Airlock IAM as SAML identity provider (IDP)

In order to send user context data in SAML assertions to selected SAML SPs, the Airlock IAM IDP must be configured as follows:

A user persister plugin should be configured in the login application (top-level configuration property of the login application).

This user persister may be used to read the context-data attributes to be sent to the user if they are not already contained in the authentee.

In the "Target Application using SAML 2.0", a list of attributes of various types can be configured to be included in the assertion. This is the recommended way to add attributes to an assertion.

For legacy setups, the attributes to add can also be configured in the extended metadata files. For each SP that shall receive dynamic attribute data from the Airlock IAM IDP, the corresponding SP's extended meta-data file must be edited (e.g. some-sp-extended.xml). Alternatively, a default map can also be specified in the IDP's extended metadata file. It is used for all SPs not defining their own map. However, defining the attributes in the target application or the SP's extended metadata is preferred.

If both attributes in the target application and the extended metadata are configured, the configuration in the target application takes precedence and all attributes defined in the metadata which do not occur in the configuration are added as well.

Where can I find the SP's extended meta data file?

The extended SP meta data file is specified in the target application's SAML settings.

Open the file and add the context data attributes to the attributeSet tag as in the following example. The syntax is  <Assertion Attribute Name>=<Context Data Name or special identifier>

some-sp-extended.xml

    ...
    <Attribute name="attributeMap">
           <Value>GIVENNAME=givenname</Value>
           <Value>SURNAME=surname</Value>
           <Value>USERNAME=USER_ID</Value>
           <Value>ROLES=GRANTED_ROLES</Value>
    </Attribute>
    ...

In the above example, the context data attributes "givenname" and "surname" are read from the user's context data container and are transported in the Assertion using the attribute names GIVENNAME and SURNAME. Also the user name is transported in the attribute named USERNAME and the user's roles is transported in the multi-value attribute ROLES. Notice that the assertion attribute names on the left hand side needn't be in upper case, they can be anything. The values on the right hand side however need to match the context data fields exactly and the special identifiers USER_ID and GRANTED_ROLES need to be upper case.