5.5 External Attribute Source Policy Examples

You can use an External Attribute Source policy to retrieve attributes from external sources. You can create shared secrets from this policy. This shared secret then can be used in configuring other policies or can be used by the Identity Servers in their attribute sets to retrieve attributes from external sources.

An External Attribute Source policy must be enabled and configured before using the policy for retrieving the attributes from external sources.

For more information about how to create an External Attribute Source policy, see Creating External Attribute Source Policies in the NetIQ Access Manager 3.2 SP3 Policy Guide.

This section describe the usages of the External Attribute Source policy with the help of the following scenarios:

For information about sample codes for these examples, see Access Manager SDK Sample Code.

5.5.1 Scenario 1

e_Health is a Web portal for doctors. e_Health uses Med_Association as an external identity provider to verify whether the user is a doctor and obtain the user's professional code and specialization. Med_Association retrieves these details with the help of the NetIQ Identity Server.

Med_Association completes the following steps:

  1. Write an External Attribute data extension class and use the required attribute to retrieve the professional code and specialization of user.

    For more information about data extension class, see Adding Policy Extensions in the NetIQ Access Manager 3.2 SP3 Policy Guide.

    For more information about data extension example code, see The Policy Extension API in the NetIQ Access Manager 3.2 Developer Kit guide.

  2. Create an External Attribute Source policy for the data extension.

    For more information about how to import the data extension class and configure the External Attribute Source policy in the Identity Server, see Configuring an External Attribute Source Policy in the NetIQ Access Manager 3.2 SP3 Policy Guide.

  3. Define a shared secret for the professional code and specialization.

    For more information, see Adding Custom Attributes in the NetIQ Access Manager 3.2 SP3 Identity Server Guide.

  4. Configure this shared secret for a service provider to be sent with authentication.

    For more information, see Configuring the Attributes Sent with Authenticationin the NetIQ Access Manager 3.2 SP3 Identity Server Guide.

  5. The retrieved details that are professional code and specialization are sent to e_Health.

The following diagram illustrates this scenario:

Workflow:

  1. User requests for access to e-Health through browser.

  2. e_Health redirects the user’s browser to the NetIQ Identity Server at Med_Association for authentication.

  3. User logs in with providing credentials. User is authenticated with LDAP.

  4. On the successful authentication, the Identity Server sends the assertion to e_Health.

  5. e_Health verifies the assertion with Med_Association by using the back channel communication.

  6. After verification, the NetIQ Identity Server retrieves the attributes (professional code and specialization) from external sources (for example, database) by using the External Attribute Source policy.

  7. The Identity Server returns the response containing professional code and specialization in a shared secret attribute. If the user is not a doctor, external source returns null values in the shared secret attribute in the response.

    e_Health grants access to the user if it receives valid values for the attributes in the authentication response else it denies the access.

5.5.2 Scenario 2

Company XYZ is a customer of NetIQ Access Manger. The employees of this company get authenticated to the Identity Server. Each employee's mail attribute is retrieved from the user store. XYZ wants only user name part of the email address to be displayed on the Home page after authentication. This can be achieved by using the External Attribute Source policy.

XYZ completes the following steps:

  1. Write an External Attribute data extension class and use the mail attribute as the parameter to the class.

    For more information about data extension class, see Adding Policy Extensionsin the NetIQ Access Manager 3.2 SP3 Policy Guide.

  2. In the data extension class, read the email address and parse the name identifier in it and return as an attribute. For more information about data extension example code and example code for this scenario, see The Policy Extension API in the NetIQ Access Manager 3.2 Developer Kit guide.

  3. Define a shared secret for the name field of the email address.

    For more information, see Adding Custom Attributes in the NetIQ Access Manager 3.2 SP3 Identity Server Guide.

  4. Create an External Attribute Source policy for the data extension.

    For more information about how to import the data extension class and configure the External Attribute Source policy in the Identity Server, see Configuring an External Attribute Source Policy in the NetIQ Access Manager 3.2 SP3 Policy Guide.

  5. Create an Identity Injection policy.

    For more information, see Creating Identity Injection Policiesand Configuring a Custom Header Policy in the NetIQ Access Manager 3.2 SP3 Policy Guide.

  6. The Identity Server sends the user ID part of email address to the Access Gateway.

    In turn, the Access Gateway or service provider sends this attribute to the configured Web server. For example, John is an employee of XYZ. He provides his email address, john@mail-domain.com, as his user name. After authentication, only John will be displayed on the Home page.

The following diagram illustrates this scenario:

Workflow:

  1. User (through the browser) is requesting for a resource. The Access Gateway determines whether it is a protected resource and redirects the request to the Identity Server for authentication. The Identity Server authenticates with the LDAP servers and provides the assertion details to the Access Gateway. In turn, the Access Gateway verifies the assertion details.

  2. The Home page in the resource is configured to display the user ID that has to be retrieved from the Identity Server.

  3. The Identity Server determines whether the attributes can be retrieved from the external source. The Identity Server will send the required details to the external source (in this example, an email address).

  4. The external source returns the data. In this example, user ID part of the email address.

  5. The Identity Server sends the data that it has obtained from the external source to the Access Gateway.

  6. The Access Gateway sends the data to the Web server.

  7. The Web server returns the resource.