3.5 Configuring the Identity Server Shared Settings

The Shared Settings tab on the Identity Servers page allows you to define the following shared settings:

Attribute sets: Sets of attributes that are exchangeable between identity and service providers.
User matching expressions: The logic of the query to the user store for identification when an assertion is received from an identity provider.
Shared Secret names: Custom shared secret names that you want to be available when configuring policies.
LDAP attributes: Custom LDAP attribute names that you want to be available when configuring policies.
Authentication card images: Custom images that you can assign to authentication cards to uniquely identify an authentication procedure.
Metadata Repositories: Import metadata of trusted providers.

You can reuse these settings. These are available in any Identity Server cluster configuration.

This section describes the following tasks:

3.5.1 Configuring Attribute Sets

The attributes you specify on the 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. These shared attributes can then be used for policy enforcement, user identification, and data injection.

For example, you could have a Web server application that requires the user’s e-mail address. For this scenario, you configure the Web server to be a protected resource of the 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, then assign it to be sent with the authentication response of the Embedded Service Provider of the Access Gateway, 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.

To create and configure an attribute set:

In the Administration Console, click Devices > Identity Server > Shared Settings > Attribute Sets > New.
Specify the following fields:

Set Name: Specify a name for identifying the attribute set.

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 fields:

Specify the attribute. Select from the following:
- Local Attribute: Select an attribute from the drop-down list of all server profile, LDAP, and shared secret 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 the Remote Attribute field.
Remote Attribute: Specify the name of the attribute defined at the external provider. The text for this field is case sensitive.
- A value is optional if you are mapping a local attribute. If you leave this field blank, the system sends an internal value that is recognized between Identity Servers.
  
  For a SAML 1.1 and SAML 2.0 identity consumer (service provider), a name identifier received in an assertion is automatically given a remote attribute name of saml:NameIdentifier. This allows the name identifier to be mapped to a profile attribute that can then be used in policy definitions.
- A value is required if you are mapping a constant.
  
  An attribute set with a constant is usually set up when the Identity Server is acting as an identity provider for a SAML or Liberty service provider. The name must match the attribute name that the service provider is using.
Remote namespace: Specify the namespace defined for the attribute by the remote system:
- If you are defining an attribute set for LDAP, select none. If you want a service provider to accept any namespace specified by an identity provider, select none. If you want an identity provider to use a default namespace, select none. The urn:oasis:names:tc:SAML:1.0:assertion value is sent as the default.
- If you are defining an attribute set for WS Federation, select the radio button next to the text box, then specify the following name in the text box.
```
http://schemas.xmlsoap.org/claims
```
- If you want to specify a new namespace, select the radial button by the text box, then specify the name in the text box.
Remote format: Select one of the following formats:
- unspecified: Indicates that the interpretation of the content is implementation-specific.
- uri: Indicates that the interpretation of the content is application-specific.
- basic: Indicates that the content conforms to the xs:Name format as defined for attribute profiles.
Attribute value encoding: Select one of the following encoding options:
- Special characters encoded: Encodes only the special characters in the attribute value.
- Not encoded: Does not encode the attribute value.
- Entire value encoded: Encodes the entire attribute value.
Click OK.

The system displays the map settings on the Define Attributes page, as shown below:

You can continue adding as many attributes as you need.
Click Finish after you created the map.

The system displays the map on the Attribute Sets page, as well as indicating whether it is in use by a provider.
(Conditional) To configure a provider to use the attribute set, see Section 3.9.6, Selecting Attributes for a Trusted Provider.

3.5.2 Editing Attribute Sets

You can edit attribute sets that have been created in the system.

In the Administration Console, click Devices > Identity Server > Shared Settings > Attribute Sets.
Click the name of the attribute set that you want to edit.
The system displays an attribute set page with the following tabs:

General: Click to edit the name of the attribute set.

Mapping: Click to edit the attribute map.

Usage: Displays where the attribute set is used. Informational only.
Click OK, then click Close.

3.5.3 Configuring User Matching Expressions

When a service provider receives an assertion from a trusted identity provider, the service provider tries to identify the user. The service provider can be configured to take one of the following actions:

Accept that the assertion contains a valid user and authenticate the user locally with a temporary identity and account. As soon as the user logs out, the account and identity are destroyed.
Use the attributes in the assertion to match a user in the local user store. When you want the service provider to take this action, you need to create a user matching expression.
Use the attributes in the assertion to match a user in the local user store and when the match fails, create an account (called provisioning) for the user in the local user store of the service provider. When you want the service provider to take this action, you need to create a user matching expression.

The user matching expression is used to format a query to the user store based on attributes received in the assertion from the identity provider. This query must return a match for one user.

If the query returns a match for multiple users, the request fails and the user is denied access.
If the query fails to find a match and you have selected provisioning, the service provider uses the attributes to create an account for this user in its user store. If you haven’t selected provisioning, the request fails and the user is denied access.

The user matching expression defines the logic of the query. You must know the LDAP attributes that are used to name the users in the user store in order to create the user’s distinguished name and uniquely identify the users.

