SAML 2.0 module
The SAML 2.0 module (Saml20STSTokenModule) validates and issues tokens used for single sign-on in SAML 2.0 federations. Security Assertion Markup Language 2.0 (SAML 2.0) is for exchanging authentication and authorization data between security domains. cross-domain single sign-on reduces the administrative overhead of distributing multiple authentication tokens to the user.
- Scenarios
- Single sign-on federations
- Custom trust chains
- Supported modes
- Validate
- Issue
- Exchange
- Configuration properties
- Validate mode
- Enable one-time assertion use enforcement
- Whether to use the assertion or token only once.
- Enable signature validation
- Enable or disable validation of signatures in the token module. Even if we do not select the check box, we must provide the key for decryption.
- Select a validation key
- Validation key the partner must use.
- Use the KeyInfo of the XML signature to find the X509 certificate for signature validation
- Determines the appropriate certificate for signature validation. When we select this option, we must provide the subject distinguished name matching the certificate.
- RegExp
- Regular expression to validate the subject distinguished name returned in theKeyInfo.
- Use the keystore alias to find the public key for signature validation
- Public key for signature validation, which is the default. Certificate database and label.
- Certificate Database
- Certificate database to use for validation.
- Certificate Label
- Certificate label for validation.
- Select a decryption key
- Select the key to use to decrypt encrypted messages.
- Certificate Database
- Certificate database to use for validation.
- Certificate Label
- Certificate label for validation.
- Create multiple attribute statements in the Universal User
- Whether to keep multiple attribute statements in the groups in which they were received. This option might be necessary if the custom identity mapping rules are written to operate on one or more specific groups of attribute statements.
- If we do not select this check box, multiple attribute statements are arranged into a single group (AttributeList) in the STSUniversalUser document. The default setting of the check box is not selected. This setting is appropriate for most configurations.
- Map unknown name identifiers to the anonymous username
- The service provider can map an unknown persistent name identifier alias to the anonymous user account. By default, this option is disabled.
- Default NameID format for assertion validation
- Parameter for use during validation of a SAML assertion. Used to determine processing rules for the NameID element when one of the following conditions exists:
- If there is not an explicit Format attribute included in the assertion
- If the Format attribute is urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified
Typically needed only for STS chains that process SAML assertions that do not set the Format attribute. A normal example value is urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress.
- Issue and Exchange mode
- Name of the organization issuing the assertions
- Name of the organization (for example, a company) that issues the SAML assertions.
- Amount of time before the issue date that an assertion is considered valid (seconds)
- Default: 60 seconds
There is no minimum or maximum value enforced.
This field must contain a value.
- Amount of time the assertion is valid after being issued (seconds)
- Default: 60 seconds
There is no minimum or maximum value enforced.
This field must contain a value.
- List the attribute types to include
- Types of attributes to be inserted during token creation. The attributes consist of information about the identity (user). Use && to separate attribute types. By default, all types are supported, as indicated by the asterisk (*) wildcard character.
For example, to add user-defined attribute types type1 and type2, enter:
type1&&type2
- Sign SAML assertions
- Select if SAML assertions must be signed. Even if we do not select the check box, we must provide the key for encryption assertions.
- Select the key for signing assertions
- Key to use when signing SAML assertions.
- Certificate Database
- Certificate database to use for validation.
- Certificate Label
- Certificate label for validation.
- Select the KeyInfo elements to include
- Determines what KeyInfo elements to include in the digital signature when signing a SAML message or assertion. Select one or more of the following elements.
- X509 Subject Key Identifier
- Include the X.509 subject key identifier with your signature. If not selected, the subject key identifier is excluded. To change the default for this element, change it in the custom properties.
- Public Key
- Include the public key with your signature. If not selected, the public key is excluded. To change the default for this element, change it in the custom properties.
- X509 Subject Issuer Details
- Include the issuer name and the certificate serial number with your signature. If not selected, the subject issuer details are excluded. To change the default for this element, change it in the custom properties.
- X509 Subject Name
- Include the X.509 subject name with your signature. If not selected, the X.509 data is excluded. To change the default for this element, change it in the custom properties.
- X509 Certificate Data
- Include the BASE64 encoded certificate data with your signature. If not selected, the X.509 data is excluded. To change the default for this element, change it in the custom properties.
If we do not select any of the KeyInfo elements, X.509 certificate data is still included in the signature by default.
- Signature algorithm for signing SAML assertions
- Signature algorithm to use to sign the SAML assertion.
- RSA-SHA1
- http://www.w3.org/2000/09/xmldsig#rsa-sha1
- DSA-SHA1
- http://www.w3.org/2000/09/xmldsig#dsa-sha1
- RSA-SHA256
- http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
The chosen signature algorithm must match the signing key type set in the federation level to prevent a signature failure. For example, select DSA-SHA1 for DSA keys.
- Select the key for encrypting assertion elements for this partner
- Key to use to encrypt assertions.
- Certificate Database
- Certificate database to use for validation.
- Certificate Label
- Certificate label for validation.
- Encrypt assertions
- Whether assertions are to be encrypted. If selected, specify an encryption key.
- Encrypt assertion attribute elements
- Whether Attribute elements within the assertions are to be encrypted. If selected, specify an encryption key.
- Encrypt NameID elements in assertions
- Whether NameID elements in the assertions are to be encrypted. If selected, specify an encryption key.
- Block encryption algorithm
- Encryption algorithm to use to encrypt data for this partner.
- Triple DES
- Triple Digital Encryption Standard
- AES-128
- Advanced Encryption Standard 128-bit
- AES-192
- Advanced Encryption Standard 192-bit
- AES-256
- Advanced Encryption Standard 256-bit
- Subject confirmation method
- Subject confirmation method for the assertion. We can select one or more subject confirmation methods at the same time, or choose not to select any confirmation methods. If you select the holder-of-key type, the default includes the X.509 Certificate Data in the KeyInfo for the SubjectConfirmationMethod. STSUniversalUser can provide the data for the subject confirmation method KeyInfo. The data can also be extracted from the signed request data.
- Valid values can be:
- urn:oasis:names:tc:SAML:2.0:bearer
- urn:oasis:names:tc:SAML:2.0:holder-of-key
- urn:oasis:names:tc:SAML:2.0:sender-vouches
We can use the identity mapping rules to add subject confirmation information to the STSUniversalUser.
<stsuuser:Attribute name="SamlSubjectConfirmationMethod" type="urn:oasis:names:tc:SAML:2.0:assertion"> <stsuuser:Value>urn:oasis:names:tc:SAML:2.0:cm:bearer </stsuuser:Value> <stsuuser:Value>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key </stsuuser:Value> </stsuuser:Attribute>Another way to add subject confirmation information is by using configuration properties. See the topic on SAML 2.0 module properties. The values set in the identity mapping rule take precedence over the settings in the configuration.For the SubjectConfirmationMethod to be issued correctly, the client must sign the RequestSecurityToken request and include a KeyInfo used for the SCM when sending the RequestSecurityToken. To use the holder-of-key capability, the JavaScript mapping rules must be updated to insert the attribute into the STSUU.
For example:
<stsuuser:AttributeList> <stsuuser:Attribute name="SamlSubjectConfirmationMethod" type="urn:oasis:names:tc:SAML:2.0:assertion"> <stsuuser:Value>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key </stsuuser:Value> </stsuuser:Attribute> </stsuuser:AttributeList>
Parent topic: Supported module types