Introduction to Security Assertion Markup Language (SAML) and SAML Support in IBM WebSphere Application Server Version 7.

0 Fix Pack 7

November 17, 2009 IBM WebSphere Web Services Security Development Software Group
Copyright IBM Corp. 2009

Abstract Security Assertion Markup Language (SAML) is an XML based framework developed by the Organization for the Advancement of Structured Information Standards (OASIS), used for the exchange of security information between different parties. This is an open standard that can be used to exchange security information between different products. SAML support in IBM WebSphere Application Server Version 7.0 Fix Pack 7 delivers a SAML solution that provides support for the most common scenarios SAML using Web services. Introduction As Web services become more prevalent and businesses seek to provide combined services to the customers they share, the need for a group of businesses to provide a single point of entry to their customers becomes very important. Take the classic case of a traveler preparing to book a flight, hotel and car reservations. Without any kind of integration or agreements between the different businesses providing these services, customers need to log in to their preferred airline Web site, book the flight, and then log in separately to their preferred car rental company's Web site to get a car, and finally, log in to their preferred hotel or hotel booking Web site. This process can be a burden to customers that need to remember their different user names and passwords, and keep track of the different reservations on different Web browser sessions, with no unified interface showing the status of the different reservations. It also can be a burden to the different businesses, as each of them has to develop and maintain their own user authentication solution. In the world of Web services, a similar scenario can take place. A client application may need to send a SOAP message to be processed by a service. One possible solution would be that the client authenticates to the service, and the service handles the authentication, and keeps its own record of the security credentials for this clients identity. However, this service may need to forward the message for further processing to one or more services. Without another kind of solution, each service would need to individually authenticate the client and keep record of the clients credentials for that individual service. This puts a burden on the client of having to authenticate multiple times to get a single service completed, and also, the individual services would need to maintain their own authentication solution and records of credentials. A scalable solution would be to have the client authenticate once, and if successful, have the authentication results and the clients identity and credentials propagated to all services involved based on a trust relationship (assuming that the services trust the original authenticator). This way, the client would only authenticate once, and each individual service would be relieved of the responsibility of authenticating the client and keeping security credentials information for each registered user. This type of problem is what Single Sign-On (SSO) solutions aim to solve: having a person or service authenticate only once, obtaining access to a wide variety of online services without the need to re-authenticate on each one. As part of this

goal, some concerns must be addressed, such as how do you establish trust among service providers that the service requester is truly who it says it is? How do you communicate the services or resources that a service requester is entitled to? For how long is the authentication valid? In multi-hop asynchronous environments, where there is no guarantee when a request will be handled, how do you handle the lifetime of the authentication? Can the SSO solution work in a cross-vendor environment? There are a number of SSO solutions available that address some of these concerns. One such solution is Lightweight Third-Party Authentication (LTPA), available in IBM products. In WebSphere, Tivoli and Lotus products, LTPA has been used to implement SSO. While this works well in IBM solutions, incorporating non-IBM products into the scenario requires another approach to maintain a SSO solution. Another possible SSO solution is the use of Kerberos authentication. Kerberos is a network authentication protocol that provides a centralized authentication server where clients authenticate to get Kerberos credentials. These credentials can be used to get service tickets to access multiple services. It also is an open standard that can be implemented across multi-vendor products. Some implementations even provide support to communicate client attributes, but these are proprietary implementations. There is not a standardized way to communicate attributes in Kerberos. Therefore, if any attributes associated with a request's subject (such as what resources the requester is entitled to) must be communicated, it would depend on the proprietary implementation of a given vendor. Integration with other vendors would be difficult or impossible. There are also scalability issues with large scale cross realm topologies because of its dependence on shared/secret keys. Distribution of the key on such environments requires that the parties involved coordinate how to securely exchange the secret key. Security Assertion Markup Language (SAML) aims to solve these shortcomings. Developed by the Organization for the Advancement of Structured Information Standards (OASIS), it is an XML-based framework that aims to solve the problem of exchanging security information. By the use of SAML assertions, security information related to a subject can be shared among service providers in a platform-agnostic way. Most importantly, for Web services using WS-Security to secure its messages, SAML can be used to secure the message exchange between different services. In SAML, the PKI based trust model is used to establish trust. For example, by signing a message with the senders private key, it can be proven that the message was truly sent by the sender. This is a well understood and widely used model that allows for the easy management of trust relationship. In addition, PKI can also be used for the distribution of symmetric keys protected by the receivers public keys, solving the problem of distribution of keys with a scalable solution. With SAML, a platform-neutral, secure and scalable SSO solution can be implemented.

