Map a local user identity to a SAML 1.1 token

We can map a local identity to a SAML 1.1 token for an identity provider.

The Security Verify Access server places the local user identity information into an XML document that conforms to the security token service universal user (STSUUSER) schema. The identity provider issues a SAML 1.1 token to the service provider. It generates the SAML 1.1 token based on the local identity of the user. We can customize how the local identity is converted into a SAML 1.1 token using a mapping rule.

Security Verify Access first converts the local identity to an STS Universal User. It then converts this STS Universal User into another STS Universal User using a mapping rule that you provide. After that, it converts the latter STS Universal User to a SAML 1.1 token.

Your mapping rule does not operate directly on local identity or SAML 1.1 token. Instead, it operates on the STS Universal User. Any modification made to an STS Universal User has an impact on the output SAML 1.1 token.

The mapping rule is responsible for the following tasks:

1. Map Principal Attr Name to a Principal Name entry. When the token module generates the token, this Principal name is not directly used. Instead, the value in the Name field is sent as input to the alias service. The alias service obtains the alias name, name identifier, for the principal, and places the returned alias in the generated token module.

   The type must be valid for SAML. For example:

   urn:oasis:names:tc:SAML:1.1:assertion

2. Set the authentication method to the password mechanism. This action is required by the SAML standard.

Parent topic: Customizing SAML identity mapping