SAML assertion across the WebSphere Application server security Domain

Brief introduction

Security Assertion Markup Language (SAML) is an OASIS open standard for representing and exchanging user identities, authentication, and property information. SAML is becoming a common technique for creating a single sign-on (SSO) solution. Companies that want to provide business services to authorized users of their business partners can apply this technology to create an SSO solution to cross Enterprise Federated Web Services resources.

Consider a business scenario where you want your users to have access to the business services of a partner company. The best SSO effect is that the user simply authenticates to your enterprise without having to authenticate to another company. When a user accesses a Web service resource, the user identity and property data can be passed using the SAML token. Because of business and privacy issues, these companies are likely not to consolidate their multiple user directories into a single common user directory. This means that the SAML token will contain user identities from external security domains that are not defined in the business service provider's user directory. This article discusses how to use the SAML support in Ibm®websphere®application Server V7.0 Fix Pack 7 to assert a SAML token across multiple security domain boundaries, and to make direct access using external security domain user identities and custom SAML group properties Control decisions. As you can see, it is easier to manage the assertion of external identities and custom group properties based on trust relationships than identity and group mapping techniques.

SAML token

The SAML token is digitally signed by the token issuer to ensure the integrity of the token. The business service provider can validate the digital signature of the token issuer to verify the authenticity of the user identity in the SAML token. Verifying the digital signature of a token issuer is the basis for verifying a trust relationship between business partners. This article describes the trust model used to assert a SAML token to create a user security context in the application Server runtime environment. This article also includes a ejb™3.0 java™api for XML Web Services (JAX-WS) sample application that demonstrates how to configure a cross security Domain Saml assertion based on the trust relationship between the SAML token issuer and the WEB service provider. You will learn how to configure business services through this application to make resource access control decisions using SAML tokens.

There are many advantages to building an SSO solution using the application Server SAML Token Assertion Trust model:

The advantage for users is that they only need to authenticate themselves to their own security domain, and then they can access the business partner's Web service resources through a trust relationship. Users do not need to manage account numbers and authentication data for other security domains.

The obvious advantage for IT administrators is that extensive third-party interoperability is achieved through the use of standards-based SAML technology.

Another major advantage for IT administrators is the cost of managing the identity of federated business Resources. There is no need to consolidate the company's user directory, even if it works in a business scenario, and the task is cumbersome.

Another advantage for IT administrators is the retention of user identities in the external security domain, which can be included in security and business audit records.

Unless otherwise stated, the WebSphere Application server in this article refers to the WebSphere application server V7.0 that has the Fix Pack 7 (V7.0.0.7) or later applied.

Multi-Secure Domain business scenario

Figure 1 is an example of a WEB services federated business scenario. The figure shows three WebSphere application Server security domains, each containing its own user repository configuration. These security domains can represent different business units or different companies. Users in the two security domains on the left send WEB service messages to access the resources of the security domain on the right. Users send their identities in the SAML token, indicating their identity to the target security domain. The Web service provider creates a security context using the SAML user identity, such as the JAAS principal. Making resource access control decisions requires a JAAS principal representing the client.

Figure 1. Assert the SAML token across the WebSphere application Server security Domain