SAML support in WebSphere Application Server Version 7.0.Fix Pack 7 delivers SAML functionality for JAX-WS Web services. This paper provides an introduction to SAML basic concepts and features. SAML Concepts: To support the exchange of security information, SAML makes use of the following basic concepts: Assertions: At the core of SAML, assertions are used by an asserting party to communicate the authentication, attributes and entitlement information for a given subject. Thanks to the fact that SAML is a platform independent framework, as it is based in the platform neutral XML specification, SAML assertions can be exchanged between different services that run on different platforms. Bindings: Map SAML protocols to the lower level transports that are used for the request/response exchanges. One example for bindings is the SAML SOAP bindings. These bindings define how the SAML request and response messages described in SAML protocols can be executed using SOAP message exchanges. Profiles: Define combinations of assertions, protocols and bindings that can be used for specific use cases. For example, there is a Web services security SAML token profile that defines how to use SAML V1.1 and V2.0 assertions with Web services security. SAML in Web services security SAML assertions can be used in Web services security (WS-Security) to secure Web services messages. The WS-Security standard defines the use of SAML assertions in the form of a security token with the Web services security SAML token profile. It is worth mentioning that this is not to be confused with the use of SAML over SOAP bindings. SAML over SOAP bindings is used to obtain the SAML assertion from an Identity Provider, and SAML cannot play any role in the protection of the SOAP message. In WS-Security, the SAML assertions pertaining to the identity of the requester have already been obtained. In addition, in WS-Security, SAML can play a role in the protection of the message itself. For example, in a SAML token with Holder-of-Key confirmation method, the cryptographic key used to confirm the subject can also be used to protect the message. This would not be the case on Bearer and Server-Vouches confirmation methods. The typical SAML usage scenario using WS-Security works as follows: A client authenticates to a security token service (STS) to request a SAML token. The STS is trusted by both client and service provider to provide the authentication.

STS creates SAML assertions needed for the transaction and issues the SAML security token to the client. The STS signs the token with its private key and includes its own X509 certificate in the token. The client adds a SAML security token to the WS-Security header of the SOAP message. It then sends the SOAP message to the service provider. The service verifies that the SAML token can be trusted. To do so, it first verifies the STSs certificate included in the SAML token against its own trust store. If the certificate passes verification, the public key of the X509 certificate is used to verify the tokens digital signature. The service provider confirms the identity of the subject using a subject confirmation method that is specified on the SAML token via the SubjectConfirmation assertion. If valid, it proceeds to give access to the resources requested by the client.

The SAML token profile defines three subject confirmation methods to verify the validity of a SAML token. Each of these methods enforces a set of criteria to confirm that the SAML token assertions that were received are really associated with the subject requesting the service.

Bearer Subject Confirmation: In this method, the SAML token carries the subject's identity and attributes. There is no requirement to verify trust by the profile, as it is assumed that the token is trusted, however XML signature validation is recommended to confirm that the token was issued by the STS. By default, WebSphere Application Server follows the recommendation and validates the issuers digital signature. This is useful in scenarios where SSL is used to secure the message insuring security from point to point. At the time of this writing, this is by far the most used of subject confirmation methods.

Figure 1: Bearer Subject Confirmation method.

Holder of Key Subject Confirmation Method: In this method, the SAML token carries the subject's identity and attributes and it can provide message protection. The receiver of the token is required to verify that the token can be trusted, typically by checking the tokens digital signature performed with the STSs private key. The sender of the SAML token must demonstrate knowledge of a cryptographic key identified in the SubjectConfirmation element of the SAML token assertion and can also use the key to cryptographically protect the message. How knowledge of the key can be demonstrated will depend on the keys type. When the key is symmetric, it is encrypted using the recipients public key so the recipient can extract it when it receives the message. To verify that the sender possesses the key, the sender can digitally sign the message with the symmetric key. When the receiver gets the message, it can obtain the symmetric key contained in the tokens SubjectConfirmation element by decrypting its contents with its private key. Once obtained, the receiver can use the key to verify the digital signature of the message, confirming that the sender possesses the key. When the key is asymmetric, the SubjectConfirmation element contains the X509 data or the RSA key value of an asymmetric pair. The private key of the pair is the senders, and it is used to digitally sign the message. When the receiver receives the token, it extracts the public key using the data available in the SubjectConfirmation element, verifying that the sender possesses the private key of the pair