For example, if the service provider user store uses the email attribute to identify users, the identity provider should be configured to send the email attribute. The service provider would use this attribute in a user matching expression to find the user in the user store. If a match is found, the user is granted access. If the user is not found, that attribute can be used to create an account for the user. The assertion must contain all the attributes that the user store requires to create an account.

To create a user matching expression:

In the Administration Console, click Devices > Identity Servers > Shared Settings > User Matching Expressions.
Click New, or click the name of an existing user matching expression.
Specify a name for the user lookup expression.
Click the Add Attributes icon (plus sign), then select attributes to add to the logic group. (Use the Shift key to select several attributes.)
Click OK.
To add logic groups, click New Logic Group.

The Type drop-down (AND or OR) applies only between groups. Attributes within a group are always the opposite of the type selection. For example, if the Type value is AND, the attributes within the group are OR.
Click the Add Attributes icon (plus sign) to add attributes to the next logic group, then click OK.
Click Finish.
(Conditional) If you selected attributes from the Custom, Employee, or Personal profile, you need to enable the profile so that the attribute can be shared:
1. Click Servers > Edit > Liberty > Web Service Provider.
2. Select the profiles that need to be enabled, then click Enable.
3. Click OK, then update the Identity Server.

3.5.4 Adding Custom Attributes

You can add custom shared secret names or LDAP attribute names that you want to make available for selection when setting up policies.

Creating Shared Secret Names

The shared secret consists of a secret name and one or more secret entry names. You can create a secret name only, or a secret name and an entry name. For ease of use, the entry name should match the policy that uses it:

For a Form Fill policy, the entry name should match a form field name.
For an Identity Injection policy, the entry name should match the Custom Header Name.
For an External Attributes policy, Secret Name should match the policy name and Secret Entry Name should match the attribute name configured while creating the policy.

For example, if the policy name is fetchattr and attribute name configured in the policy is address, then Secret Name should be fetchattr and Secret Entry Name should be address.

For more information about how to use shared secrets with policies, see Section 6.5.4, Creating and Managing Shared Secrets.

The Identity Server needs to be configured to use shared secrets. For information about this process, see Configuring a User Store for Secrets.

Shared secret names can be created either on the Custom Attributes page or in the associated policy that consumes them.

In the Administration Console, click Devices > Identity Servers > Shared Settings > Custom Attributes.
To create shared secret names, click New.
Enter a new shared secret name and, optionally, a secret entry name.
Click OK.
(Optional) To create additional entries for the secret, click the name of the secret, click New, specify an entry name, then click OK.

WARNING:The Identity Server currently has no mechanism to determine whether a secret is being used by a policy. Before you delete a shared secret, you must ensure that it is not being used.

Creating LDAP Attribute Names

LDAP attributes are available for all policies. LDAP attribute names can be created either on the Custom Attributes page or in the associated policy that consumes them. The attribute names that you specify must match the name of an attribute of the user class in your LDAP user store.

In the Administration Console, click Devices > Identity Servers > Shared Settings > Custom Attributes.

This list contains the attributes for the inetOrgPerson class. It is customizable.

audio: Uses a u-law encoded sound file that is stored in the directory.

businessCategory: Describes the kind of business performed by an organization.

carLicense: Vehicle license or registration plate.

cn: The X.500 commonName attribute, which contains a name of an object. If the object corresponds to a person, it is typically the person’s full name.

departmentNumber: Identifies a department within an organization.

displayName: The preferred name of a person to be used when displaying entries. When displaying an entry, especially within a one-line summary list, it is useful to use this value. Because other attribute types such as cn are multivalued, an additional attribute type is needed.

employeeNumber: Numerically identifies a person within an organization.

employeeType: Identifies the type of employee.

givenName: Identifies the person’s name that is not his or her surname or middle name.

homePhone: Identifies a person by home phone.

homePostalAddress: Identifies a person by home address.

initials: Identifies a person by his or her initials. This attribute contains the initials of an individual, but not the surname.

jpegPhoto: Stores one or more images of a person, in JPEG format.

labeledURI: Uniform Resource Identifier with an optional label. The label describes the resource to which the URI points.

mail: A user’s e-mail address.

manager: Identifies a person as a manager.

mobile: Specifies a mobile telephone number associated with a person.

o: The name of an organization.

pager: The pager telephone number for an object.

photo: Specifies a photograph for an object.

preferredLanguage: Indicates an individual’s preferred written or spoken language.

roomNumber: The room number of an object.

secretary: Specifies the secretary of a person.

sn: The X.500 surname attribute, which contains the family name of a person.

uid: User ID.

userCertificate: An attribute stored and requested in the binary form.

userPKCS12: A format to exchange personal identity information. Use this attribute when information is stored in a directory service.

userSMIMECertificate: PKCS#7 SignedData used to support S/MIME. This value indicates that the content that is signed is ignored by consumers of userSMIMECertificate values.

