The attributes you specify on Identity Server are used in attribute requests and responses, depending on whether you are configuring a service provider (request) or identity provider (response). Attribute sets provide a common naming scheme for the exchange.
For example, an attribute set can map an LDAP attribute, such as givenName to the equivalent remote name used at the service provider, which might be firstName. You can use these shared attributes for policy enforcement, user identification, and data injection.
Example 1:Attribute sets provide the centrally configurable means to map identity attributes between federation partners. When Access Manager Identity Server provides authenticated user information to a federated service provider such as Office 365, the attribute set determines what identity information is sent and available to Office 365 during and after authentication. The source of the identity data being sent can be the user's local LDAP directory or can be calculated dynamically. The identity data from external databases and secondary LDAP directories is achieved through virtual attributes. Virtual attributes are dynamically calculated attributes populated by the Attribute Retrieval and Transformation feature. See User Attribute Retrieval and Transformation.
Example 2: You could have a web server application that requires a user’s e-mail address. You configure the web server to be a protected resource of Access Gateway, and you configure an Identity Injection policy to add the user’s email address to a custom HTTP header. When the user accesses the protected resource, the value of the email attribute is retrieved. However, if you create an attribute set with this attribute and assign it to be sent with the authentication response of Access Gateway ESP, the value is cached at authentication and is immediately available. If you have multiple attributes that you are using in policies, obtaining the values in one LDAP request at authentication time can reduce the amount of LDAP traffic to your user store.
You can define multiple attribute sets and assign them to different trusted relationships. You can also use the same attribute set for multiple trusted relationships.
Perform the following steps to create and configure an attribute set:
Click Devices > Identity Server > Shared Settings > Attribute Sets > New.
Specify the following details:
Field |
Description |
---|---|
Set Name |
Specify a name for identifying the attribute set. |
Supports WSTrust and OAuth |
Select this option if you require to add the LDAP attributes and the virtual attributes to an attribute set. For the OAuth scope, you can add LDAP attributes or only the virtual attributes that are LDAP attributes or are constants. |
Select set to use as template |
Select an existing attribute set that you have created, which you can use as a template for the new set, or select None. To modify an existing attribute set, select that set as a template. |
Click Next.
To add an attribute to the set, click New.
Specify the following details:
Field |
Description |
---|---|
Local Attribute |
Select an attribute from the list of all server profile, LDAP, shared secret attributes and virtual attributes. For example, you can select All Roles to use in role policies, which enables trusted providers to send role information in authentication assertions. Share secret attributes must be created before they can be added to an attribute set. For instructions, see Creating Shared Secret Names. |
Constant |
Specify a value that is constant for all users of this attribute set. The name of the attribute that is associated with this value is specified in Remote Attribute. |
Remote Attribute |
Specify the name of the attribute defined at the external provider. The text for this field is case-sensitive.
NOTE:The FriendlyName attribute is applicable for Access Manager 5.0 Service Pack 3 and later. To configure the FriendlyName attribute, use the delimiter $$ to separate attribute name and FriendlyName. For example, configuring the Remote attribute as urn:oid:0.9.2342.19200300.100.1.2$$email, urn:oid:0.9.2342.19200300.100.1.2 is considered as value for SAML2 Attribute Name and email is considered as value for FriendlyName attribute. The SAML assertion will contain the below SAML attribute: <saml:Attribute FriendlyName="email" Name="urn:oid:0.9.2342.19200300.100.1.2" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <saml:AttributeValue xsi:type="xs:string">test@mf.com</saml:AttributeValue> </saml:Attribute> |
Remote namespace |
Specify the namespace defined for the attribute by the remote system:
|
Remote format |
Select one of the following formats:
|
Attribute value encoding |
Select one of the following encoding options:
|
Click OK.
Click Finish.
The system displays the map on the Attribute Sets page and indicates whether it is in use by a provider.
(Conditional) To configure a provider to use the attribute set, see Selecting Attributes for a Trusted Provider.