Figure 2: Holder of Key Subject Confirmation Method

Sender-Vouches Subject Confirmation: Although this confirmation method is not currently supported by the WebSphere Application Server Version 7.0 Fix Pack 7 product, it deserves discussion. In this method, the SAML token carries the subject's identity and attributes. The acceptance of the confirmation method is proved by whether the sender is trusted, as the sender assumes responsibility for verifying validity of the SAML token. The sender must protect the integrity of the message to prove this trust. One example is using transport level signing, with SSL. Another example would be that the sender signs the message with its own private key. Whatever method is used, the sender is always required to protect the integrity of the SAML token and the recipient must verify the integrity.

Figure 3: Sender-Vouches Subject Confirmation; not currently supported in the product

SAML Token Propagation in Web Services As discussed previously, a web services client can obtain a SAML token from a security token service (STS) which contains its identity and security attributes. The client can then send the SAML token on a request to a service provider. The service will validate that the token is signed by an issuer that it trusts and obtain the identity and security attributes from the token. However, it is common that a service provider will use one or more service providers to complete its business logic. Instead of requiring the client to authenticate to the STS for each of these services, a better solution would be for the first service to propagate the SAML token when it makes its requests to the other services. The SAML token already contains the subjects identity and authenticated security attributes and can be propagated to the downstream services. Figure 4 shows this scenario:

Figure 4: Propagation of a SAML token to services, which is used to implement a single sign-on solution.

The ability to propagate the SAML token from the original client provides an end to end security solution. However, one factor that must be taken into account is the expiration time of the SAML token and how long it would take for all the services downstream to process a request. If one service takes too long to execute its own business logic, the token may be expired before it propagates the token to another service. This process is illustrated in Figure 5:

Figure 5: Same SAML token is propagated to Service Provider 2 after it has expired. One solution for such a case would be to configure the STS to issue a SAML token with longer expiration time. This solution may work if the total request invocation time is well known. However, in reality, the total request invocation time is non-deterministic. Re-issuing of SAML tokens is one possible solution. In this case, when a service is about to propagate the SAML token, it checks the expiration time of the original. If it finds that the expiration time has expired or it is close to expiring, the service, itself, can issue a new SAML token by copying the original SAML token assertion and security attributes, but with a new expiration time. The second service would accept this new self-issued SAML token with the new expiration time. However, this means that there is a change in the trust relationship between services. Before, the SAML token from the STS was propagated among services causing the subjects identity and authenticated security attributes in the token to also be propagated. This is made possible because each of the parties

involved trust the STS. However, in this case this trust relationship has changed, because once a service sends a self-issued SAML token, the receiving services must trust the sender service to accept the self-issued token, not the STS. This process is illustrated in Figure 6:

Figure 6: Self-issuance of the SAML tokens by each service is a possible solution for token expiration time issues, but this means that the trust relationship with the STS is changed to the services doing self-issue. Before deploying a solution that uses self-issuance of SAML tokens, consider whether it is acceptable to trust the services doing the self-issuance. Also, consider the security implications of changing the expiration time originally set by the STS. If the risks are well understood, then self-issuance of SAML tokens may be an acceptable solution for SAML token expiration issues.

SAML support in WebSphere Application Server Version 7.0 Fix Pack 7 The SAML solution for JAX-WS Web services in Fix Pack 7 includes the following highlights:

It is configurable via policy sets. Default policy sets covering common SAML usage scenarios for Bearer and Holder of Key subject confirmation are included. Sender Vouches method is not supported. Support for scenarios targeting OASIS Web services security SAML 1.1 profile with V1.1 and V2.0 SAML tokens. API to create and consume SAML assertions SAML token propagation support using self-issuance of SAML tokens Allows for use with external security token service (STS), tested with Tivoli Federated Identity Manager. SAML support in the product does not support its own STS solution.

As mentioned above, Fix Pack 7 ships policy sets for the most frequently used SAML usage scenarios. Specifically, it delivers Bearer and Holder of Key subject confirmation policy sets. These are: Pre-packaged policy sets SAML11 Bearer WSHTTPS default Policy set contents and description Policies: HTTPTransport, SSLTransport, WSAddressing, WSSecurity * Transport security: Using SSL for HTTP * Message authentication: Using SAML 1.1 Token with bearer confirmation method. SAML11 HoK Public WSSecurity default Policies: WSSecurity, WSAddressing * Message integrity: Digitally sign body, timestamp and addressing headers * Message confidentiality: Encrypt

