The minimum requirement to configure the WebSphere Application Server SAML service provider as an SSO partner to an identity provider is to import the SAML token signer certificate from the identity provider to the trust store of the service provider. The service provider can be configured to work with multiple identity providers. For each identity provider, you must import the SAML token signer certificate.
You can import the certificate used by an IdP to sign the SAML token by using either the administrative console or the wsadmin command-line utility.
You can grant inbound trust to the identity providers using either the administrative console or the wsadmin command utility.
Each identity provider that is used with your WebSphere Application Server service provider needs to be configured to add the service provider as an SSO partner. The procedure for adding the service provider partner to an identity provider depends on the specific identity provider. Refer to the documentation of the identity provider for instructions on how to add a service provider partner for SSO.
You can either export the WebSphere Application Server service provider metadata, and import it to the identity provider, or manually configure the identity provider to add the service provider.
To add the service provider as a federation partner to an identity provider, you must provide the URL of the Assertion Consumer Service (ACS) of the service provider, which is the -acsUrl parameter used when enabling the SAML trust association interceptor (TAI).
wsadmin -lang jython AdminTask.exportSAMLSpMetadata('-spMetadataFileName /tmp/spdata.xml -ssoId 1')This command creates the /tmp/spdata.xml metadata file.
If the SAML token is encrypted, you must provide the public key certificate that you want the identity provider to use for encrypting the SAML token, and the certificate must exist in the WebSphere Application Server default KeyStore before performing an export.
You can map the SAML assertion to the WebSphere Application Server platform Subject without using a local registry and this is the default behavior. In this default implementation, the SAML NameID is mapped to the principal, the issuer is mapped to the realm, and selected attributes can be mapped to group members. ID assertion can be further customized. For example, you can configure a SAML attribute as a principal, realm, accessId, or a list of group members. You can also configure NameQualifier from NameID as a realm, or use a predefined realm name.
You can configure the WebSphere Application Server service provider to map the NameID from a SAML assertion to the local registry of the service provider, and build the subject from the registry. With this option, you can directly search the SAML NameID against the registry, or use a plugin point for custom mapping of the assertion, and then use the new mapped ID to build the subject from the registry.
This option allows you to map the NameID to the registry, and fall back to ID assertion if the NameID cannot be mapped to the registry.
This option combines ID assertion and local registry and allows you to reevaluate group membership while doing ID assertion. Consider a SAML assertion from a partner lab, containing user Joe with a group attribute of X-ray Techs. At the service provider, the group X-ray Techs is a subgroup of group Technicians, but Joe is not necessarily in the user registry of the service provider. The authorization policy of the service provider application allows access to the Technicians group. To achieve this, the SAML TAI needs to look up the asserted groups X-ray Techs in the registry and then include the parent groups Technicians in the Subject.
When doing ID assertion to create a security context, a custom security realm is chosen. You must explicitly add the custom realm as a trusted realm. In a default ID assertion implementation, the SAML issuer name is used as the security realm. You must explicitly add the issuer name to the list of inbound trusted authentication realms in current user registry. After adding the custom realm to the inbound trusted realms, you are ready to do role mapping with this custom realm.
To add a custom realm as a trusted realm, see the Add IdP realms to the list of inbound trusted realms step.
In this information ... | IBM Redbooks, demos, education, and more(Index) Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience. This feature requires Internet access. Most of the following links will take you to information that is not part of the formal product documentation and is provided "as is." Some of these links go to non-IBM Web sites and are provided for your convenience only and do not in any manner serve as an endorsement by IBM of those Web sites, the material thereon, or the owner thereof. |