x500uniqueIdentifier: Distinguishes between objects when a distinguished name has been reused. This is a different attribute type from both the uid and the uniqueIdentifier type.
To add a name:
1. Click New.
2. If you want the attribute to return raw data rather binary data, select 64-bit Encode Attribute Data.
3. Click OK.
To modify the 64-bit attribute data encoding, click an attribute’s check box, then click one of the following links:

Set Encode: Specifies that LDAP returns a raw format of the attribute rather than binary format, which Access Manager encodes to base64, so that the protected resource understands the attribute. You might use base64 encoding if you use certificates that require raw bites rather than binary string format.

Clear Encode: Deletes the 64-bit data encoding setting.
Click Apply to save changes, then click the Servers tab to return to the Servers page.

3.5.5 Adding Authentication Card Images

Each authentication contract and managed card template must have a card associated with it.

To add new images, the image files must be available from the workstation where you are authenticated to the Administration Console. Images must fall within the size bounds of 60 pixels wide by 45 pixels high through 200 pixels wide by 150 pixels high.To add a card image:

In the Administration Console, click Devices > Identity Servers > Shared Settings > Authentication Card Images.
Click New.
Fill in the following fields.

Name: Specify a name for the image.

Description: Describe the image and its purpose.

File: Click Browse, locate the image file, then click Open.

Locale: From the drop-down menu, select the language for the card or select All Locales if the card can be used with all languages.
Click OK.
If you did not specify All Locales for the Locale, continue with Section 3.5.6, Creating an Image Set.

3.5.6 Creating an Image Set

You can create card images for specific locales as well as a default image for all locales. The images need to be placed in an image set that allows the browser to display the image associated with the requested locale. If the browser requests a locale for which you have not defined an image, the All Locales image is displayed. If an All Locales image is not available, the browser displays the Image not Available card.

In the Administration Console, click Devices > Identity Servers > Shared Settings > Authentication Card Images.
Click the card image.
To add an image to the set, click New, then fill in the following fields:

File: Click Browse, then browse to the location of the file.

Locale: Select the locale from the drop-down menu.
Click OK.

3.5.7 Metadata Repositories

Large scale federations have more than 100+ identity and or service providers and it is a tedious task to establish bi-lateral relationships with Access Manager. You as an identity provider can now configure several identity and or service providers using a multi-entity metadata file available in a central repository. The identity and/or service providers become partners of a community which maintains a single metadata file containing metadata of all the approved partners. The identity and or service providers submit their metadata which includes specifications of services offered (SAML 1.1 and SAML 2.0) and any other information. This feature is available only for SAML 1.1 and SAML 2.0.

For example, XYZ is an e-book store and several e-book stores, which are either identity or service providers are partner with it. XYZ maintains a single metadata file containing metadata of all the other stores. ABC an e-book identity provider wants to establish a federation with many other e-book stores. Hence, ABC partners with XYZ by sharing its metadata and XYZ in turn shares the metadata XML file. ABC imports the XML file available publicly on the internet (for example, http://xyz.commonfederation.org/xyz-metadata.xml) and establishes trusts with others in the federation which includes XYZ’s trusted provider sites.

Creating Metadata Repositories

In the Administration Console, click Devices > Identity Servers > Shared Settings > Metadata Repositories.
Click New and fill in the following fields:

Name: Enter the name of the metadata repository.

Description: Enter the description of the metadata repository.

Source: From the drop-down menu, select the source from which you want to import the metadata file.
- To specify the URL location of the XML file in the URL field, select Metadata URL.
- To specify the path of the XML file in the File field, select Metadata File.
Click Finish.

The details of the metadata such as the number of identity servers and service providers present in the metadata, and expiry date of the metadata are displayed.

You can select the metadata repository and click Delete to delete the repository. If the metadata file is in use, you cannot delete it. Delete the trusted provider first and then delete the metadata file.
Select All to see a list of entities. If the entity is supporting it the respective protocol will be checked.

When the metadata repositories are imported, the entities available in the metadata repository can be assigned as trusted provider to any of the Identity Provider clusters. To create trusted providers, see Section 3.9.3, Managing Trusted Providers.

Reimporting Metadata Repositories

You can reimport the metadata repository to get the updated XML.

In the Administration Console, click Devices > Identity Servers > Shared Settings > Metadata Repositories.
Click on the metadata repository you created and click Reimport.
Specify the URL location of the XML file in the URL field and click Next.
The screen displays the following:

New Entities added to the repositories: If the entities are updated or deleted and are assigned as TrustedProviders to an Identity Server cluster then the Identity Server cluster name is displayed in brackets next to the entity ID.

Entities Deleted from the repositories: If the entity is updated and is assigned as a trusted provider to an Identity Server cluster, that trusted provider will be updated. You must update the Identity Server cluster for the changes to take effect.

Entities Updated in the repositories: If an entity is deleted and was assigned as trusted provider to an Identity Server cluster, then the link between the trusted provider and the metadata repository entity is deleted.

NOTE:The corresponding trusted provider is not deleted and you will have to manually delete the trusted provider.
Click Finish to apply the changes.