body and signature * Message authentication: Using SAML 1.1 token contains holder of key confirmation method and a reference of client public key. SAML11 HoK Symmetric WSSecurity default Policies: WSSecurity, WSAddressing * Message integrity: Digitally sign body, timestamp and addressing headers * Message confidentiality: Encrypt body and signature * Message authentication: Using SAML 1.1 token contains holder of key confirmation method and a symmetric key. SAML20 Bearer WSHTTPS default Policies: HTTPTransport, SSLTransport, WSAddressing, WSSecurity * Transport security: Using SSL for HTTP * Message authentication: Using SAML 2.0 Token with bearer confirmation method. SAML20 HoK Public WSSecurity default Policies: WSSecurity, WSAddressing * Message integrity: Digitally sign body, timestamp and addressing headers * Message confidentiality: Encrypt body and signature * Message authentication: Using SAML 2.0 token contains holder of key confirmation method and a reference of client public key.

SAML20 HoK Symmetric WSSecurity default

Policies: WSSecurity, WSAddressing * Message integrity: Digitally sign body, timestamp and addressing headers * Message confidentiality: Encrypt body and signature * Message authentication: Using SAML 2.0 token contains holder of key confirmation method and a symmetric key.

Username WSHTTPS default (for communication with STS)

Policies: HTTPTransport, SSLTransport, WSAddressing, WSSecurity * Transport security: Using SSL for HTTP * Message authentication: Using Username token

Uses can take advantage of these pre-defined SAML policy sets to enable SAML for their existing JAX-WS web services or customize their SAML solution based on these pre-defined policy sets. It also provides the Username WSHTTPS default policy set which is common for communicating with security token services such as Tivoli Federated Identify Manager. SAML token propagation is also supported in the product. The SAML token can be propagated by forwarding using the original token issued by an STS or reissuing the token when it is determined that it is an appropriate solution. Conclusion Security Assertion Markup Language (SAML) is an XML-based framework that is designed to solve the problem of exchanging security information across multiple platforms or vendors. Using SAML assertions, security information related to a subject can be propagated among service providers in a heterogeneous platform environment. SAML tokens can provide a Single Sign-On solution where a client would only need to authenticate once to an STS and assert the SAML token that it obtains from the STS to multiple service providers based on a trust relationship. This can be accomplished by having services propagate the SAML token. In some cases, the business logic of a service may take longer than a SAML tokens lifetime, and

if the service decides to propagate the token, the next service receiving it will not accept it as it will find that the tokens lifetime has expired. If the total time to process a request is known, increasing the expiration time of the token at the time the STS issues it is an appropriate solution. If the time to process the request is non-deterministic, having the service providers reissue SAML tokens with new expiration times if the token has expired may be an appropriate method to propagate the token. However, in that case the trust relationship changes from trusting the STS to trusting the services doing the re-issuing of the tokens and a security analysis will need to be made to determine if this is an acceptable solution. WebSphere Application Server Version 7.0 Fix Pack 7 SAML supports Bearer and Holder of Key confirmation methods. It also supports propagation of SAML tokens and self-issuance. It has been tested with Tivoli Federated Identity Manager. The pre-defined SAML policy sets can facilitate existing or new JAXWS Web services to exploit the new SAML support. References [1] Organization for the Advancement of Structured Information Standards (OASIS), Security Assertion Markup Language [SAML] V2.0 Technical Overview, 2006. http://www.oasis-open.org/committees/download.php/20645/sstc-samltech-overview-2%200-draft-10.pdf [2] Organization for the Advancement of Structured Information Standards (OASIS), SAML Executive Overview, 2006. http://www.oasisopen.org/committees/download.php/11785/sstc-saml-exec-overview-2.0-draft06.pdf [3] Organization for the Advancement of Structured Information Standards (OASIS), Web Services Security: SAML Token Profile 1.1, 2006. http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-osSAMLTokenProfile.pdf

 Copyright IBM Corporation 2009 All Rights Reserved. IBM, the IBM (logo), Lotus, Tivoli, and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others. References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATIONPROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTYOF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUTNOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR APARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to nonIBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. The information in this publication is provided AS IS without warranty. Such information was obtained from publicly available sources, is current as of January 2009, and is subject to change. Any performance data included in the paper was obtained in the specific operating environment and is provided as an illustration. Performance in other operating environments may vary. More specific information about the capabilities of products described should be obtained from the suppliers of those products.