5.2 Configuring Federated Authentication

Federation allows a user to associate two accounts with each other. This allows the user to log into one account and access the resources of the other account without logging in to the second account. It is one method for providing single sign-on when a user has accounts in multiple user stores.

5.2.1 Configuring Federation

This section describes what is federation, how to configure federation, and how to set up federation with third-party providers. Topics include:

Understanding a Simple Federation Scenario

Suppose Company A has a centralized user store that does the authentication for most of the company’s internal resources on its inner Web site. But Company A also has a customer feedback application that employees and customers need access to, and for this application, a second user store has been created. This user store contains both employee and customer user accounts. The centralized user store cant be used, because it can contain only employee accounts. This means that the employee must log in to both accounts to access both the inner Web site and the customer feedback application. With federation, the employee can access the resources of both sites by using a single login.

Figure 5-18 illustrates such a network configuration where the user accounts of Site A are configured to federate with the user accounts at Site B.

Figure 5-18 Using Federated Identities

In this configuration, Site A is the Identity Server for the corporate resources, and the employees authenticate to this site and have access to the resources on the Web server with the URL of https://provo.novell.com/inner. Site B is the Identity Server for the Bugzilla application, and both employees and customers authenticate to this site to have access to the resources of the Web server with the URL of https://provo.novell.com/bugz. After an account has been federated, the user can log in to Site A and have access to the resources on the Web servers of both Site A and Site B.

In this scenario, Site B is not as secure a site as Site A, so federation is configured to go only one way, from Site A to Site B. This means that users who log in to Site A have access to the resources at Site A and B, but users who log in to Site B have access only to the resources at Site B. Federation can be configured to go both ways, so that it doesn’t matter whether the user logs into Site A or Site B. When federation is configured to be bidirectional, both sites need to be equally secure.

The Access Gateways in Figure 5-18 are service providers and are configured to use the Identity Servers as identity providers. The trusted relationship is automatically set up for you when you specify authentication settings for the Access Gateway and select an Identity Server Cluster.

Federation can be set up between providers in the same company or between providers of separate companies. For example, most companies have contracts with other companies for their user’s health benefits and retirement accounts. Their users have accounts with these companies. These accounts can be federated with the user’s employee account when both companies agree to set up the trusted relationship.

Configuring Federation

Federation requires the configuration of a trusted relationship between an identity provider and a service provider. Figure 5-19 illustrates setting up federation between two identity servers, because a NetIQ Identity Server can act as either an identity provider or a service provider.

Figure 5-19 Configuring Trust Between Site A and Site B

Site A must be configured to trust Site B as a service provider, and Site B must be configured to trust Site A as an identity provider. Until this two-way trust is established, federation cannot occur.

Before setting up a trusted relationship, you must make the following decisions:

Protocol: The Identity Server supports SAML 1.1, SAML 2.0, and Liberty. You need to decide which of these protocols to use. If no user interaction is needed, SAML 1.1 is probably a good choice. The SAML 2.0 and Liberty protocols permit user interaction when federating. The user decides whether to federate (link) the accounts and must be logged in at both sites to accomplish this. Liberty offers an additional service, not available with SAML 2.0, that allows the user to select attributes that can be shared with the service provider.

The instructions in this documentation, starting in Prerequisites, use the Liberty protocol. They also indicate how to configure for the SAML 2.0 and SAML 1.1 protocols.

Trust Relationship: You need to decide whether the trusted relationship is going to be from Site A to Site B, from Site B to Site A, or bidirectionally from Site A to Site B and from Site B to Site A. Federation is set up to go from the most secure site to the less secure site. The only time federation is set up to be bidirectional is when both sites are equally secure. The scenario described in Figure 5-18 is an example of a trusted relationship that you would want to go only one way, from Site A to Site B, because Site B is not as secure as Site A.

The instructions, starting in Prerequisites, explain how to set up the trusted relationship between Site A and Site B. You can easily modify them to set up the bidirectional trust relationships by substituting Site B for Site A (and vice versa) in the instructions and then repeating them for Site B

Attributes to Share: You need to decide whether there are user attributes or roles at Site A that you want to share with Site B. The attributes from Site A can be used to identify the users at Site B. Other attributes might be needed to access protected resources, for example, to satisfy the requirements of an Identity Injection policy.

For all the protocols, Sharing Roles explains how to share the roles at Site A with Site B. For the SAML 1.1 protocol, the instructions starting in Prerequisites use the LDAP mail attribute to share the user’s e-mail address.

User Identification: You need to decide how assertions can be used to map users from Site A to users at Site B. The Identity Server supports four methods:

  • Temporary: This method allows the user access to Site B solely from the credentials of Site A. No effort is made to map the user to a user account at Site B. A temporary account is set up for the user on Site B, and when the user logs out, the account is destroyed.

  • Login: This method requires that the user have login credentials at both Site A and Site B, and when logged in at both sites, the user can select to federate the accounts.

  • Mapped Attributes: This method requires that the sites share attributes and that these attributes are used to create a matching expression that determines whether the user accounts match. For an added security check, the first time the accounts are matched, the user is asked to verify the match by supplying the password for Site B.

    If the match fails, you can allow the federation to fail or you can configure the method to allow the user to use the Login method or the Provisioning method.

  • Provisioning: This method allows the user to create a new, permanent account at Site B.

The configuration instructions, starting in Prerequisites, use the Login method for the SAML 2.0 and Liberty protocols and Mapped Attributes method for the SAML 1.1 protocol.

The instruction for setting up a trusted relationship between two NetIQ Identity Servers have been divided as follows:

Prerequisites

Establishing Trust between Providers

To set up this very basic example of federation, complete the following tasks.

Configuring Site A to Trust Site B as a Service Provider

To establish trust between Site A and Site B, you must perform two tasks:

  • The providers must trust the certificates of each other so you need to import the trusted root certificate of Site B to Site A.

  • You must also import the metadata of Site B to Site A. The metadata allows Site A to verify that Site B is truly Site B when Site B sends a request to Site A.

The following instructions explain how to import the certificate and the metadata:

  1. Log in to the Administration Console for Site A.

    The configuration for Site A can be created in the same Administration Console as Site B; it cannot be configured to be a cluster member of Site B.

  2. Import the trusted root certificate of Site B into the NIDP trust store of Site A:

    1. Click Devices > Identity Servers > Edit > Security > NIDP Trust Store.

    2. In the Trusted Roots section, click Auto-Import From Server, then fill the following fields:

      Server IP/DNS: Specify the IP address or DNS name of Site B. For Site B in Figure 5-19 specify the following:

      idp.siteb.novell.com

      Server Port: Specify 8443.

    3. Click OK, then specify an alias for the certificate (for example, SiteB).

      You will get two certificate options: Root CA Certificate andServer certificate. We recommend you to select Root CA Certificate.

    4. Examine the trusted root that is selected for you.

      If the trusted root is part of a chain, make sure you select the parent and all intermediate trusted roots.

    5. Click OK.

      The trusted root certificate of Site B is added to the NIDP trust store.

    6. Click Close.

    7. Click Devices > Identity Servers, then update the Identity Server.

      Wait for the health status to return to green.

  3. Configure a service provider for Site A:

    1. Click Identity Servers > Edit > Liberty [or SAML 2.0 or SAML 1.1].

    2. Click New, select Service Provider, then fill the following fields:

      Name: Specify a name for the provider. If you plan on configuring more than one protocol, include the protocol as part of the name, such as, SiteB_Liberty

      Metadata URL: Specify the URL of the Liberty metadata on Site B. For Site B in Figure 5-19, specify the following: 

      http://idp.siteb.novell.com:8080/nidp/idff/metadata

      This example uses port 8080 to avoid any potential certificate problems that occur when the Identity Server and the Administration Console are installed on separate machines.

      SAML 2.0: If you are using SAML 2.0, the metadata path is /nidp/saml2/metadata. For Site B in Figure 5-19, specify the following for SAML 2.0:

      http://idp.siteb.novell.com:8080/nidp/saml2/metadata

      SAML 1.1: If you are using SAML 1.1, the metadata path is /nidp/saml/metadata. For Site B in Figure 5-19, specify the following for SAML 1.1:

      http://idp.siteb.novell.com:8080/nidp/saml/metadata

    3. Click Next > Finish > OK.

    4. Update the Identity Server.

      Wait for the health status to return to green.

  4. Continue with Configuring Site B to Trust Site A as an Identity Provider.

Configuring Site B to Trust Site A as an Identity Provider

The following instructions explain how to import the trusted root certificate and metadata of Site A into the configuration for Site B.

  1. Log in to the Administration Console for Site B.

    The configuration of Site B can be created in the same Administration Console as Site A; it cannot be configured to be a cluster member of Site A.

  2. Import the trusted root certificate of Site A into the NIDP trust store of Site B.

    1. Click Devices > Identity Servers > Edit > Security > NIDP Trust Store.

    2. In the Trusted Roots section, click Auto-Import From Server, then fill the following fields:

      Server IP/DNS: Specify the IP address or DNS name of Site A. For Site A in Figure 5-19, specify the following:

      idp.sitea.novell.com

      Server Port: Specify 8443.

    3. Click OK, then specify an alias for the certificate (for example, SiteA).

      You will get two certificate options: Root CA Certificate andServer certificate. We recommend you to select Root CA Certificate.

    4. Examine the trusted root that is selected for you.

      If the trusted root is part of a chain, make sure you select the parent and all intermediate trusted roots.

    5. Click OK.

      The trusted root certificate of Site A is added to the NIDP trust store.

    6. Click Close.

    7. Click Identity Servers > Update > OK.

      Wait for the health status to return to green.

  3. Configure an identity provider for Site B.

    1. Click Identity Servers > Edit > Liberty [or SAML 2.0 or SAML 1.1].

    2. Click New, select Identity Provider, then fill the following fields:

      Name: Specify a name for the provider. If you plan on configuring more than one protocol, include the protocol as part of the name, such as SiteA_Liberty

      Metadata URL: Specify the URL of the Liberty metadata on Site A. For Site A in Figure 5-19, specify the following: 

      http://idp.sitea.novell.com:8080/nidp/idff/metadata

      This example uses port 8080 to avoid any potential certificate problems that occur when the Identity Server and the Administration Console are installed on separate machines.

      SAML 2.0: If you are using SAML 2.0, the metadata path is /nidp/saml2/metadata. For Site A in Figure 5-19, specify the following for SAML 2.0:

      http://idp.sitea.novell.com:8080/nidp/saml2/metadata

      SAML 1.1: If you are using SAML 1.1, the metadata path is /nidp/saml/metadata. For Site B in Figure 5-19, specify the following for SAML 1.1:

      http://idp.siteb.novell.com:8080/nidp/saml/metadata

    3. Click Next.

    4. To configure an authentication card, fill in the following:

      ID: (Optional) Specify an alphanumeric number that identifies the card. If you need to reference this card outside of the Administration Console, you need to specify a value here. If you do not assign a value, the Identity Server creates one for its internal use.

      Text: Specify the text that is displayed on the card to the user

      Image: Specify the image to be displayed on the card. Select the image from the drop down list. To add an image to the list, click Select local image.

      Login URL: (Conditional) If you are configuring an authentication card for SAML 1.1, specify an Intersite Transfer Service URL. For Figure 5-18, specify the following value:

      https://idp.sitea.novell.com:8443/nidp/saml/idpsend?PID=https://idp.siteb.novell.com:8443/nidp/saml/metadata&TARGET=https://idp.siteb.novell.com:8443/nidp/app

      For more information, see Specifying the Intersite Transfer Service URL for the Login URL Option.

      Show Card: Determine whether the card is shown to the user. If this option is not selected, the card is only used when a service provider makes a request for the card. For this scenario, select this option.

      Passive Authentication Only: Do not select this option.

    5. Click Finish > OK.

    6. Update the Identity Server.

      Wait for the health status to return to green.

  4. Continue with one of the following:

Verifying the Trust Relationship

Before continuing with federation configuration, you need to verify that Site A and Site B trust each other.

  1. To test the trusted relationship, log in to the user portal of Site B. For Site B in Figure 5-19, specify the following:

    https://idp.siteb.novell.com:8443/nidp/app

    The following login screen appears.

    In this configuration, the customizable image was used for the Liberty authentication card.

  2. Click the Liberty (or SAML 2.0) authentication card.

    You are directed to Site A for login, with the default card selected for you. A screen similar to the following appears:

  3. Enter the credentials for a user from Site A.

    The Federation consent prompt appears.

  4. Click Yes.

    You are returned to the login page for Site B.

  5. Enter the credentials of a user from Site B that you want to federate with the user from Site A.

    These two accounts are now federated. You can enter the URL to the user portal on Site A or Site B, and you are granted access without logging in again.

    If you log out and log back in, the accounts are still federated, but you might be prompted for login credentials as you access resources on Site A and Site B. To enable a single sign-on experience, the Identity Server at Site A, the Identity Server at Site B, and the protected resources of the Access Gateways must be configured to share a contract.

  6. To enable a single sign-on experience, continue with Configuring User Authentication.

Configuring User Authentication

The following instructions describe one way to enable single sign-on to the Identity Servers and Access Gateways in Figure 5-18. It explains how to configure all sites to use the same contract. The instructions explain the following tasks:

  • Selecting the contract for federation

  • Configuring the contract at Site B to allow authentication at Site A

  • Configuring Site A so its contract can satisfy the requirements of the contract at Site B

  • Configuring Site A and Site B to use this contract as their default contract

To configure the contracts:

  1. Log in to the Administration Console for Site B.

  2. Configure the authentication request:

    1. Click Devices > Identity Servers > Edit > Liberty [or SAML 2.0] > [Name of Identity Provider] > Authentication Card > Authentication Request.

    2. (Liberty) Verify the settings of the following fields:

      Allow federation: Make sure this option is selected. If this option is not selected, users cannot federate their accounts at Site A with an account at Site B.

      After authentication: Make sure this option is selected. Enabling this option assumes that a user account exists at the service provider and that the account can be associated with a user’s account at the identity provider.

      During authentication: Make sure this option is selected. Enabling this option allows federation to occur when the user selects the authentication card of the identity provider.

    3. (SAML 2.0) Verify the settings of the following fields:

      Persistent: Select this option to set up a persistent relationship between the two accounts.

      After authentication: Make sure this option is selected. Enabling this option assumes that a user account exists at the service provider and that the account can be associated with a user’s account at the identity provider after authentication.

      During authentication: Make sure this option is selected. Enabling this option allows federation to occur when the user selects the authentication card of the identity provider.

    4. For Requested By, select Use Contracts.

    5. (SAML 2.0) For Context Comparison, accept the default value of Exact.

    6. In the Authentication contracts section, select the name of the contract used by the protected resources and move it to the Contracts section.

      If the contract you require is not in the list, it has not been configured for federation. See step 3.

    7. Click OK, then update the Identity Server configuration.

  3. (Conditional) Configure the contract at Site B to allow federation:

    1. Click Identity Servers > Edit > Local > Contracts.

    2. Record the URI for the contract you are using. This URI needs to exist as a contract on Site A. The name of the contract can be different at each site, but the URI must be the same.

      NOTE:If site A only understands authentication class or type, select Use Types in the Requested By field and specify the authentication class in the Allowable Class field. Record the allowable class for the contract you are using. This allowable class should exist as a contract on site B. The name of the contract can be different at each site, but the allowable class must be the same.

    3. Click the name of the contract.

    4. Make sure the Satisfiable by External Provider option is selected.

    5. Click OK twice, then update the Identity Server if you made any changes.

    6. Return to Step 2 to select the contract.

  4. If Site A is configured as a SAML 2.0 identity provider, move the contract(s) from the Available contracts list to the Satisfies contract list.

    This will automatically redirect the authentication request from Site B to Site A when this contract is executed. Note that you can have multiple contracts in the Satisfies contract list.

  5. Verify that Site A contains the same contract:.

    1. Log in to the Administration Console for Site A.

    2. Click Identity Servers > Edit > Local > Contracts.

    3. Match the URI from step 3b to a contract.

      NOTE:Match the allowable class if you have selected Use Types in the Requested By field at site B.

      If such a contract does not exist, you need to create it. For help, see Section 5.1.4, Configuring Authentication Contracts.

    4. Click OK.

  6. In the Administration Console for Site A, click Identity Servers > Edit > Local > Defaults.

  7. For the Authentication Contract, select the name of the contract from step 5c.

  8. (Conditional) If you have multiple user stores, set the default contract for each user store.

  9. Click OK, then update the Identity Server.

  10. Test the configuration:

    1. Enter the URL to the user portal of Site B.

    2. Click the federated login link to Site A.

    3. Enter the credentials for Site A and log in.

    4. Enter the URL for a protected resource at Site B.

      You are granted access without being prompted for credentials.

  11. If you want to allow federated users to log in at Site A rather than using the card at Site B to redirect them to Site A, complete the following tasks:

    1. In the Administration Console for Site B, click Devices > Identity Servers > Edit > Local > Defaults.

    2. For the Authentication Contract, select the name of the contract whose URI matches the URI of the contract used by Site A.

    3. Click Liberty [or SAML 2.0] > [Name of Identity Provider] > Authentication Card > Authentication Request.

    4. In the Options section, enable the Use automatic introduction option.

      This enables single sign-on to Site B when the user has already federated the accounts at the two sites.

    5. Click OK, then update the Identity Server.

    6. To test single sign-on, log in to the user portal on Site A, then enter a URL for a protected resource at Site B.

Configuring SAML 1.1 for Account Federation

SAML 1.1 does not support user-controlled federation, but you can configure it so that accounts that match are automatically federated. The Liberty and SAML 2.0 protocols allow users to federate accounts without sharing any common attributes, but the SAML 1.1 protocol requires that the user accounts need to share some common attributes in order for SAML 1.1 to match them and allow federation.

Configuring User Account Matching

When federating with SAML 1.1, the security of a user matching method depends upon the accuracy of the mapping. You need to select an attribute or attributes that uniquely identify the user at both Site A and Site B. The attributes must identify only one user at Site A and match only one user at Site B. If the attributes match multiple users, you have a security problem,

The following steps use the e-mail address of the user and the LDAP mail attribute to set up a matching rule that matches one user account at Site A with one user account at Site B. To securely use such a matching rule, you need to have a rule in place at both Site A and Site B to ensure that all users have unique e-mail addresses.

Configuring Site B for User Account Matching

  1. In the Administration Console of Site B, click Devices > Identity Servers > Servers > Edit > SAML 1.1 > [Identity Provider] > User Identification.

  2. For the Satisfies contract option, select the contract that you want to use for single sign-on.

    For this example, select Secure Name/Password-Form.

  3. Select Attribute matching.

    The Prompt for password on successful match option is automatically selected. Leave this option enabled.

  4. Click the Define Attribute Matching Settings icon.

  5. Move the user store that you want to search for the attribute to the User stores list.

  6. For the User Matching Expression, select New User Matching Expression.

  7. Specify a name for the matching expression, such as email.

  8. In Logic Group 1, click the Add Attributes icon, select Ldap Attribute:mail [LDAP Attribute Profile], then click OK.

    The form allows you to create a very complex set of matching rules, with multiple conditions. This example uses one attribute, the simplest form of a matching expression.

  9. Click Finish, then select your matching expression for the User Matching Expression.

  10. Click OK.

  11. Click OK twice, then update the Identity Server.

  12. Continue with Configuring the Attribute for Sharing.

Configuring the Attribute for Sharing

  1. In the Administration Console of the Site B (the service provider), click Devices > Identity Servers > Shared Settings.

  2. Click Attribute Sets, then click New.

  3. Specify a Set Name, such as email, then click Next.

  4. Click New, then fill the Add Attribute Mapping options:

    Local attribute: Select Ldap Attribute:mail [LDAP Attribute Profile].

    Remote attribute: Specify a name, such as email. Make sure you use the same remote name in the mapping for both Site B and Site A.

    Leave the other options set to their default values.

  5. Click OK, then click Finish.

    Your newly created attribute mapping appears in the list of Attribute Sets.

  6. Repeat step1 through step 5 for Site A (the identity provider).

    If Site A and Site B are imported into the same Administration Console, skip this step.

  7. Continue with Configuring the Providers to Use the Shared Attribute.

Configuring the Providers to Use the Shared Attribute

You need to configure Site A to send the shared attribute with the authentication credentials, and you need to configure Site B to process the shared attribute that is included with the authentication credentials.

  1. In the Administration Console for Site B, click Devices > Identity Servers > Edit > SAML 1.1 > [Name of Identity Provider] > Attributes.

  2. For the Attribute set, select the set name you created in Configuring the Attribute for Sharing.

  3. Move the email attribute so that it is obtained at authentication.

  4. Click OK twice, then update the Identity Server.

  5. In the Administration Console for Site A, click Devices > Identity Servers > Edit > SAML 1.1 > [Name of Service Provider] > Attributes.

  6. For the Attribute set, select the set name you created in Configuring the Attribute for Sharing.

  7. Move the email attribute so that it is sent with authentication.

  8. Click OK twice, then update the Identity Server.

  9. Continue with Configuring the Default Contract for Single Sign-On

Configuring the Default Contract for Single Sign-On

The Identity Servers at Site A and Site B need to use the contract you specified in your user matching expression to be the default contract for Site A, Site B, and the protected resources of the Access Gateway.

For the user matching expression contract, see step 2 in Configuring Site B for User Account Matching.

To configure the default contracts for Site A and Site B:

  1. In the Administration Console for Site B, click Devices > Identity Servers > Edit > Local > Defaults.

  2. For the Authentication Contract, select the name of the contract used by the user matching expression.

  3. Click OK, then update the Identity Server.

  4. For Site A, repeat step 1 through step 3.

  5. For the Access Gateway, review the contracts you have assigned to the protected resources:

    1. In the Administration Console for Site B, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected Resources.

    2. For single sign-on, change the contract to match the contract for the user matching expression.

    3. (Conditional) If you have multiple reverse proxies and proxy services, verify the contracts on all protected services that you want enabled for single sign-on.

    4. Click OK to save your changes, then update the Access Gateway.

  6. Continue with Verifying the Trust Relationship with SAML 1.1.

Verifying the Trust Relationship with SAML 1.1

  1. To test the trusted relationship, enter the URL for the user portal of Site B. For Site B in Figure 5-19, you would specify the following:

    https://idp.siteb.novell.com:8443/nidp/app

    The following login screen appears:

    Use the scroll bar to see all available cards.

  2. Click the card you have configured for SAML 1.1 authentication.

    You are directed to Site A for login.

  3. Enter the credentials for Site A.

  4. Enter the password for the user at Site B.

    You are directed to the target page specified in the Login URL of the authentication card.

    If you disabled the Prompt for password on successful match option on the User Identification page, the accounts are mapped without any user interaction.

  5. (Conditional) If you receive an error, try one of the following:

    • If you are not redirected to the target URL on Site B, verify the value you enter for the Login URL option. See Step 3.d.

    • If you receive an authentication error at Site B, verify the user matching setup. See Configuring User Account Matching.

    • If you have enabled logging, open the logging file (catalina.out or stdout.log) and search for the error string. There should be additional information about the cause of the error in the error string entry as well as log entries before the error sting.

  6. (Optional) If your protected resources on Site A and Site B use the same contract, enter the URLs of these resources.

    You are granted access without entering any additional credentials.

Sharing Roles

When two Identity Servers are configured to trust each other, one as an identity provider and the other as a service provider, they can be configured so that roles are shared. The following instructions are written for when both the identity provider and the service provider are NetIQ Identity Servers. If you are using a third-party identity or service providers, you need to modify the instructions.

Figure 5-20 illustrates a configuration where Identity Server of Site A is acting as an identity provider for Site B. When you configure the Identity Servers correctly, the Access Gateway can use the roles defined for the users of Site A in its policies.

Figure 5-20 Two Federated Identity Servers

The key to sharing roles is to set up the configuration so that the SAML assertion that the identity provider (Site A) sends to the service provider (Site B) contains the roles that the user has been assigned. Site B evaluates the roles and assigns them to the federated users at Site B. The Access Gateway can use these roles in its policy evaluations, and grant or deny access based on the assigned roles.

For example, when user tsmith authenticates to Site A, tsmith is assigned the role of doc. Tom, a user at Site B, is federated with the tsmith user. The doc role is shared with Site B, and Site B contains a policy that assigns users with the shared doc role to the tester role. The Access Gateway is configured with an Authorization policy that grants access to a resource when the requester is assigned the tester role. However, Tom does not have the qualifications at Site B to be assigned the tester role.

In this scenario, when Tom requests access to the protected resource at Site B, a login page with a federated link to Site A is displayed. If Tom selects to log in to Site A, Site A assigns him to the doc role. The doc role is sent with tsmith’s authentication credentials to Site B. Site B evaluates the credentials and assigns Tom to the tester role because the following conditions are met:

  • Tom is federated with tsmith.

  • tsmith was assigned the doc role.

  • The shared role and tester policies on Site B qualify the user to be assigned the tester role.

When the Access Gateway evaluates the credentials of Tom, Tom is granted access to the protected resource because he now has the tester role.

This section describes how to set up such a configuration. It assumes that the following have already been done:

This section explains how to configure Site A and Site B so that Site A shares its roles with Site B.

Configuring Role Sharing

There are three major tasks for configuring role sharing. You need to configure a shared attribute for transferring the roles. You need to configure the identity provider and the service provider so that the role assignments can be added to the attribute and retrieved from the attribute. Finally, you need to create a shared Role policy for each role sent to the service provider. This policy defines how the role should be processed.

The following sections describe these configuration tasks:

Defining a Shared Attribute Set

  1. In the Administration Console of the Site A (the identity provider), click Devices > Identity Servers > Shared Settings.

  2. Click Attribute Sets, then New.

  3. Specify a Set Name, such as role_sharing, then click Next.

  4. Click New and fill the Add Attribute Mapping options:

    Local attribute: Select All Roles.

    Remote attribute: Specify a name, such as roles. Make sure you use the same remote name in the mapping for both the identity provider and the service provider.

    Leave the other options set to their default values.

  5. Click OK, then click Finish.

    Your newly created attribute mapping appears in the list of Attribute Sets.

  6. Repeat Step 1 through Step 5 on Site B (the service provider).

  7. Continue with Obtaining the Role Assignments.

Obtaining the Role Assignments

  1. To export the roles from the identity provider, log in to the Administration Console for the identity provider. (In Figure 5-20, this is Site A.)

    1. Click Devices > Identity Servers > Edit > Liberty > [Name of Service Provider] > Attributes.

      If you are using SAML 2.0 or SAML 1.1 protocol, the steps are the same. You just need to click the appropriate tab after clicking Edit. The path is the same for these protocols.

    2. Select the attribute set you created, then move All Roles so this attribute is sent with authentication.

    3. Click OK.

    4. Update the Identity Server of Site A.

  2. To import the roles from the identity provider to the service provider, log in to the Administration Console for the service provider. (In Figure Figure 5-20, this is Site B.)

    1. Click Devices > Identity Servers > Edit > Liberty > [Name of Identity Provider]> Attributes.

    2. Select the attribute set you created, then move All Roles so this attribute is obtained with authentication.

    3. Click OK.

    4. Update the Identity Server of Site B.

    5. Continue with Configuring Policies to Process Received Roles.

Configuring Policies to Process Received Roles

For each role that is sent from Site A, you need to create a Role policy that specifies the role that should be activated on Site B. For example, suppose the tsmith user from Site A is assigned the doc role at authentication. You can create a Role policy on Site B that assigns the tester role to anyone with the doc role from Site A.

  1. Log in to the Administration Console for Site B.

  2. Click Policies > Policies > New.

  3. Specify a name for the policy, select Identity Server: Roles for the type, then click OK.

  4. In the Condition Group 1 section, click New, then select Roles from Identity Provider.

  5. (Conditional) If you have federated with more than one identity provider, select the provider. If you have federated with only one identity provider, the provider is selected for you.

    In this example, you have federated with only the identity provider at Site A, and it is selected for you.

  6. For the value, select Data Entry Field, then specify the name of a role that is assigned by Site A, for example doc.

    If you leave Mode set to Case Sensitive, make sure you specify the case correctly.

  7. In the Actions section, specify the role to activate on Site B for the role received from Site A.

    Your policy should look similar to the following:

  8. Click OK twice, then click Apply Changes.

  9. To enable the role for the Identity Server, click Identity Servers > Edit > Roles.

  10. Select the role, then click Enable.

  11. (Optional) Repeat Step 2 through Step 10 for other roles assigned at Site A.

    If you have other Role policies at Site A, you need to set up Role policies at Site B to have the roles activated. For example, if Site A had a Tester Role policy and you wanted users assigned to the Tester Role policy to also be assigned to the Tester Role policy at Site B, you could create a separate policy for this activation, or you could add an Or condition group with a value field of tester to the policy in Step 7. The policy would assign federated users who belonged to the doc or tester roles at Site A, to the tester role at Site B.

  12. To test role sharing:

    1. Enter the URL of a protected resource that requires a role for access. For the policy above, it would be a resource requiring the tester role.

    2. Click the federated link to Site A.

    3. Log in with the credentials of a user who is assigned the doc role.

      You are granted access to the resource. If you are denied access, continue with Verifying the Configuration to discover the problem.

Verifying the Configuration

This section traces the role assignment from the Identity Server that assigns it to the user, through the Identity Server that receives the roles with the user’s authentication assertion, to the policy evaluation. If you are having trouble, this should help you determine the source of the problem.

The following procedures refer to the configuration displayed in Figure 5-20, Two Federated Identity Servers. A tsmith user from Site A, who is assigned the doc role, is federated with a Tom user at Site B. Site B does not assign Tom the tester role. The Web server has been configured to protect the bugz site, which requires the tester role.

To verify the configuration:

  1. Make sure policy logging is enabled on the identity provider and the service provider. Make sure that you enable at least Application logging at an Info level.

    For configuration procedures, see Section 17.3.1, Configuring Logging for Identity Server.

    You can access log files for downloading and viewing by clicking Auditing > General Logging.

  2. Have a user access a resource that is protected by a policy requiring a role from Site A.

    For this trace, the tsmith user from Site A requests access to the bugz page. The user uses the federated link and logs in with the credentials of the tsmith user.

  3. Verify that Site A is assigning the user the role.

    1. View the catalina.out file (Linux) or the stdout.log file (Windows) of the Identity Server at Site A.

    2. Search for the name of the role. You should find a line similar to the following:

      <amLogEntry> 2009-08-22T20:30:19Z INFO NIDS Application: AM#500105013: AMDEVICEID#C5F467BA50B009AC: AMAUTHID#DEEF6BEC3655DEB71CA56832DDDF866E: Authenticated user cn=tsmith,o=novell in User Store sitea-nids-user-store with roles doc,authenticated. </amLogEntry>

      If the role you need is not listed, look at the policy evaluation trace to discover why the user has not been assigned the role. For more information about how to understand role traces, see Role Assignment Traces.

  4. Verify that Site A is sending an authentication assertion to Site B.

    In the catalina.out file (Linux) or the stdout.log file (Windows) of the Identity Server from Site A, look for lines similar to the following:

    <amLogEntry> 2009-08-22T20:30:19Z INFO NIDS Application: AM#500105018: AMDEVICEID#C5F467BA50B009AC: AMAUTHID#DEEF6BEC3655DEB71CA56832DDDF866E: Responding to AuthnRequest with artifact AAPLsCVpfv3ha9Mpn+cUiCXcf3D63sc0QfscL5mZaaygHBKVOOh9aPSQ </amLogEntry>

<amLogEntry> 2009-08-22T20:30:19Z INFO NIDS Application: AM#500105019: AMDEVICEID#C5F467BA50B009AC: AMAUTHID#F8B1C147EB3DDEFE9A3DB0827BA8E4A3: Sending AuthnResponse in response to artifact AAPLsCVpfv3ha9Mpn+cUiCXcf3D63sc0QfscL5mZaaygHBKVOOh9aPSQ </amLogEntry>

    If you do not see these types of entries, verify that you have configured Site A to send the roles. See Obtaining the Role Assignments.

  5. Verify that Site B is receiving the SAML assertion with the roles.

    In the catalina.out file (Linux) or the stdout.log file (Windows) of the Identity Server from Site B, look for lines similar to the following:

    <amLogEntry> 2009-08-22T20:30:19Z INFO NIDS Application: AM#500105020: AMDEVICEID#488475009C6D3DDF: AMAUTHID#0FBA0CF7E41E6C7F9121DABB918D34F4: Received and processing artifact from IDP - AAPLsCVpfv3ha9Mpn+cUiCXcf3D63sc0QfscL5mZaaygHBKVOOh9aPSQ </amLogEntry>

<amLogEntry> 2009-08-22T20:30:19Z INFO NIDS Application: AM#500105021: AMDEVICEID#488475009C6D3DDF: AMAUTHID#0FBA0CF7E41E6C7F9121DABB918D34F4: Sending artifact AAPLsCVpfv3ha9Mpn+cUiCXcf3D63sc0QfscL5mZaaygHBKVOOh9aPSQ to URL https://rholm.provo.novell.com:8443/nidp/idff/soap at IDP </amLogEntry>

    The artifact ID should be the same as the artifact ID in Step 4.

    If you do not see these types of entries, verify that you have configured Site B to receive the roles. See Obtaining the Role Assignments.

  6. Verify that Site B is evaluating the received role assignments and activating the roles.

    In the catalina.out file (Linux) or the stdout.log file (Windows) of the Identity Server from Site B, search for a policy evaluation for RolesFromIdentityProvider. You should find lines similar to the following: 

    ~~CO~1~RolesFromIdentityProvider(6670):https://ipd.sitea.provo.novell.com:
8443/nidp/idff/metadata:TESTER,DOC,AUTHENTICATED~com.novell.nxpe.condition.
NxpeOperator@string-equals~(0):hidden-param:hidden-value:~~~True(69)

~~PA~ActionID_1203705845727~~AddRole~tester~~~Success(0)

<amLogEntry> 2009-08-22T20:30:20Z INFO NIDS Application: AM#500105013: AMDEVICEID#488475009C6D3DDF: AMAUTHID#0FBA0CF7E41E6C7F9121DABB918D34F4: Authenticated user cn=Tom,o=novell in User Store Internal with roles tester,authenticated. </amLogEntry>

    The policy evaluation shows that the condition evaluates to true and that the tester role is activated. Tom is the user that is federated with the tsmith user, and the entry shows that Tom has been assigned the tester role.

    If you do not see a policy evaluation for RolesFromIdentityProvider, make sure you have created such a Role policy and that you have enabled it. See Configuring Policies to Process Received Roles.

  7. If the use has been assigned the correct role, the last step is to verify how the embedded service provider evaluated the policy protecting the resource.

    In the catatina.out file of the ipd-esp file for the Access Gateway, search for lines similar to the following for the authorization policy trace:

    <amLogEntry> 2009-08-22T20:30:20Z INFO NIDS Application: AM#501102050: AMDEVICEID#esp-2559E77C93738D15: AMAUTHID#BCF3CB40B51E8A0AF8582BEF762B4DDD: PolicyID#65LN233O-KN19-1L7M-176M-P942LMN6P832: NXPESID#1411: AGAuthorization Policy Trace:
 ~~RL~1~~~~Rule Count: 2~~Success(0)
 ~~RU~RuleID_1198874340999~Allow_Tester~DNF~~1:1~~Success(0)
 ~~CS~1~~ANDs~~1~~True(69)
 ~~CO~1~CurrentRoles(6660):no-param:TESTER,AUTHENTICATED~com. novell.nxpe.condition.NxpeOperator@string-substring~SelectedRole (6661):hidden-param:hidden-value:~~~True(69)
 ~~PA~1~~Permit Access~~~~Success(0)
 ~~PC~1~~Document=(ou=xpemlPEP,ou=mastercdn,ou=ContentPublisher Container,ou=Partition,ou=PartitionsContainer,ou=VCDN_Root,ou=accessManagerContainer,o=novell:romaContentCollectionXMLDoc),Policy=(Allow_Tester),Rule=(1::RuleID_1198874340999),Action=(Permit::1)~~~~Success(0)
 </amLogEntry>

    If the PA line does not evaluate to Permit Access, then you need to review the Authorization policy and discover the conditions, other than the tester role, that must be met to permit access.

Setting Up Federation with Third-Party Providers

Setting up federation with providers other than NetIQ Identity Servers requires the same basic tasks as setting up federation with NetIQ Identity Servers, with some modifications.

When you set up federation with identity providers and service providers that are controlled by a single company, you have access to the Administration Consoles for both Identity Servers and know the admin credentials. When setting up federation with another company, additional steps are required.

  • You need to negotiate with the other company and gain approval for federation because metadata must be shared and both sites require configuration. You need to negotiate a schedule for these configuration changes.

  • The other site might not be using Access Manager for its identity or service provider. The basic tasks need to be modified to accommodate how that implementation shares metadata, authentication methods, and roles.

  • Many SAML 1.1 providers do not support a metadata URL, and the data must be imported manually.

    For example, instead of sharing URLs that allow you to import metadata, you might need to share the actual metadata and paste it into the configuration. The NetIQ Identity Server validates the metadata of another identity provider or service provider; some implementations do not validate it. If the Identity Server determines that the metadata is invalid, you need to negotiate with the provider to send you metadata that has been validated.

  • Most third-party providers do not support authentication cards and contracts. However, most do support either authentication types or authentication URIs. You can use either of these to map from their authentication procedure to an Identity Server authentication contract.

For sample implementations with third-party providers that explain the modifications that were required to set up the federation, see the following:

5.2.2 Service Provider Brokering

The Service Provider Brokering (SP Brokering) feature enables the Identity Server to act as a federation gateway or a service provider broker. This federation gateway allows you to connect to different protocols such as Liberty, SAML 1.1, and SAML 2.0. You can use SP Brokering with the Intersite Transfer service of the identity provider. Intersite Transfer service enables authentication at a trusted service provider.SP Brokering helps companies establish trust between identity providers and their service providers that support different federation protocols. For example, an identity provider that supports SAML 2.0 can provide authentication to a Liberty or SAML 1.1 service provider by using SP broker.

SP Brokering helps reduce the number of trust relationships between an identity provider and their service provider. For example, identity providers can now provide authentication to their service providers by establishing a single trust relationship instead of multiple trust relationships. Similarly, a service provider must establish a single trust relationship with SP Broker to receive authentication from several identity providers.

You can control the authentication flow between several identity providers and service providers in a federation circle by allowing the administrator to configure policies that control Intersite Transfers. For example, an administrator can configure a policy with SP Broker that allows only certain users from an identity provider to be authenticated at a given service provider.

An Intersite Transfer URL has the following format: https://<identity provider>/idpsend?PID=<Service Provider ID>&TARGET=<final_destination_URL>

This Intersite Transfer URL consists of three parts:

  • https://<identity provider>: The user can authenticate at the identity provider.

  • /idpsend?PID=<Service Provider ID>: Authentication occurs at the service provider represented by the service provider ID at the identity provider.

  • &TARGET=<final_destination_URL: The user is finally redirected to the specified target URL associated with the service provider.

A Web page is created with many Intersite Transfer URLs for each combination of identity provider, service provider, and the target application.

For more information about the Intersite Transfer Service, see Section 3.9.10, Using the Intersite Transfer Service.

This following illustration explains the flow of providing access to the target URL by using SP Brokering:

Web Page (User Portal): A Web page (user portal) is created with a list of URLs called Brokered URLs, which provide access to various target applications.

Originating Identity Providers: The Originating Identity Provider is the identity provider with which the user credentials are stored for authentication. The Origin IDP must be configured as a Liberty/SAML1.1/SAML2.0 trusted identity provider in the SP Broker.

Federation Gateway or SP Broker: The Federation Gateway or SP Broker is a NetIQ identity provider that can be configured to control the authentication between several Origin IDPs and Allowed SPs in a federation circle.

Allowed Service Provider: The Allowed SP is the service provider in which the SP Broker provides authentication. The allowed SP must be configured as a Liberty/SAML1.1/SAML2.0 trusted service provider on SP Broker.

Target Application: The target application is the application running on a Web Sever that is protected by the service provider.

Broker URL: A Broker URL is a specially designed Intersite Transfer URL, which consists of four parts. You can click the brokered URL, which results in the following:

  1. You must authenticate with the Originating IDP (https://idp1.com/idpsend).

  2. The Origin IDP causes an authentication to occur at the SP Broker (?PID=SPBroker).

  3. The SP Broker causes an authentication to occur at the allowed SP (TARGET=https://spbroker.com/idpsend?PID=SP1).

  4. You are redirected to the target application (?TARGET=TARGET1).

SP Brokering requests are the Intersite Transfers resulting from brokered URLs processed on the SP Broker. The SP Broker can control the brokering requests before providing an authentication to the service provider. The SP Broker enforces the policies configured by the administrator by either causing the authentication at the service provider or by denying the request.

The SP Broker provides the following options to configure policies that control SP brokering requests:

  1. A set of SAML 1.1, SAML 2.0 and Liberty trusted identity providers and trusted service providers can be configured as a brokering group. The brokering request is allowed only if the Origin identity provider and Allowed service provider belong to the same brokering group. Brokering Request is not allowed from an Origin identity provider of one group to an Allowed service provider of another group.

  2. In a brokering group, a set of brokering rules can be configured that provides granular control on the brokering requests. For example, a brokering rule can be configured to deny a brokering request from an Origin identity provider to an Allowed service provider, if the user satisfies a certain condition at the SP Broker.

SP brokering is enabled on the Identity Server only if at least one brokering group is enabled. If an Intersite Transfer request is received with neither the origin identity provider nor the Allowed service provider in any of the brokering group, the request is treated as a regular Intersite Transfer and SP brokering controls are not applied.

This chapter provides information about configuring the Access Manager SP Brokering functionalities, various deployment scenarios, and associated configuration details.

Configuring a SP Broker

This section describes how to configure the origin identity provider to act as a SP Broker or a federation hub and also control authentications provided by the Origin identity providers to their Allowed service providers.

Prerequisites

  1. Identify the Origin identity providers and their Allowed service providers. For example, Company 1 establishes a business partnership with Partner 1, at which Company 1 users can access the application of Partner 1. In this case, identity provider at Company 1, is now the Origin identity provider and Allowed service provider is the service provider at Partner 1, and controls access to its applications.

  2. Identify the federation protocols supported by the Origin identity providers and their Allowed service providers. NetIQ Identity Provider supports SP brokering for SAML 2.0, Liberty, or SAML 1.1 federations.

  3. Identify whether Persistent or Transient federations needs to be established between Company 1 and Partner 1. For Persistent federation, the user that is authenticated at the Origin identity provider must be mapped to a valid user at their Allowed service provider. For Transient federation, the user is provided with a temporary identity at the Allowed service provider.

    Configuration Flow

    The following diagram depicts the various configuration steps involved in enabling the SP Brokering feature assuming SP Brokering is enabled between Company 1 and Partner 1:

Step 1: Establish Federation at Origin Identity Providers to SP Broker

  1. The SP Broker must be configured as the service provider at origin identity provider of Company 1.

    For more information, see Creating a Trusted Service Provider for SAML 1.1.

    If NetIQ identity provider is the Origin identity provider, refer.

    For more information, see Creating a Trusted Service Provider for SAML 2.0.

    Step 1a: Establish Federation at Allowed Service Providers to SP Broker

The SP Broker must be configured as the identity provider at the allowed service provider of Partner 1.

For more information, see Creating a Trusted Identity Provider.

If NetIQ identity provider is the allowed service provider, refer.

For more information, see Creating a Trusted Service Provider for SAML 2.0.

NOTE:Step 1 must be repeated for each of the origin identity provider in the federation circle and step 1a must be repeated for each of the allowed service provider in the federation circle.

Step 2: Establish Federations at SP Broker for Origin Identity Providers and their Allowed Service Providers

At the SP Broker, configure origin identity provider of Company 1 as the identity provider. The federation protocol (SAML 1.1/ SAML 2.0/ Liberty) and the federation type (Persistent or Transient) must match the federation protocol and federation type that is used for the respective origin identity provider in the step 1 above.

For more information, see Creating a Trusted Service Provider for SAML 1.1, Creating a Trusted Service Provider for Liberty, and Creating a Trusted Service Provider for SAML 2.0.

Step 2a:

At the SP Broker, configure the allowed service provider of Partner 1 as the service provider. The federation protocol (SAML 1.1/ SAML2.0/ Liberty) and the federation type (Persistent or Transient) must match the federation protocol and the federation type that is used for the respective allowed service provider in the Step1a above.

For more information, see Creating a Trusted Identity Provider.

For more information, see Creating a Trusted Service Provider for SAML 2.0.

NOTE:Step 2 must be repeated for each of the origin identity provider in the federation circle and Step 2a must be repeated for each of the allowed service provider in the federation circle.

Step 3: Configure the Attribute to be Cached at the SP Broker (Optional)

If the target applications require user information, then this information must be passed along with the authentication by the origin identity provider. At the SP Broker, these attributes that are received at the authentication must be cached and sent to the allowed service provider during authentication.

For more information, see Configuring the Attributes Obtained at Authentication.

For more information, see Configuring the Attributes Sent with Authentication.

Step 4: Create Brokering Group for the Federation Circle with the Origin Identity Providers and their Allowed Service Providers

Create a new brokering group in the SP Broker. Company 1 identity provider and Partner 1 service provider must be selected as the origin identity provider and their allowed service provider.

For more information, see Creating a Brokering Group.

The SP Brokering is enabled when at least one brokering group is enabled. Origin identity providers and their allowed service providers can either be added while creating the brokering group or added/deleted by editing the brokering group.

Step 5: Create Brokering Rules for the Brokering Group

Create brokering rules that provide granular control on the brokering requests. For example, a brokering rule can be configured which can deny a brokering request from an origin identity provider to an Allowed service provider, if the user satisfies a certain role at the SP Broker.

For more information, see Configuring Brokering Rules.

To use roles in the brokering rules, identity role policies must be configured on NetIQ identity provider acting as an SP Broker. Roles can be associated for the user at the SP Broker according to the various parameters that include roles sent by the origin identity provider, attribute values sent from the identity provider.

For more information, see Section 6.2.2, Enabling Role-Based Access Control.

Several rules can be configured for a brokering group. To help administrators understand how the rules are applied, a Rule Validation user interface is provided under each brokering group.

For more information, see Validating Brokering Rules.

Step 6: Create and Configure Brokering URLs

The users at Company 1 are provided with a portal page containing URLs to access the applications at the service provider of Partner 1. These URLs are called Brokering URLs and are designed to pass through the SP Broker. The URLs consists of information that are embedded and a tool is provided to construct these URLs. The administrator can create URLs from a given origin identity provider to their allowed service provider to access a given target application specified by a target URL. The URLs constructed are placed in the users’ portal page.

For more information, see Constructing Brokering URLs.

Configuring a Brokering for Authorization of Service Providers

Authorization rules for authorizing service provider requests must be configured from the Access Manager Brokering page. To configure authorization policy, configure the broker rule policy. Ensure that the service providers are configured to the local Identity Server that will be evaluated during authorization. Figure 5-21 displays the sample configuration.

Figure 5-21 SAMl2 Service Provider Initiated Authorization Rule Configuration

Creating and Viewing Brokering Groups

The identity server cluster configuration provides a Brokering tab that you can use to configure the groups and generate brokered URLs.

  1. In the Administration Console, click Devices > Identity Servers > Brokering.

  2. The Brokering tab allows you to create new Groups as well as display the configured Groups.The Display Brokering Groups page displays the list of groups configured.

    You can also create, delete, enable, and disable the brokering group on this page.

  3. The Display Brokering Groups page displays the following information for each group:

    Group Name: Specifies a unique name to identify the group. When you click on the hyperlink, you can view the Group Details page, where the Group configuration such as name and list of Identity Providers and Service Providers can be modified.

    Enabled: A check mark indicates that brokering is enabled for the group by applying theconfigured rules. A blank means that brokering is disabled.

    Identity Providers: Display the total number of Liberty/SAML1.1/SAML2 IDPs assigned to this group.

    Service Providers: Display the total number of Liberty/SAML1.1/SAML2 SPs assigned to this group.

    Brokering Rules: If the rules are not configured, then “No Rules Config” is displayed. The default rule allows for brokering between any IDP to any SP in the group. If new rules are configured, then the first rule name is displayed along with the count of total rules.

Creating a Brokering Group

When a brokering group is created while grouping the brokering feature, following rules are applicable:

  • Brokering is not allowed among different company groups.

    The brokering is not allowed between the logical customers of Company 1 Brokering Group and Company 2 Brokering Group.

  • Brokering is allowed among different partners of the company group.

    Brokering is allowed between the brokering groups of Company 1 Brokering Group and Company 2 Brokering Group.

    • Role based brokering is allowed among Company 1 and Partner 1 logical customers.

    • Role based brokering is allowed among Company 2 and Partner 2 logical customers.

  • Brokering is allowed among different partners based on roles and groups authentication of the company.

To create a new broker group follow these steps:

  1. In the Administration Console, click Devices > Identity Servers > Brokering.

  2. Click New. The Creating Brokering Group page displays.

  3. Perform the following actions in the fields:

    Display Name: Specify the brokering group display name.

    Selected IDPs: Select at least one trusted IDP using navigation button.

    Selected SPs: Select at least one trusted SP using navigation button.

    Available Trusted IDPs: Displays Liberty/SAML1.1/SAML2.0 trusted IDP configured on the given IDP cluster (idp_cluster1).

    Available Trusted SPs: Displays Liberty/SAML1.1/SAML2.0 Trusted Service Providers configured on the given Identity Provider Cluster (idp_cluster1).

  4. Click Finish to complete creation of the brokering group creation.

Configuring Trusted Identity Providers and Service Providers

You can configure the rules between the trusted identity providers and service providers by configuring rules, roles, and actions. You can view the configured rules, create new, delete the existing rule, edit the rules, enable and disable the configured rules.

You can configure the service providers and identity providers for all of the protocols in the Identity Server, which are configured in the Identity Server cluster. Using the brokering group, you can view the list of available service providers and identity providers in the selection box. Using the arrow keys, configure the trusted identity providers and trusted service providers for the respective brokering group.

  1. In the Administration Console, click Devices > Identity Servers > Brokering Group Name. The Configuration page displays the Trusted Providers, Brokering rules, Construct URL and Rule Validation tabs.

  2. Click Trusted Providers tab.

  3. Specify the display name and configure the brokering groups.

    Display Name: Specify the display name of the configuring brokering group.

    Select IDPs: Configure the selected identity providers using the arrow keys from the available trusted IDPs.

    Available Trusted IDPs: Configure the available trusted identity providers using the arrow keys from Selected Identity Providers selection box.

    Selected SPs: Configure the selected service providers using the arrow keys from the Available Trusted Service Providers selection box.

    Available Trusted SPs: Configure the available trusted service providers using the arrow keys from the Selected Service Providers selection box.

  4. Click OK to continue and the configured service providers and identity providers details are displayed in the Brokering page.

  5. Click Finish to complete the rules configuration for the brokering group.

  6. Click Apply to see the configuration changes.

NOTE:When you log out from the Access Gateway device, then the logout is not propagated on the other Identity Servers if you have SAML 1.1 as one of the trusted provider in the brokering group.

Configuring Brokering Rules

You can create, edit, delete, enable, and the disable brokering rules.

  1. In the Administration Console, click Devices > Identity Servers > Brokering.

  2. Click the existing or newly created Brokering Group hyperlink.

  3. Click Rules. The Brokering Group Rules page is displayed.

    Name: Displays the rule name of the brokering group.

    Enabled: Displays the status of the brokering group rule.

    Identity Providers: Displays the number of identity providers configured to the brokering group.

    Service Providers: Displays the number of service providers configured to the brokering group.

    Priority: Displays the brokering group rule priority number.

    Actions: Displays the configured brokering group rule action status either as permit or deny.

    Role Conditions: Displays the brokering group role condition, such as manager and emplyee , configured on the rule page.

  4. Click OK to continue and display the configured brokering group rule details on the Brokering Rules page.

  5. Click Apply to see the brokering rule configuration changes.

Creating a Brokering Rule

You can configure the rules to the created brokering groups.

  1. In the Administration Console, click Devices > Identity Servers > Brokering.

  2. Click the existing or newly created Brokering Group hyperlink.

  3. Click Rules. The Creating Brokering Group page displays.

    Rule Name: Specify the name of the rule.

    Rule Priority: Select the rule priority from the drop-down list.

    NOTE:The default rule specified during creation of the group has a priority of 1. Additional rules can be added, and existing rules can be deleted or modified. You can use the Edit Rules Page to modify the priority of the rules.

    Origin IDP: Displays all Identity Servers or one or more Identity Servers that are available in the group.

    Allowed SP: Displays all service providers or one or more service providers that are available in the group.

    Role Conditions: Displays the brokering group role condition such as manager and employee, configured on the rule page.

    Actions: Select the Permit or Deny action radio button for the rule you configure to the brokering group.

    NOTE:By default, Access Manager allows any role. If you want to allow access to only particular roles, configure a permit condition for roles with higher priority and configure a deny condition in which no roles are defined with lower priority.

  4. Click Finish to complete configuration of rules for the brokering group.

Deleting a Brokering Rule

  1. In the Administration Console, click Devices > Identity Servers > Edit > Brokering > (Brokering Group in the Brokering Group list) > Rules.

  2. Select the check box of the brokering group rule you want to delete, then click Delete. A message is displayed as “Delete selected brokering rule(s)?”.

  3. Click OK to continue.

Enabling a Brokering Rule

  1. In the Administration Console, click Devices > Identity Servers > Edit > Brokering > (Brokering Group in the Brokering Group list) > Rules.

  2. Select the check box of the brokering group rule you want to enable.

  3. Click Enable.The selected brokering group is enabled.

Disabling a Brokering Rule

  1. In the Administration Console, click Devices > Identity Servers > Edit > Brokering > (Brokering Group in the Brokering Group list) > Rules.

  2. Select the check box of the brokering group you want to disable from the brokering group rule configuration.

  3. Click Disable. The selected brokering group is disabled.

Editing Brokering Rules

You can edit the group rules in the Brokering page.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Brokering.

  2. Click the existing or newly created brokering group hyperlink.

  3. Click Rules tab.

  4. Click the Brokering Rules hyperlink to edit the information. The Edit Brokering Rule page displays the information. You can also edit the information.

You can edit all the fields and modify the information about the Create Brokering Rule page. For more information about create brokering rule, see Creating a Brokering Rule

Constructing Brokering URLs

The Construct URL page helps you to create a URL, which you use in your application to navigate to your trusted partners.

You can generate the URL according to the origin and allowed service provider Identity Servers.

  1. In the Administration Console, click Devices > Identity Servers > Brokering.

  2. Click the existing or newly created brokering group hyperlink.

  3. Click Construct URL.

    IDP Type: Select the Identity Provider type from the drop-down list. The three types of IDP in the drop-down list are Local IDP, NetIQ IDP, and Other IDP. If you select NetIQ IDP as the IDP type, then you can select the Origin IDP from the drop-down list. If you select Other IDP as the IDP type, you can enter the Origin IDP URL and you can select the Origin IDP from the drop-down list.

    Origin IDP: The Origin identity providers are the trusted providers. The drop-down list displays all the trusted providers created for the specific NetIQ brokering group. Select the Origin IDP from the drop-down list.

    NOTE:If the Origin IDP drop-down list does not list any trusted providers, it is because a local Identity Server exists as a trusted provider. To resolve this, add another Identity Server to the NetIQ brokering group

    Origin IDP URL: If you select Other IDP as the IDP type, you can enter the Origin IDP URL manually. The <OriginIDPURL> represents (protocol :// domain : port / path ? querystring).

    Provider Parameter Name: If you select Other IDP as the IDP Type, you can enter the trusted provider parameter ID. For more information about Intersite Transfer Service target for a service provider, see Configuring an Intersite Transfer Service Target for a Service Provider

    Target Parameter Name: If you select Other IDP as the IDP type, you can enter the target provider parameter name manually.

    Allowed SP: The allowed service providers are the selected service providers of the trusted roviders. The drop-down list displays all the service providers created for the specific brokering group. Select the service providers from the drop-down list.

    Target URL: Specify the target URL for the specific trusted providers and service provider pair. This URL will be appended to the login URL. Click Generate to generate the login URL

    Login URL: The login URL consists of Origin IDP URL and the target URL.

  4. Click Cancel to close the Construct URL page.

Validating Brokering Rules

The rule validation page helps you to validate the Origin identity providers and the allowed service provider rule according to the role associated with the respective trusted partners.

  1. In the Administration Console, click Devices > Identity Servers > Brokering.

  2. Click on the existing or newly created brokering group hyperlink.

  3. Click the Rule Validation tab.

    Origin IDP: The Origin identity providers are the trusted providers. The drop-down list displays all the trusted providers created for the specific NetIQ brokering group. Select the Origin identity providers from the drop-down list.

    Allowed SP: The Allowed SPs are the selected SPs of the trusted providers. The drop-down list displays all the service providers created for the specific brokering group. Select the service providers from the drop-down list

    Role: Specify the role you want to validate for the selected Origin identity trusted providers and allowed SP. Click the Validate Rule.

    A list is displayed according to the rule validation for the selected trusted providers, role, and permission.

    Name: Displays the role name of the selected trusted providers.

    Identity Providers: Displays the identity provider name.

    Service Providers: Displays the service provider name.

    Priority: In ascending order, displays the priority number of the rule validation of the selected trusted providers.

    Action: Displays the permission action for validation of the selected trusted providers rule validation.

    Role Conditions: Displays the role conditions for the selected trusted providers rule validation. Denial takes precedence over Permit.

    Evaluate State: Displays the role conditions evaluate state for the selected trusted providers rule validation. You can see diffferent evaluation states in the role conditions.

    Pass 1: If the rule matches the Origin identity provider, allowed service provider or any roles mentioned.

    Pass2: If the rule matches the Origin identity provider, allowed service provider or any specific role mentioned.

    Ignored: If the rule does not match either Pass 1 or Pass 2 .

    Not Executed: The default state of all the roles.

    NOTE:If the rule has the evaluate State as Pass 1 action as Deny, then the remaining rules are in the non-executed state.

    After a rule has the evaluate state as Pass 2, regardless of the action, the remaining rules are in the non-executed state.

    The rules before Pass 1, should have the evaluate state of Ignored. All these ignored rules should have the role condition as Any, without specifying any role condition.

    Pass 1 evaluation stops, as soon as a match for the Origin identity provider and allowed service provider is found with specific to some role condition.

  4. Click Cancel to close the Rule Validation page.

Generating the Brokering URLs by Using an ID and Target in the Intersite Transfer Service

You can generate the brokering URL’s using the ID of the target. You can use this value to simplify the Intersite Transfer Service URL that must be configured at the service provider. For more information, see Configuring an Intersite Transfer Service Target for a Service Provider.

  1. In the Administration Console, click Devices > Identity Servers > Brokering or click Devices > Identity Servers > Edit > SAML 2.0 > Trusted Providers > > (Broker Identity under the Service Providers list) >Intersite Transfer Service.

  2. ID: Specify the ID value of the target.

  3. Target: Specify the URL of the page that you want to display to users when they authenticate with an Intersite Transfer URL.The behavior of this option is influenced by the Allow any target option. If you are using the target ID as part of the Intersite Transfer URL and did not specify a target in the URL, you need to specify the target in this field. For example, if you enter the target URL as it appears below, then it will be displayed when you select Allow Any Target option.

    https://login.company1.com:8443/nidp/saml2/idpsend?id=217ID&TARGET=https%3A%2F%2FSPBROKER1.labs.blr.novell.com%3A8443%2Fnidp%2Fsaml2%2Fidpsend%3FPID%3Dhttps%3A%2F%2Flogin.partner2B.com%3A8443%2Fnidp%2Fsaml2%2Fmetadata%26TARGET%3Dhttps%3A%2F%2Fpartner2b.com

  4. Allow any Target: Select this option to use the target that was specified in the Intersite Transfer URL. If this option is not selected, the target value in the Intersite Transfer URL is ignored and you can see the URL specified in the Target option.

Assigning The Local Roles Based On Remote Roles And Attributes

You are able to configure the attributes based on the roles you select in the Attribute set field. You are able to log in and authenticated based on roles federated in the Origin Identity Provider, Target Service Provider and the Brokering Service Provider configuration.

Origin Identity Provider Role Attribute Configuration

  1. In the Administration Console, click Devices > Identity Servers > Shared Settings >Attribute Sets > Mapping >New. The Add Attribute Mapping window displays.

  2. Select the local attribute name from the drop-down list

  3. Enter the remote attribute name for the selected local attribute.

  4. Click OK to add the remote attribute name. The newly added attribute displays in the Mapping list.

  5. In the Administration Console, click Devices > Identity Servers > Edit > SAML 2.0 > Trusted Providers > (Broker Identity under the Identity Providers list) > Configuration > Attributes.

  6. Select the role from drop-down list in the Attribute set.

  7. Using the arrows map the attributes in the Send with Authentication and Available List.

  8. Click Apply to map the set role and attribute of the origin Identity Provider.

Target Identity Provider Role Attribute Configuration

  1. In the Administration Console, click Devices > Identity Servers > Shared Settings >Attribute Sets > Mapping >New. The Add Attribute Mapping window displays.

  2. Select the local attribute name from the drop-down list

  3. Enter the remote attribute name for the selected local attribute.

  4. Click OK to add the remote attribute name. The newly added attribute displays in the Mapping list.

  5. In the Administration Console, click Devices > Identity Servers > Edit > SAML 2.0 > Service Providers > (Broker Identity under the Service Providers list) > Configuration > Attributes.

  6. Select the role from drop-down list in the Attribute set.

  7. Using the arrows map the attributes in the Send with Authentication and Available List.

  8. Click Apply to map and set the attribute changes to the selected role of the target Identity Service Provider.

Brokering Service Provider Role Attribute Configuration

The roles set and the attribute configured in origin identity provider and the target service provider is added and mapped in the brokering service provider attribute configuration.

  1. In the Administration Console, click Devices > Identity Servers > Shared Settings >Attribute Sets > Mapping >New. The Add Attribute Mapping window displays.

  2. Select the local attribute name from the drop-down list

  3. Enter the remote attribute name for the selected local attribute.

  4. Click OK to add the remote attribute name. The newly added attribute displays in the Mapping list.

  5. In the Administration Console, click Devices > Identity Servers > Brokering or click Devices > Identity Servers > Edit > SAML 2.0 > Service Providers > (Broker Identity under the Service Providers list) > Configuration > Attributes.

  6. Select the role from drop-down list in Attribute set.

  7. Using the arrows map the attributes in Send with Authentication and Available List.

  8. Click Apply to set the role and configure the attribute mappings.

SP Brokering Example

This example explains how SP Brokering works. Let us assume that two companies Digital Airlines and ACME are business partners. There are certain applications that users of both Digital Airlines and ACME require to access.

With SP Brokering, users in Digital Airlines are provided with an intersite transfer URL that allows users to authenticate at Digital Airlines, set the assertion at ACME, and give access to the target application. With this approach, users do not have to choose from different authentication cards.

The following diagram depicts the SP Brokering workflow:

Workflow:

  1. A user is authenticated at Digital Airlines identity provider. The user clicks Broker URL. Digital Airlines checks if this user is authenticated. If not, it asks for user credentials and authenticates the user.

  2. Digital Airlines identity provider processes an intersite URL and creates an assertion for SP Broker (NetIQ Identity Server).

  3. SP Broker receives the assertion and validates that this assertion is received from a trusted identity provider.

  4. SP Broker checks if the trusted identity provider and the service provider (available in the target URL) belong to the same group. SP Broker denies the request if both do not belong to same group.

  5. SP Broker sends a request to Digital Airlines identity provider to resolve the artifact.

  6. SP Broker receives the SAML assertion from Digital Airlines identity provider and caches attributes/roles received. SP Broker applies any Role policies that have been enabled.

  7. SP Broker performs intersite transfer. In the processing of intersite transfer, SP Broker checks if this user was a result of SP Brokering (step 4 earlier). SP Broker enforces the SP Brokering rules check: if any of the rules result in deny, an error page is displayed.

  8. SP Broker creates an assertion for ACME.

  9. ACME sends a request to SP Broker to resolve the artifact.

  10. ACME receives the SAML assertion from the SP Broker along with roles/attributes.

  11. ACME sends a redirect to the final target URL. (Note: Redirect happens from ACME’s ESP to ACME’s identity provider where the user is already authenticated.)

  12. The user accesses the target application.

5.2.3 Configuring User Identification Methods for Federation

Configuring authentication involves determining how the service provider interacts with the identity provider during user authentication and federation. Three methods exist for you to identify users from a trusted identity provider:

  • You can identify users by matching their authentication credentials

  • You can match selected attributes and then prompt for a password to verify the match, or you can use just the attributes for the match.

  • You can assume that the user does not have an account and create new accounts with user provisioning. You can also allow for provisioning when the matching methods fail. If there are problems during provisioning, you see error messages with more information.

The following sections describe how to configure these methods:

Defining User Identification for Liberty and SAML 2.0

Selecting a User Identification Method for Liberty or SAML 2.0

User identification determines how an account at the identity provider is matched with an account at the service provider. If federation is enabled between the two, the user can set up a permanent relationship between the two accounts. If federation is not enabled (see Configuring a SAML 2.0 Authentication Request and Configuring a Liberty Authentication Request), you cannot set up a user identification method.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty [or SAML 2.0] > [Identity Provider] > User Identification.

  2. Specify how users are identified on the SAML 2.0 or Liberty provider. Select one of the following methods:

    • Authenticate: Select this option when you want to use login credentials. This option prompts the user to log in at both the identity provider and the service provider on first access. If the user selects to federate, the user is prompted, on subsequent logins, to authenticate only to the identity provider.

      • Allow ‘Provisioning’: Select this option to allow users to create an account when they have no account on the service provider.

        This option requires that you specify a user provisioning method.

    • Provision account: Select this option when the users on the identity provider do not have accounts on the service provider. This option allows the service provider to trust any user that has authenticated to the trusted identity provider

      This option requires that you specify a user provisioning method.

    • Attribute matching: Select this option when you want to use attributes to match an identity server account with a service provider account. This option requires that you specify a user matching method.

      • Prompt for password on successful match: Select this option to prompt the user for a password when the user’s name is matched to an account, to ensure that the account matches.

    NOTE:If you have selected Transient user mapping while configuring the name identifier format, the Authenticate and Provision account options are not displayed for SAML 2.0.

  3. Select one of the following:

  4. Configure the post authentication method.

    Selected Methods: Using the arrow keys to move methods from the Available Methods list to the Selected Methods list. The selected method is executed when post remote authentication completes.

    For example if you select the passwordfetch method, this method is executed at the service provider after the identity provider authentication and federation completes.

    Logout on method execution failure: If you select this check box, then whenever there is a session failure, the user is logged out automatically.

  5. Configure the session options.

    Allow IDP to set session timeout: Select Allow Identity Provider to set session timeout between the principal identified by the subject and the SAML authority based on SessionNotOnOrAfter attribute in SAML assertion of authnStatement.

    Overwrite Temporary User: If you select this check box, then the temporary user credentials profile got form previous authentication method in the same session will be overwritten with real user credentials profile got from this authentication method.

    Overwrite Real User: If you select this check box, then the real user credentials profile got form previous authentication method in the same session will be overwritten with real user credentials profile got from this authentication method

    Assertion Validity Window: You can manually set the assertion validity time for SAML Service Provider (SP) to accommodate clock skew between Service Provider and SAML Identity (IDP) Server.

  6. Click OK twice, then update the Identity Server.

Configuring the Attribute Matching Method for Liberty or SAML 2.0

If you enabled the Attribute matching option when selecting a user identification method, you must configure a matching method.

The Liberty Personal Profile is enabled by default. If you have disabled it, you need to enable it. See Managing Web Services and Profiles.

  1. In the Administration Console, click Devices > Identity Servers > Servers > Edit > Liberty [or SAML 2.0] > [Identity Provider] > User Identification.

  2. Click Attribute Matching settings.

  3. Select and arrange the user stores you want to use.

    Order is important. The user store at the top of the list is searched first. If a match is found, the other user stores are not searched.

  4. Select a matching expression, or click New to create a look-up expression. For information about creating a look-up expression, see Section 3.5.3, Configuring User Matching Expressions.

  5. Specify what action to take if no match is found.

    • Do nothing: Specifies that an identity provider account is not matched with a service provider account. This option allows the user to authenticate the session without identifying a user account on the service provider.

      IMPORTANT:Do not select this option if the expected name format identifier is persistent. A persistent name format identifier requires that the user be identified so that information can be stored with that user. To support the Do nothing option and allow anonymous access, the authentication response must be configured for a transient identifier format. To view the service provider configuration, see Section 3.9.8, Configuring an Authentication Response for a Service Provider.

    • Prompt user for authentication: Allows the user to specify the credentials for a user that exists on the service provider. Sometimes users have accounts at both the identity provider and the service provider, but the accounts were created independently, use different names (for example, joe.smith and jsmith) and different passwords, and share no common attributes except for the credentials known by the user.

    • Provision account: Assumes that the user does not have an account at the service provider and creates one for the user. You must create a provisioning method.

  6. Click OK.

  7. (Conditional) If you selected Provision account when no match is found, select the Provision settings icon. For information about this process, see Defining the User Provisioning Method.

  8. Click OK twice, then update the Identity Server.

Defining User Identification for SAML 1.1

Selecting a User Identification Method for SAML 1.1

Two methods exist for identifying users from an identity provider when using the SAML 1.1 protocol. You can specify that no account matching needs to occur, or you can configure a match method. You configure a match method when you want to use attributes from the identity provider to uniquely identify a user on the service provider.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 1.1 > [Identity Provider] > User Identification.

  2. In the Satisfies contract option, specify the contract that can be used to satisfy the assertion received from the identity provider. Because SAML 1.1 does not use contracts and because the Identity Server is contract-based, this setting permits an association to be made between a contract and a SAML 1.1 assertion.

    Use caution when assigning the contract to associate with the assertion, because it is possible to imply that authentication has occurred, when it has not. For example, if a contract is assigned to the assertion, and the contract has two authentication methods (such as one for name/password and another for X.509), the server sending the assertion might use only name/password, but the service provider might assume that X.509 took place and then incorrectly assert it to another server.

  3. Select one of the following options for user identification:

    • Do nothing: Specifies that an identity provider account is not matched with a service provider account. This option allows the user to authenticate the session without identifying a user account on the service provider.

    • Attribute matching: Authenticates a user by matching a user account on the identity provider with an account on the service provider. This option requires that you set up the match method.

      • Prompt for password on successful match: Specifies whether to prompt the user for a password when the user is matched to an account, to ensure that the account matches.

  4. Select one of the following:

  5. You can also configure the assertion time manually.

    • Assertion Validity Window: You can manually set the assertion validity time for SAML Service Provider (SP) to accommodate clock skew between Service Provider and SAML Identity (IDP) Server.

  6. Click OK twice.

  7. Click Apply to make the user identification configuration changes.

  8. Update the Identity Server.

Configuring the Attribute Matching Method for SAML 1.1

A user matching expression is a set of logic groups with attributes that uniquely identify a user. User matching expressions enable you to map the Liberty attributes to the correct LDAP attributes during searches. You must know the LDAP attributes that can be used to identify unique users in the user store.

To use user matching, the Personal Profile must be enabled. It is enabled by default. If you have disabled it, you need to enable it. See Managing Web Services and Profiles.

  1. In the Administration Console, click Devices > Identity Servers > Servers > Edit > SAML 1.1 > [Identity Provider] > User Identification.

  2. To configure the match method, click Attribute Matching settings.

  3. Select and arrange the user stores you want to use.

    Order is important. The user store at the top of the list is searched first. If a match is found, the other user stores are not searched.

  4. Select a matching expression, or click New to create a look-up expression. For information about creating a look-up expression, see Section 3.5.3, Configuring User Matching Expressions.

  5. Click OK.

  6. Update the Identity Server.

Defining the User Provisioning Method

If you have selected Provision account as the user identification method or have created an attribute matching setting that allows for provisioning when no match is found, you need to create a provision method. This procedure involves selecting required and optional attributes that the service provider requests from the identity provider during provisioning.

IMPORTANT:When a user object is created in the directory, some attributes are initially created with the value of NAM Generated. Afterwards, an attempt is made to write the required and optional attributes to the new user object. Because required and optional attributes are profile attributes, the system checks the write policy for the profile’s Data Location Settings (specified in Liberty > Web Service Provider) and writes the attribute in either LDAP or the configuration store. In order for the LDAP write to succeed, each attribute must be properly mapped as an LDAP Attribute. Additionally, you must enable the read/write permissions for each attribute in the Liberty/LDAP attribute maps. See Mapping LDAP and Liberty Attributes.

To configure user provisioning:

  1. In the Administration Console, click Devices > Identity Servers > Servers > Edit > Liberty [or SAML 2.0] > [Identity Provider] > User Identification.

  2. Click the Provisioning settings icon.

  3. Select the required attributes from the Available Attributes list and move them to the Attributes list.

    Required attributes are those used in the creation of a user name, or that are required when creating the account.

  4. Click Next.

  5. Select optional attributes from the Available Attributes list and move them to the Attributes list.

    This step is similar to selecting required attributes. However, the user provisioning request creates the user account whether or not the optional attributes exist on the service provider.

  6. Click Next.

  7. Define how to create the username.

    You can specify whether users are prompted to create their own usernames or whether the system automatically creates usernames. Selecting an attribute for the username segments from the required attributes list improves the chances that a new username is successfully created.

    Maximum length: The maximum length of the user name. This value must be between 1 and 50.

    Prompt for user name: Enables users to create their own usernames.

    Automatically create user name: Specifies that the system creates usernames. You can configure the segments for the system to use when creating usernames and configure how the names are displayed.

    For example, if you are using the required attributes of Common First Name and Common Last Name, a username for Adam Smith might be generated as A.Smith_02, as shown in the following illustration:

    Use the following settings to specify how this is accomplished:

    • Segment 1: The required attribute to use as the first segment for the user name. The values displayed in this drop-down menu correspond to the required attributes you selected. For example, you might select Common First Name to use for Segment 1.

    • Length: The length of the first attribute segment. For example, if you selected Common First Name for the Segment 1 value, setting the length to 1 specifies that the system uses the first letter of the Common First Name attribute. Therefore, Adam Smith would be ASmith.

    • Junction: The type of junction to use between the attributes of the user name. If a period is selected, Adam Smith would display as A.Smith.

    • Segment 2: The required attribute to use as the second segment for the user name. The values displayed in this drop-down menu correspond to the required attributes you selected. For example, you might select Common Last Name to use for Segment 2.

    • Length: The length of the second attribute segment. For example, if you selected Common Last Name for the Segment 2 value, you might set the length to All, so that the full last name is displayed. However, the system does not allow more than 20 characters for the length of segment 2.

    • Ensure name is unique: Applies a suffix to the colliding name until a unique name is found, if using attributes causes a collision with an existing name. If no attributes are provided, or the lengths for them are 0, and this option is selected, the system creates a unique name.

  8. Click Next.

  9. Specify password settings.

    Use this page to specify whether to prompt the user for a password or to create a password automatically.

    Min. password length: The minimum length of the password.

    Max. password length: The maximum length of the password.

    Prompt for password: Prompts the user for a password.

    Automatically create password: Specifies whether to automatically create passwords.

  10. Click Next.

  11. Specify the user store and context in which to create the account.

    User Store: The user store in which to create the new user account.

    Context: The context in the user store you want accounts created.

    The system creates the user within a specific context; however, uniqueness is not guaranteed across the directory.

    Delete user provisioning accounts if federation is terminated: Specifies whether to automatically delete the provisioned user account at the service provider if the user terminates his or her federation between the identity provider and service provider.

  12. Click Finish.

  13. Click OK twice, then update the Identity Server.

User Provisioning Error Messages

The following error messages are displayed for the end user if there are problems during provisioning:

Table 5-13 Provisioning Error Messages

Error Message

Cause

 
Username length cannot exceed (?) characters.

The user entered more characters for a user name than is allowed, as specified by the administrator.

 
Username is not available.

The user entered a name that already exists in the directory.

 
Passwords don't match.

The user provided two password values that do not match.

 
Passwords must be between (x) and (y) characters in length.

The user provided password values that are either too short or too long.

 
Username unavailable.

The provisioned user account was deleted without first defederating the user. Remove orphaned identity objects from the configuration datastore.

IMPORTANT:Only experienced LDAP users should remove orphaned identity objects from the configuration datastore. You must ensure that the objects you are removing are orphaned. Otherwise, you create orphaned objects by mistake.

 
Unable to complete authentication request.

The password provided does not conform to the Windows password complexity policy in Active Directory. Ensure that Active Directory is configured to use a secure port, such as 636, and that the user’s password conforms to the complexity policy. If you encounter this error, you must reset the password on the Windows machine.

Can occur when users are allowed to create accounts from a service provider’s login page, when the service provider uses Active Directory for the user store.

5.2.4 Configuring SAML 2.0

This section explains how to use the SAML 2.0 protocol to set up the trust with internal and external identity providers, service providers, and Embedded Service Providers (ESPs). Topics include:

Understanding How Access Manager Uses SAML

Security Assertions Markup Language (SAML) is an XML-based framework for communicating security assertions (user authentication, entitlement, and attribute information) between trusted identity providers and trusted service providers. For example, an airline company can make assertions to authenticate a user to a partner company or another enterprise application, such as a car rental company or hotel.

The Identity Server allows SAML assertions to be exchanged with trusted service providers that are using SAML servers. Using SAML assertions in each Access Manager component protects confidential information by removing the need to pass user credentials between the components to handle session management.

An identity provider using the SAML protocol generates and receives assertions for authentication, according to the SAML 1.0, 1.1, and 2.0 specifications described on the Oasis Standards Web site.

This section describes how Access Manager uses SAML. It includes the following topics:

Attribute Mapping with Liberty

Attribute-based involves one Web site communicating identity information about a subject to another Web site in support of some transaction. However, the identity information might be some characteristic of the subject, such as a role. The attribute-based is important when the subject’s identity is either not important, should not be shared, or is insufficient on its own.

In order to interoperate with trusted service providers through the SAML protocol, the Identity Server distinguishes between different attributes from different SAML implementations. All of the SAML administration is done with Liberty attributes. When you specify which attributes to include in an assertion, or which attributes to use when locating the user from an assertion, these attributes should always be specified in the Liberty format.

In an attribute map, you convert SAML attributes from each vendor’s implementation to Liberty attributes. (See Section 3.5.1, Configuring Attribute Sets.)

You can find detailed information about SAML 2.0 on the OASIS Standards Web site.

Trusted Provider Reference Metadata

Metadata is generated by the Identity Server and is used for server communication and identification. Metadata can be obtained via URL or XML document, then entered in the system when you create the reference. Metadata is traded with federation partners and supplies various information regarding contact and organization information located at the Identity Server. Metadata is generated automatically for SAML 2.0. You enter it manually for SAML 1.1.

IMPORTANT:The SAML 2.0 and Liberty 1.2 protocols define a logout mechanism whereby the service provider sends a logout command to the trusted identity provider when a user logs out at a service provider. SAML 1.1 does not provide such a mechanism. For this reason, when a logout occurs at the SAML 1.1 service provider, no logout occurs at the trusted identity provider. A valid session is still running at the identity provider, and no credentials need to be entered. In order to log out at both providers, users must navigate to the identity provider that authenticated them to the SAML 1.1 service provider and log out manually.

Identity Provider Process Flow

The following illustration provides an example of an Identity Server automatically creating an authenticated session for the user at a trusted SAML service provider. PP indicates a Personal Profile Service as defined by the Liberty specification.

Figure 5-22 SAML Service Provider Process Flow

  1. A user is logged in to the Identity Server at abc.com (the user’s identity provider) and clicks a link to xyz.com, a trusted SAML service provider.

    The Identity Server at abc.com generates the artifact. This starts the process of generating and sending the SAML assertion. The HREF would look similar to the following:

    http://nidp.com/saml/genafct?TARGET=http://xyz.com/index.html&AID=XYZ

  2. The Identity Server processes attributes as follows:

    1. The server looks up LDAP or Liberty-LDAP mapped attributes. (See Mapping LDAP and Liberty Attributes.) In this example, you use Liberty attributes such as PP: sn instead of surname. PP: sn and PP: ph# are attributes that you are sending to xyz.com.

    2. The Identity Server processes these attributes with a SAML implementation-specific attribute.

      Because the identity provider must interoperate with other SAML service providers that probably do not use consistent attribute names, you can map the service provider attributes to your Liberty and LDAP attributes on the Identity Server. In this example, the service provider names for the Liberty PP: sn and PP: ph# attributes are lastname and phonenumber, respectively. (See Configuring the Attributes Obtained at Authentication.)

    3. The Identity Server uses the PP service to look up the values for the user’s PP: sn and PP: ph# attributes.

      The Identity Server recognizes that the values for the user’s PP: sn and PP: ph# attributes are Jones and 555-1212, respectively.

  3. The Identity Server sends an HTTP redirect with an artifact.

    The Identity Server now has the information to generate a SAML assertion. The Identity Server sends an HTTP redirect containing the artifact back to the browser. The redirect looks similar to the following: 

    http://xyz.com/auth/afct?TARGET=http://xyz.com/index.html&SAMLArtifact =<<artifact>>

  4. The remote SAML server requests the assertion.

    The HTTP redirect results in the browser sending the artifact to the SAML server at xyz.com. The SAML server at xyz.com requests the SAML assertion from the Identity Server.

  5. The Identity Server sends the assertion to the remote SAML server.

    The remote SAML server receives the artifact and looks up the assertion.The assertion is sent to the SAML server at xyz.com in a SOAP envelope. The assertion contains the attributes lastname=Jones and phonenumber=555-1212.

    The user now has an authenticated session at xyz.com. The xyz.com SAML server redirects the user’s browser to http://xyz.com/index.html, which was referenced in the original HREF in Step 1.

SAML Service Provider Process Flow

The following illustration provides an example of the authentication process on the consumer side, when a user clicks a link at the SAML service provider (xyz.com) in order to begin an authentication session with an identity provider (such as abc.com). PP indicates a Personal Profile Service as defined by the Liberty specification.

Figure 5-23 SAML Consumer Process Flow

  1. The user clicks a link at xyz.com.

    This generates a SAML assertion intended for the Identity Server at abc.com, which is the identity provider in an Access Manager configuration. After the SAML server generates the artifact, it sends the browser a redirect containing the artifact. The browser is redirected to the identity provider, which receives the artifact. The URL sent to the Identity Server would look similar to the following:

    http://nidp.com/auth/afct?TARGET=http://abc.com/index.html&SAMLArtifact =<<artifact>>

  2. The Identity Server at abc.com receives the assertion.

    The assertion is sent to the Identity Server packaged in a SOAP envelope. In this example, the assertion contains the attributes lastname=Jones, and phonenumber=555-1212.

  3. The Identity Server determines which attributes to use when locating the user.

    The Identity Server must determine how to locate the user in the directory. When you created the SAML service provider reference for xyz.com, you specified which Liberty attributes should be used for this purpose. In this case, the you specified that PP: sn and PP: ph# should be used.

    1. The Identity Server processes the Liberty attribute map (see Mapping LDAP and Liberty Attributes) to the SAML implementation-specific attributes (see Configuring the Attributes Obtained at Authentication).

      Because this SAML implementation must interoperate with other SAML implementations that probably do not use consistent attribute names, you can map the attributes used by each third-party SAML implementation to Liberty attributes on the Identity Server.

    2. The Identity Server receives implementation-specific SAML attribute names.

      The trusted service provider’s names for the Liberty PP: sn and PP: ph# attributes are returned. Using the attribute map, the Identity Server knows that the service provider’s names for these attributes are lastname and phonenumber, respectively.

    3. The Identity Server uses the PP service to lookup the values for the user’s PP: sn and PP: ph# attributes.

      The Identity Server now recognizes that the values for the user’s PP: sn and PP: ph# attributes are Jones and 555-1212, respectively. The user’s DN is returned to the Identity Server, and the user is authenticated.

  4. The user’s DN is returned to the Identity Server, and the user is authenticated.

  5. The user is redirected to the target resource at xyz.com.

Configuring a SAML 2.0 Profile

You can configure the methods of communication that are available at the server for requests and responses sent between providers. These settings affect the metadata for the server and should be determined prior to publishing to other sites.

Profiles control the methods of communication that are available for SAML 2.0 protocol requests and responses sent between trusted providers. These settings affect the metadata for the server and should be determined prior to publishing to other sites. The identity provider uses the incoming metadata to determine how to respond.

All available profile bindings are enabled by default. SOAP is used when all are enabled (or if the service provider has not specified a preference), followed by HTTP Post, then HTTP Redirect.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 2.0 > Profiles.

  2. Configure the following fields for identity providers and identity consumers (service providers):

    Artifact Resolution: Specify whether to enable artifact resolution for the identity provider and identity consumer.

    The assertion consumer service at the service provider performs a back-channel exchange with the artifact resolution service at the identity provider. Artifacts are small data objects pointing to larger SAML protocol messages. They are designed to be embedded in URLs and conveyed in HTTP messages.

    Login: Specifies the communication channel to use when the user logs in. Select one or more of the following:

    • Post: A browser-based method used when the SAML requester and responder need to communicate using an HTTP user agent. This occurs, for example, when the communicating parties do not share a direct path of communication. You also use this when the responder requires user interaction in order to fulfill the request, such as when the user must authenticate to it.

    • Redirect: A browser-based method that uses HTTP 302 redirects or HTTP GET requests to communicate requests from this identity site to the service provider. SAML messages are transmitted within URL parameters.

    Single Logout: Specifies the communication channel to use when the user logs out. Select one or more of the following:

    • HTTP Post: A browser-based method used when the SAML requester and responder need to communicate by using an HTTP user agent. This occurs, for example, when the communicating parties do not share a direct path of communication. You also use this when the responder requires user interaction in order to fulfill the request, such as when the user must authenticate to it.

    • HTTP Redirect: A browser-based method that uses HTTP 302 redirects or HTTP GET requests to communicate requests from this identity site to the service provider. SAML messages are transmitted within URL parameters.

    • SOAP: Uses SOAP back channel over HTTP messaging to communicate requests from this identity provider to the service provider.

      NOTE:If Show logged out providers option is enabled with HTTP Post profile, logout request from service provider does not complete. This is due to the difference in the HTTP method used in the logout request. It is recommended to use HTTP Redirect method when Show logged out providers option is enabled.

    Name Management: Specifies the communication channel for sharing the common identifiers for a user between identity and service providers. When an identity provider has exchanged a persistent identifier for the user with a service provider, the providers share the common identifier for a length of time. When either the identity or service provider changes the format or value to identify the user, the system can ensure that the new format or value is properly transmitted. Select one or more of the following:

    • HTTP Post: A browser-based method used when the SAML requester and responder need to communicate using an HTTP user agent. This occurs, for example, when the communicating parties do not share a direct path of communication. You also use this when the responder requires user interaction in order to fulfill the request, such as when the user must authenticate to it.

    • HTTP Redirect: A browser-based method that uses HTTP 302 redirects or HTTP GET requests to communicate requests from this identity site to the service provider. SAML messages are transmitted within URL parameters.

    • SOAP: Uses SOAP back channel over HTTP messaging to communicate requests from this identity provider to the service provider.

  3. Click OK, then update the Identity Server.

  4. (Conditional) If you have set up trusted providers and have modified these profiles, the providers need to reimport the metadata from this Identity Server.

Creating a Trusted Service Provider for SAML 2.0

You can configure the Identity Server to trust a service provider or an identity provider.

  • When you create a trusted identity provider, you are allowing that identity provider to authenticate the user and the Identity Server acts as a service provider.

  • When you create a trusted service provider, you are configuring the Identity Server to provide authentication for the service provider and the Identity Server acts as an identity provider.

Both of these types of trust relationships require the identity provider to establish a trusted relationship with the service provider and the service provider to establish a trusted relationship with the identity provider.

Prerequisites

Before you can create a trusted provider, you must complete the following tasks:

  • Imported the trusted root of the provider’s SSL certificate into the NIDP trust storeFor instructions, see Section 8.4.4, Managing the Keys, Certificates, and Trust Stores..

  • Shared the trusted root of the SSL certificate of your Identity Server with the other provider so that the administrator can imported it into the provider’s trust store.

  • Obtained the metadata URL from the other provider or an XML file with the metadata.

  • Shared the metadata URL of your Identity Server with the other provider or sent an XML file with the metadata.

  • Enabled the protocol. Click Devices > Identity Servers > Edit, and on the Configuration page, verify that the required protocol in the Enabled Protocols section has been enabled.

Procedure

  1. In the Administration Console, click Devices > Identity Servers > Edit > [Protocol].

    For the protocol, click SAML 2.0.

  2. Click New, then click Service Provider.

    NOTE:By default, the Provider Type > General is selected. You can configure an Identity Server to trust a service provider to establish federation with external service providers. For more information on pre-configured metadata for Google Applications, Office 365, and Salesforce.com, see Section 5.2.11, Configuring Authentication Through Federation for Specific Providers.

  3. Select one of the following sources for the metadata:

    Metadata URL: Specify the metadata URL for a trusted provider. The system retrieves protocol metadata by using the specified URL.

    Examples of metadata URLs for an Identity Server acting as a trusted provider with an IP address 10.1.1.1:

    • Liberty: http://10.1.1.1:8080/nidp/idff/metadata

    • Liberty: https://10.1.1.1:8443/nidp/idff/metadata

    • SAML 2.0: http://10.1.1.1:8080/nidp/saml2/metadata

    • SAML 2.0: https://10.1.1.1:8443/nidp/saml2/metadata

    • OIOSAML: http://10.1.1.1/nidp/saml2/metadata_oiosaml

    • OIOSAML: https://10.1.1.1/nidp/saml2/metadata_oiosaml

    The default values nidp and 8080 are established during product installation; nidp is the Tomcat application name. If you have set up SSL, you can use https and port 8443.

    If your Identity Server and Administration Console are on different machines, use HTTP to import the metadata. If you are required to use HTTPS with this configuration, you must import the trusted root certificate of the provider into the trust store of the Administration Console. You need to use the Java keytool to import the certificate into the cacerts file in the security directory of the Administration Console.

    Linux: /opt/novell/java/jre/lib/security

    Windows Server 2008: \Program Files (x86)\Novell\jre\lib\security

    If you do not want to use HTTP and you do not want to import a certificate into the Administration Console, you can use the Metadata Text option. In a browser, enter the HTTP URL of the metadata. View the text from the source page, save the source metadata, then paste it into the Metadata Text option.

    Metadata Text: An editable field in which you can paste copied metadata text from an XML document, assuming you obtained the metadata via e-mail or disk and are not using a URL. If you copy metadata text from a Web browser, you must copy the text from the page source.

    Manual Entry: Allows you to enter metadata values manually. When you select this option, the system displays the page to enter the required details. See Editing a SAML 2.0 Service Provider’s Metadata.

    Metadata Repositories: Allows you to configure several identity and/or service providers using a multi-entity metadata file available in a central repository. For more information about creating Identity and/or Service Providers see, Creating Identity Providers and Service Providers.

  4. In the Name option, specify a name by which you want to refer to the provider.

  5. Click Next.

  6. Review the metadata certificates and click Finish. The system displays the trusted provider on the protocol page.

  7. Click OK, then update the Identity Server.

    The wizard allows you to configure the required options and relies upon the default settings for the other federation options. For information about how to configure the default settings and how to configure the other available options, see Section 3.9.4, Modifying a Trusted Provider.

Executing Authorization Based Roles Policy During SAML 2.0 Service Provider Initiated Request

Access Manager service provider federation profiles do not currently allow control based on authorization policies. Usually the service providers enforce authorization rules. However, not all service providers have this flexibility. It is recommended not to trust the service provider to enforce such rules. You can now apply an authorization policy to a configured service provider to either allow or not to allow access to the service provider. The Identity Server will evaluate the service provider and will generate the successful/unsuccessful assertions.

Use Case: Company xyz.com uses a CRM application that is protected through the SAML 2.0 service provider. This application should only be accessible to the sales team and not to any other teams. Whenever a user accesses the application through the service provider, it redirects to the Identity Server for validating the user.

Figure 5-24 Executing Authorization Policy Based on Role

The Identity Server should authenticate the user and then check if the user is member of the sales team. If the user is a member, then the Identity Server sends a successful assertion to the service provider. Else, the Identity Server sends an error response to the service provider.

By default, the Identity Server executes these authorization policies after a user is authenticated during spsend. Adding the ALLOW_AUTH_POLICY_EXECUTION=false option in the nidp.properties file will not allow the Identity Server to execute the authorization policies.

If the authorization policy is to deny execution, the Identity Server sends the following message as part of an assertion response. <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"> <samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" /> </samlp:StatusCode> <StatusMessage>Authorization is failed</StatusMessage> </samlp:Status>

For more information about, configuring a brokering for authorization of service providers see Configuring a Brokering for Authorization of Service Providers.

Contracts Assigned to SAML 2.0 Service Provider

During federation, when a service provider initiates an authentication request, contract information may not be available. If the contract information is not available, the Identity Server executes a default contract for validating the user. The step up authentication feature enables you to assign a default contract for service providers in such scenarios.

The following scenario helps you understand the execution of contracts that are assigned to the SAML 2.0 service provider.

Figure 5-25 Step Up Authentication example with two applications:

There are two applications Payroll and HR web applications protected through different service providers and are using Access Manager Identity Server as identity provider. The user wants to use the name/password form contract whenever the user accesses the HR application and wants to use the higher level contract say X509 for the Payroll application. The Identity Server provides ability to execute the appropriate contract that has been assigned to the service provider instead of executing the default contract.

The following procedure allows you to assign a specific contract to the service provider.

  1. Click on Devices > Identity Servers > Edit > > SAML2.0.

  2. Click on configured service provider.

  3. Go to Options > Step Up Authentication contracts and select the contracts from the Available contracts list.

The following table lists the behavior of a service provider request.

Service Provider Request

Result (Identity Server Response if the user is not authenticated)

Service provider request has no contract information to be executed at the Identity Server.

 

1. Identity Server has no contracts set for this service provider as in Step 3.

Execute default contract for validating the user and default contract name will be sent in the response.

2. Identity Server has contract C1 set for this service provider as in Step 3.

C1 will be executed for validating the user and C1 will be sent in response.

Service provider requests execution of contract C1 at the Identity Server.

 

1. Identity Server has no contracts set for this service provider as in Step 3.

C1 will be executed for validating the user and C1 will be sent in response.

2. Identity Server has contract C1 set for this service provider as in Step 3.

C1 will be executed for validating the user and C1 will be sent in response.

3. Identity Server has contract C2 set for this service provider. C2 has trust level check disabled.

C2 will be executed for validating the user and C2 will be sent in response. (Note: This is as good as C1 not available at the Identity Server)

4. Identity Server has contract C2 set for this service provider. C2 has trust level check enabled.

If trust level of C2 >= trust level of C1, then C2 will be executed and C2 will be sent in response.

If trust level of C2 < trust level of C1, then C1 will be executed and C1 will be sent in response as in the previous Access Manager 3.2 release.

If C1 is not available at Identity Server, then C2 is executed and C2 is sent in the response.

Configuring Communication Security for a SAML 2.0 Identity Provider

The security settings control the direct communication between the Identity Server and the identity provider across the SOAP back channel.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 2.0.

  2. Click the name of an identity provider.

  3. On the Trust page, fill in the following fields:

    Name: Specify the display name for this trusted provider. The default name is the name you entered when creating the trusted provider.

    The Security section specifies how to validate messages received from trusted providers over the SOAP back channel. Both the identity provider and the service provider in the trusted relationship must be configured to use the same security method.

    Encrypt name identifiers: Specifies whether you want the name identifiers encrypted on the wire.

    Select one of the following security methods:

    • Message Signing: Relies upon message signing using a digital signature.

    • Mutual SSL: Specifies that this trusted provider provides a digital certificate (mutual SSL) when it sends a SOAP message.

      SSL communication requires only the client to trust the server. For mutual SSL, the server must also trust the client. For the client to trust the server, the server’s certificate authority (CA) certificate must be imported into the client trust store. For the server to trust the client, the client’s CA certificate must be imported into the server trust store.

    • Basic Authentication: Specifies standard header-based authentication. This method assumes that a name and password for authentication are sent and received over the SOAP back channel.

      Send: The name and password to be sent for authentication to the trusted partner. The partner expects this password for all SOAP back-channel requests, which means that the name and password must be agreed upon.

      Verify: The name and password used to verify data that the trusted provider sends.

      Certificate Revocation Check Periodicity: Specifies if the certificate is valid or not. You can define periodicity to validate on start up, on assertion level, or set frequency to hourly/daily.

  4. Click OK twice.

  5. Update the Identity Server.

Configuring Communication Security for a SAML 2.0 Service Provider

The security settings control the direct communication between the Identity Server and the service provider across the SOAP back channel.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 2.0.

  2. Click the name of a service provider.

  3. On the Trust page, fill in the following fields:

    Name: Specify the display name for this trusted provider. The default name is the name you entered when creating the trusted provider.

    The Security section specifies how to validate messages received from trusted providers over the SOAP back channel. Both the identity provider and the service provider in the trusted relationship must be configured to use the same security method.

    Encrypt assertions: Specifies whether you want the assertions encrypted on the wire.

    Encrypt name identifiers: Specifies whether you want the name identifiers encrypted on the wire.

    Certificate Settings: All service providers use the default signing and encryption certificates of the identity provider. Specify custom certificates for a service provider as follows:

    • Identity Provider Signing Certificate: Select a certificate from the keystore and assign it to the service provider.

    • Identity Provider Encryption Certificate: Select a certificate from the keystore and assign it to the service provider.

      NOTE:When you assign custom certificates to each service provider while configuring the identity server, ensure that you export these certificates and custom metadata to the service provider. To retrieve the metadata, click on the metadata link. (This link is available in the note on the Trust page).

      For example, the default certificates will have the following default metadata URL: <IDP URL>/nidp/saml2/metadata.

      The custom certificates will have the following custom metadata URL for a service provider: <IDP URL>/nidp/saml2/metadata?PID=<SP Entity ID >

    • Certificate Revocation Check Periodicity: Specifies if the certificate is valid or not. You can define periodicity to validate on start up, on assertion level, or set frequency to hourly/daily.

    SOAP Back Channel Security Method: Select one of the following security methods.

    • Message Signing: Relies upon message signing using a digital signature.

    • Mutual SSL: Specifies that this trusted provider provides a digital certificate (mutual SSL) when it sends a SOAP message.

      SSL communication requires only the client to trust the server. For mutual SSL, the server must also trust the client. For the client to trust the server, the server’s certificate authority (CA) certificate must be imported into the client trust store. For the server to trust the client, the client’s CA certificate must be imported into the server trust store.

    • Basic Authentication: Specifies standard header-based authentication. This method assumes that a name and password for authentication are sent and received over the SOAP back channel.

      Send: The name and password to be sent for authentication to the trusted partner. The partner expects this password for all SOAP back-channel requests, which means that the name and password must be agreed upon.

      Verify: The name and password used to verify data that the trusted provider sends.

  4. Click OK twice.

  5. Update the Identity Server.

Editing a SAML 2.0 Service Provider’s Metadata

Access Manager allows you to obtain metadata for SAML 2.0 providers. However, metadata for SAML 2.0 might not be available for some service providers, so you can enter the metadata manually. The page for this is available if you clicked the Manual Entry option when you created the trusted provider.

For conceptual information about how Access Manager uses SAML, see Understanding How Access Manager Uses SAML.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 2.0 > [Service Provider] > Metadata.

    You can reimport the metadata (see Step 2) or edit it (see Step 3).

  2. To reimport the metadata, click Reimport on the View page.

    Follow the on-screen instructions to complete the steps in the wizard.

  3. To edit the metadata manually, click Edit.

  4. Fill in the following fields:

    Provider ID: (Required) Specifies the SAML 2.0 metadata unique identifier for the provider. For example, https://<dns>:8443/nidp/saml2/metadata. Replace <dns> with the DNS name of the provider.

    In the metadata, this is the entityID value.

    Metadata expiration: Specifies the date upon which the metadata is no longer valid.

    Want assertion to be signed: Specifies that authentication assertions from the trusted provider must be signed.

    Artifact consumer URL: Specifies where the partner receives incoming SAML artifacts. For example, https://<dns>:8443/nidp/saml2/spassertion_consumer. Replace <dns> with the DNS name of the provider.

    In the metadata, this URL value is found in the AssertionConsumerService section of the metadata.

    Post consumer URL: Specifies where the partner receives incoming SAML POST data. For example, https://<dns>:8443/nidp/saml2/spassertion_consumer. Replace <dns> with the DNS name of the provider.

    In the metadata, this URL value is found in the AssertionConsumerService section of the metadata.

    Service Provider: Specifies the public key certificate used to sign SAML data. You can browse to locate the service provider certificate.

  5. Click Finish.

Configuring a SAML 2.0 Authentication Request

You can configure how an authentication request is federated. When users authenticate to a service provider, they can be given the option to federate their account identities with the preferred identity provider. This process creates an account association between the identity provider and service provider that enables single sign-on and single log-out.

The authentication request specifies how you want the identity provider to handle the authentication process so that it meets the security needs of the Identity Server.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 2.0 > [Identity Provider] > Authentication Card > Authentication Request.

  2. Configure the name identifier format:

    Persistent: A persistent identifier federates the user profile on the identity provider with the user profile on the service provider. It remains intact between sessions.

    The persistent identifier is saved to the user data store and hides the user’s identity to prevent tracking of user activities across different relying parties.

    • After authentication: Specifies that the persistent identifier can be sent after the user has authenticated (logged in) to the service provider. When you set only this option, users must log in locally. Because the user is required to authenticate locally, you do not need to set up user identification.

    • During authentication: Specifies that the persistent identifier can be sent when the user selects the authentication card of the identity provider. Typically, a user is not authenticated at the service provider when this selection is made. When the identity provider sends a response to the service provider, the user needs to be identified on the service provider. If you enable this option, ensure that you configure a user identification method. See Selecting a User Identification Method for Liberty or SAML 2.0.

    Transient: Specifies that a transient identifier, which expires between sessions, can be sent.

    Unspecified: Allows either a persistent or a transient identifier to be sent.

  3. Select one of the following options for the Requested By option:

    Do not specify: Specifies that the identity provider can send any type of authentication to satisfy a service provider’s request, and instructs a service provider to not send a request for a specific authentication type or contract.

    Use Types: Specifies that authentication types should be used.

    Select the type of comparison (for more information, see Understanding Comparison Contexts):

    • Exact: Indicates that the class or type specified in the authentication statement must be an exact match to at least one contract.

    • Minimum: Indicates that the contract must be as strong as the class or type specified in the authentication statement.

    • Better: Indicates the contract that must be stronger than the class or type specified in the authentication statement.

    • Maximum: Indicates that contract must as strong as possible without exceeding the strength of at least one of the authentication contexts specified.

    Select the types from the Available types field to specify which type to use for authentication between trusted service providers and identity providers. Standard types include Name/Password, X.509, Token, and so on.

    Use Contracts: Specifies that authentication contracts should be used.

    Select the type of comparison (for more information, see Understanding Comparison Contexts):

    • Exact: Indicates that the class or type specified in the authentication statement must be an exact match to at least one contract.

    • Minimum: Indicates that the contract must be as strong as the class or type specified in the authentication statement.

    • Better: Indicates the contract that must be stronger than the class or type specified in the authentication statement.

    • Maximum: Indicates that contract must as strong as possible without exceeding the strength of at least one of the authentication contexts specified.

    Select the contract from the Available contracts list. For a contract to appear in the Available contracts list, the contract must have the Satisfiable by External Provider option enabled. To use the contract for federated authentication, the contract’s URI must be the same on the identity provider and the service provider. For information about contract options, see Section 5.1.4, Configuring Authentication Contracts.

    Most third-party identity providers do not support contracts.

  4. Configure the options:

    Response protocol binding: Select Artifact or Post or Let IDP Decide. Artifact and Post are the two methods for transmitting assertions between the authenticating system and the target system.

    If you select Let IDP Decide, the binding is selected based on the profile that is enabled at Identity Provider and the binding selected in the service provider.

    NOTE:The post binding can be configured to be sent as a compressed option. Perform the following steps to achieve this:

    1. Open the nidpconfig.properties file located in /opt/novell/nam/idp/webapps/nidp/WEB-INF/classes.

    2. Modify the following:

      SAML2_POST_DEFLATE_TRUSTEDPROVIDERS: Enter trusted providerʹs name, metadata URI, or provider ID. You can specify multiple trusted providers in a comma separated format. These are the trusted providers who expect SAML2 POST messages in deflated format. In other words, this provider has to send deflated SAML2 POST messages to the listed trusted providers.

      IS_SAML2_POST_INFLATE: Specify True, if this provider will receive deflated SAML2 POST messages from its trusted providers.

    3. Restart the Identity Server by using this command: /etc/init.d/novell-idp restart.

    Allowable IDP proxy indirections: Specifies whether the trusted identity provider can proxy the authentication request to another identity provider. A value of None specifies that the trusted identity provider cannot redirect an authentication request. Values 1-5 determine the number of times the request can be proxied. Select Let IDP Decide to let the trusted identity provider decide how many times the request can be proxied

    Force authentication at Identity Provider: Specifies that the trusted identity provider must prompt users for authentication, even if they are already logged in.

    Use automatic introduction: Attempts single sign-on to this trusted identity provider by automatically sending a passive authentication request to the identity provider. (A passive requests does not prompt for credentials.) The identity provider sends one of the following authentication responses:

    • When the federated user is authenticated at the identity provider: The identity provider returns an authentication response indicating that the user is authenticated. The user gains access to the service provider without entering credentials (single sign-on).

    • When the federated user is not authenticated at the identity provider: The identity provider returns an authentication response indicating that the user is not logged in. The user can then select a card for authentication, including the card for the identity provider. If the user selects the identity provider card, an authentication request is sent to the identity provider. If the credentials are valid, the user is also authenticated to the service provider.

    IMPORTANT:Enable the Use automatic introduction option only when you are confident the identity provider will be up. If the server is down and does not respond to the authentication request, the user gets a page-cannot-be-displayed error. Local authentication is disabled because the browser is never redirected to the login page.

    This option should be enabled only when you know the identity provider is available 99.999% of the time or when the service provider is dependent upon this identity provider for authentication.

  5. Click OK twice, then update the Identity Server.

Understanding Comparison Contexts

When a service provider makes a request for an identity provider to authenticate a user, the authentication request can contain a class or type and a comparison context. The identity provider uses these to determine which authentication procedure to execute. There are four comparison contexts:

  • Exact: Indicates that the class or type specified in the authentication statement must be an exact match to at least one contract.

    For example, when the comparison context is set to exact, the identity provider uses the URI in the request to find an authentication procedure. If an exact URI match is found, the user is prompted for the appropriate credentials. If an exact match is not found, the user is denied access.

  • Better: Indicates the contract that must be stronger than the class or type specified in the authentication statement.

    If the identity provider is a NetIQ Identity Server, the Identity Server first finds the specified class or type and its assigned authentication level. It then uses this information to find a contract that matches the conditions. For example if the authentication level is set to 1 for the class or type, the identity provider looks for a contract with an authentication level that is higher than 1. If one is found, the user is prompted for the appropriate credentials. If more than one is found, the user is presented with the matching cards and is allowed to select the contract. If a match is not found, the user is denied access.

  • Minimum: Indicates that the contract must be as strong as the class or type specified in the authentication statement.

    If the identity provider is a NetIQ Identity Server, the Identity Server first finds the specified class or type and its assigned authentication level. It then uses this information to find a contract that matches the conditions. For example if the authentication level is set to 1 for the class or type, the identity provider looks for a contract with an authentication level of 1 or higher. If one is found, the user is prompted for the appropriate credentials. If more than one is found, the user is presented with the matching cards and is allowed to select the contract. If a match is not found, the user is denied access.

  • Maximum: Indicates that contract must as strong as possible without exceeding the strength of at least one of the authentication contexts specified.

    If the identity provider is a NetIQ Identity Server, the Identity Server first finds the specified classes or types and their assigned authentication levels. It then uses this information to find a contract that matches the conditions. For example if the authentication level is set to 1 for some types and 3 for other types, the identity provider looks for contracts with an authentication level of 3. If a match or matches are found, the user is presented with the appropriate login prompts. If there are no contracts defined with a authentication level of 3, the identity provider looks for a match with an authentication level of 2, or if necessary, level 1. It cannot search below the lowest level of class in the authentication request or higher than the highest level of a class in the authentication request.

When you configure the authentication request, you specify the comparison context for a type or a contract.

Configuring the SAML 2.0 Authentication Response

After you create a trusted service provider, you can configure how your Identity Server responds to authentication requests from the service provider.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 2.0 > [Service Provider] > Authentication Response.

  2. Select the binding method.

    If the request from the service provider does not specify a response binding, you need to specify a binding method to use in the response. Select Artifact to provide an increased level of security by using a back-channel means of communication between the two servers. Select Post to use HTTP redirection for the communication channel between the two servers. If you select Post, you might want to require the signing of the authentication requests. See Configuring the General Identity Provider Options.

    NOTE:The post binding can be configured to be sent as a compressed option. Perform the following steps to achieve this:

    1. Open the nidpconfig.properties file located in /opt/novell/nam/idp/webapps/nidp/WEB-INF/classes.

    2. Modify the following:

      SAML2_POST_DEFLATE_TRUSTEDPROVIDERS: Enter trusted providerʹs name, metadata URI, or provider ID. You can specify multiple trusted providers in a comma separated format. These are the trusted providers who expect SAML2 POST messages in deflated format. In other words, this provider has to send deflated SAML2 POST messages to the listed trusted providers.

      IS_SAML2_POST_INFLATE: Specify True, if this provider will receive deflated SAML2 POST messages from its trusted providers.

    3. Restart the Identity Server by using this command: /etc/init.d/novell-idp restart.

  3. Specify the identity formats that the Identity Server can send in its response. Select the box to choose one or more of the following:

    • Persistent: Specifies that a persistent identifier, which is written to the directory and remains intact between sessions, can be sent.

    • Transient: Specifies that a transient identifier, which expires between sessions, can be sent.

    • E-mail: Specifies that an e-mail attribute can be used as the identifier.

    • Kerberos: Specifies that a Kerberos token can be used as the identifier.

    • X509: Specifies that an X.509 certificate can be used as the identifier.

    • Unspecified: Specifies that an unspecified format can be used and any value can be used. The service provider and the identity provider need to agree on the value that is placed in this identifier.

  4. Use the Default button to select the name identifier that the Identity Server should send if the service provider does not specify a format.

    If you select E-mail, Kerberos, x509, or unspecified as the default format, you should also select a value. See Step 5.

    IMPORTANT:If you have configured the identity provider to allow a user matching expression to fail and still allow authentication by selecting the Do nothing option, you need to select Transient identifier format as the default value. Otherwise the users who fail the matching expression are denied access. To view the identity provider configuration, see Defining User Identification for Liberty and SAML 2.0.

  5. Specify the value for the name identifier.

    The persistent and transient formats are generated automatically. For the others, you can select an attribute. The available attributes depend upon the attributes that you have selected to send with authentication (see Configuring the Attributes Obtained at Authentication). If you do not select a value for the E-mail, Kerberos, X509, or Unspecified format, a unique value is automatically generated.

  6. To specify that this Identity Server must authenticate the user, disable the Use proxied requests option. When the option is disabled and the Identity Server cannot authenticate the user, the user is denied access.

    When this option is enabled, the Identity Server checks to see if other identity providers can satisfy the request. If one or more can, the user is allowed to select which identity provider performs the authentication. If a proxied identity provider performs the authentication, it sends the response to the Identity Server. The Identity Server then sends the response to the service provider.

  7. When the Include the Session Timeout attribute in the assertion option is enabled, the Identity Server sends the Identity Server session time out value to the service provider in the assertion.

  8. You can manually set the assertion validity time for the SAML service provider in the Assertion Validity field to accommodate clock skew between the service provider and SAML Identity Server (IDP).

  9. Click OK twice, then update the Identity Server.

Defining Options for SAML 2.0

OIOSAML enables service providers to use external authentication services, implements single sign-on across disparate systems, and establishes a foundation for federated identity management. OIOSAML enables reuse of authentication services and consistent application of security technology.

You can implement the Single Logout Profile of OIOSAML. This profile enables you to logout from all service providers whose session originate from a particular identity provider. For using this profile, you should use a front channel binding.

Defining Options for SAML 2.0 Identity Provider

  1. In Administration Console, click Devices > Identity Servers > Servers > Edit > SAML 2.0 > Identity Provider > Options.

  2. Select the required options:

    OIOSAML Compliance: Enable this option to make the identity provider OIOSAML compliant.

    Enable Front Channel Logout: After this option is enabled, the service provider initiates a logout at the identity provider by using the HTTP Redirect method.

  3. Click OK.

Defining Options for SAML 2.0 Service Provider

NetIQ Access Manager can be used as an identity provider for several service providers.You can configure a specific authentication contract that is required for a Service provider. If more than one authentication contract is configured for a service provider, the contract having minimum level will be selected.

When providing authentication to a service provider, the identity server ensures that the user is authenticated by the required contract. When a user is not authenticated or when user is authenticated, but the authenticated contracts do not satisfy the required contracts, user will be prompted to authenticate with required contract. This is called step up authentication.

If no required contract is configured, then the default contract is executed.

NOTE:This step up authentication is supported only for Intersite Transfer Service (identity provider initiated) requests on Liberty and works for both identity and service provider initiated requests for SAML 2.0.

To Define Options for SAML 2.0 Service Provider

  1. In Administration Console, click Devices > Identity Servers > Servers > Edit > SAML 2.0 > Service Provider > Options.

  2. Select OIOSAML Compliance to make the service provider OIOSAML compliant. The OIOSAML attribute set is automatically populated with the required attributes to send with authentication after selecting this check box.

  3. Select the required step up authentication contracts from the Available contracts list and move them to the Selected contracts list. This is to provide the step up authentication for the service provider.

    NOTE:The contract that is configured first in the Selected contracts list will only be executed. This is applicable only for SAML 2.0.

  4. Click OK.

Defining Session Synchronization for the A-Select SAML 2.0 Identity Provider

If a user session is active on the Service Provider, the service provider periodically sends session synchronization to the Identity Server to maintain the session. You must configure the properties for the session synchronization between the service provider and the target Identity provider.

  1. In the Administration Console, click Devices > Identity Servers > Servers > Edit > Liberty or SAML 2.0 > Identity Provider > Options.

  2. Click New > Add Properties, then specify the following values:

    Property Name: Specify config.aselect.sessionsync.enabled

    Property Value: Specify true.

  3. For session synchronization, add two options, one to enable the session synchronization and the other to provide the URL to which synchronization message should be sent.

    The session synchronization message is sent from the Access Manager Service Provider to the A-Select Identity Provider, in tandem with the Access Gateway ESP's activity update. The session synchronization message is sent only if the user session is active at the Access Gateway portal, which is the ESP to the Access Manager Service Provider. If you log in directly to the Access Manager Service Provider, even if the session is active, the session synchronization message is not sent to the A-Select Identity Provider.

  4. Click OK, then update the Identity Server.

Configuring the Liberty or SAML 2.0 Session Timeout

When you are active on a session on the service provider and a timeout occurs, the service provider initiates a logout.You can configure this timeout by using the web.xml parameter in the Access Gateway ESP, then ESP initiates a logout message to the Access Manager Service Provider over the SOAP back channel when the timeout is reached. After the Service Provider receives this message, it creates a SAML 2.0 logout request to the remote Identity Provider over SOAP.

To send session timeout message:

  1. Open the web.xml file located at:

    Linux: /opt/novell/nam/idp/webapps/nidp/WEB-INF/

    Windows Server 2008: \Program Files (x86)\Novell\Tomcat\webapps\nidp\WEB-INF/

  2. Add the following lines to the file:

            <context-param>
                <param-name>notifysessionTimetoIDP</param-name>
                <param-value>true</param-value>
        </context-param>

    ESP will send a ESP session timeout message then on timeout, the service provider will send a samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol request to the remote Identity provider.

  3. Save the file, then copy it to each Identity Server in the cluster.

  4. Restart Tomcat on each Identity Server in the cluster using the following command:

    Linux: Enter the following command:

    /etc/init.d/novell-idp restart

    Windows: Enter the following commands:

    net stop Tomcat7

    net start Tomcat7

Session Termination

If you set the session synchronization between the Service Provider and remote Identity Provider, then the remote Identity Provider never sends the logout request to the active Service Provider.

Modifying the Authentication Card for Liberty or SAML 2.0

When you create an identity provider, you must also configure an authentication card. After it is created, you can modify it.

  1. In the Administration Console, click Devices > Identity Servers > Edit > [Protocol] > [Identity Provider] > Authentication Card.

  2. Modify the values in one or more of the following fields:

    ID: If you have need to reference this card outside of the user interface, specify an alphanumeric value here. If you do not assign a value, the Identity Server creates one for its internal use. The internal value is not persistent. Whenever the Identity Server is rebooted, it can change. A specified value is persistent.

    Text: Specify the text that is displayed on the card to the user. This value, in combination with the image, should identify to the users, which provider they are logging into.

    Image: Specify the image to be displayed on the card. Select the image from the drop-down list. To add an image to the list, click <Select local image>.

    Show Card: Determine whether the card is shown to the user, which allows the user to select and use the card for authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.

    NOTE:Do not disable the Show Card option for default contracts.

    Passive Authentication Only: Select this option if you do not want the Identity Server to prompt the user for credentials. If the Identity Server can fulfill the authentication request without any user interaction, the authentication succeeds. Otherwise, it fails.

    Satisfies Contract: Select the required contracts from the Available contracts list and move them to the Satisfies contract list. This creates a mapping between external provider class reference to local authentication contracts.

  3. Click OK twice, then update the Identity Server.

Enabling or Disabling SAML Tags

Enabling or Disabling SAML Tags by using the Administration Console

To enable SAML tags in the Administration Console, perform the following steps:

  1. In the Administration Console, click Devices > Identity Servers > Servers > Edit > SAML 2.0.

  2. Based on whether the tag is for a service provider or an identity provider, select Service Provider or Identity Provider and then select Options.

  3. Click New and specify Property Name and Value.

    You can enable the following SAML tags in the Administration Console:

    Property Name

    Value

    Description

    SAML2_SEND_ACS_INDEX

    True

    Set the value to true to send AssertionConsumerServiceIndex with AuthnRequest.

    SAML2_SEND_ACS_URL

    True

    Set the value to true to send AssertionConsumerServiceURL with AuthnRequest.

    Extensions

    <samlp:Extensions><OnBehalfOf xmlns="https://idporten.difi.no/idporten-extensions">interaktor</OnBehalfOf></samlp:Extensions>

    After setting this value, Access Manager acting as a SAML 2.0 service provider makes an OnBehalfOf authentication request by using SAML extensions.

    SAML2_POST_SIGN_RESPONSE_TRUSTEDPROVIDERS

    True/False

    For identity providers: Set the value to true to send the signed SAML 2.0 post responses to trusted providers.

    For service providers: Set the value to true to verify the signed SAML 2.0 post responses.

    SAML2_AVOID_NAMEIDPOLICY

    True/False

    Set the value to true to not include NameIDPolicy in the SAML 2.0 request.

    SAML2_SIGN_METHODDIGEST_SHA256

    True/False

    Set the value to true to use SHA256 algorithm as signing algorithm for assertions.

    SAML2_AVOID_ISPASSIVE

    True/False

    Set the value to true to not include IsPassive as part of the SAML 2.0 request.

    SAML2_AVOID_CONSENT

    True/False

    Set the value to true to not include Consent as part of the SAML 2.0 request.

    SAML2_AVOID_PROTOCOLBINDING

    True/False

    Set the value to true to not include ProtocolBinding as part of the SAML 2.0 request

    SAML2_AVOID_PROXYCOUNT

    True/False

    Set the value to true to not include ProxyCount in the SAML 2.0 request

Enabling or Disabling SAML Tags by Using nidpconfig.proprteties

Enable or disable the following SAML Authentication Request tags by using the nidpconfig.properties file. These properties will be set at the Access Manager Identity Server when it is configured as a SAML 2.0 service provider. Restart or wait until Access Manager refreshes the nidpconfig.properties file.

Property Name

Description

SAML2_ATTRIBUTE_CONSUMING_INDEX

The value is of format {SPProviderID}->{numeric value}. {SPProviderID} will be replaced by the actual provider id of this service provider. This will set the AttributeConsumingIndex of SAML 2.0 requests to the numeric value specified here.

For example, https://nam.rtreyresearch.net:8443/nidp/saml2/metadata->2.

SAML2_AVOID_SPNAMEQUALIFIER

If set to true, SPNameQualifier is not included as part of SAML 2.0 request.

SAML2_CHANGE_ISSUER

The value is of format {SPProviderID}->{issuer name}. {SPProviderID} will be replaced by the actual provider ID of the service provider. This will set the issuer of SAML 2.0 requests to the issuer name specified here.

For example, https://nam.rtreyresearch.net:8443/nidp/saml2/metadata->https://saml.mariagerfjord.dk:8443/nidp/saml2/metadata.

SAML2_AVOID_SPNAMEQUALIFIER_TO

Set the value to true to send SPNAMEQUALIFIER in NAMEIDENTIFER with assertion.

You can set this key in the nidpconfig.properties file in the following format:

https://<host>:<port>/nidp/saml2/metadata ->true,https://<host>:<port>/nidp/saml2/metadata/spnameidentifier ->false,https://<host>:<port>/nidp/saml2/metadata/spnameidentifier ->true

SAML_ASSERTION_INCLUDE_MILLISECS

Set the value to true to get SAML responses or requests including the timestamp with millisecond in IssueInstant.

SAML2_NAMEID_ATTRIBUTE_NAME

Set the ldapattribute name to send the SAML response with the LDAP attribute value in nameidentifier.

SAML2_AVOID_AUDIENCE_RESTRICTION

Set the value to true to avoid sending the audience restriction information with assertion.
Sample XML File When All SAML Tags Are Set to True

The following sample xml file will be displayed when all the SAML tags are set to true and SAML2_CHANGE_ISSUER and SAML2_ATTRIBUTE_CONSUMING_INDEX tags are not set.

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" AssertionConsumerServiceIndex="2" ForceAuthn="false" ID="id5R6u1JFtay7eK.il97Q3eRl34u8" IssueInstant="2013-01-18T06:11:26Z" Version="2.0">

<saml:Issuer> >

</samlp:AuthnRequest>

Sample XML File When All SAML Tags Are Set to False

The following sample xml file will be displayed when all the SAML tags are set to false and SAML2_CHANGE_ISSUER and SAML2_ATTRIBUTE_CONSUMING_INDEX properties are set in the nidpconfig.properties file.

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" AssertionConsumerServiceIndex="0" AttributeConsumingServiceIndex="2"Consent="urn:oasis:names:tc:SAML:2.0:consent:unavailable" ForceAuthn="false" ID="idoeZTKq7FOs5MsCigBBCwp30lqD0" IsPassive="false"IssueInstant="2013-01-23T05:25:32Z"ProtocolBindingProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"Version="2.0">

<saml:Issuer> >

<samlp:NameIDPolicyAllowCreate="true"Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"SPNameQualifier="https://nam.rtreyresearch.net:8443/nidp/saml2/metadata"/><samlp:Scoping ProxyCount="5"/>

</samlp:AuthnRequest>

Configuring Multiple SAML 2.0 Service Providers on the Same Host for a Single SAML Identity Provider

When the same Access Manager server hosts more than one SAML service provider and federate with another Access Manager acting as an identity provider for these service providers, Access Manager should send different sets of attributes in SAML 2.0 assertions to these service providers.

Perform the following steps to create multiple service providers on the same Access Manager host:

  1. To create multiple service providers from the same identity provider metadata, manually modify the identity provider's metadata's entityID for each service provider. You can import the metadata text that was edited into the Access Manager configuration to create service providers with different entity IDs.

    For more information about how to create a SAML 2.0 service provider, see Creating a Trusted Service Provider for SAML 2.0.

  2. In the Administration Console of the SAML 2.0 identity provider, click Devices > Identity Servers > Servers > Edit > SAML 2.0 > Service Provider > Options.

  3. Set the SAML2_AVOID_AUDIENCE_RESTRICTION property to true. Setting this property to true avoids audience restriction in the SAML 2.0 assertion.

  4. To avoid the spnamequalifier attribute in nameidentifier of the assertion, do the following:

    1. Go to Access Manager Identity Server of the SAML 2.0 service provider and open the nidpconfig.properties file.

      Linux: /opt/novell/nids/lib/webapp/WEB-INF/classes/nidpconfig.properties

      Windows: Novell\Tomcat\webapps\nidp\WEB-INF\classes\nidpconfig.properties

    2. Add the following:

      SAML2_AVOID_SPNAMEQUALIFIER_TO = <entityID of the service provider>->true

      For example, if you have configured three service provider and you want to avoid sending assertion to the service provider with entity ID "https://<service provider host>:<port>/nidp/saml2/metadata/spnameidentifier2" then add the following entry:

      SAML2_AVOID_SPNAMEQUALIFIER_TO = https://< service provider host>:<port>/nidp/saml2/metadata/spnameidentifier1->true,https://< service provider host>:<port>/nidp/saml2/metadata/spnameidentifier2->true,https://< service provider host>:<port>/nidp/saml2/metadata/spnameidentifier3->true

  5. Restart the Identity Server.

NOTE:This is possible only when the identity provider and service providers are deployed on Access Manager.

Configuring Active Directory Federation Services with SAML 2.0 for Single Sign-On

This section describes step-by-step instructions for configuring a basic identity federation deployment between Microsoft Active Directory Federation Services 2.0 (AD FS 2.0) and Access Manager by using the Security Assertion Markup Language (SAML) 2.0 protocol, specifically its Web Browser SSO Profile and HTTP POST binding.

You can configure AD FS 2.0 as the claims provider and Access Manager as the relying party, or you can configure Access Manager as the claims provider and AD FS 2.0 as the relying party or service provider.

Prerequisites and Requirements

  • Two servers, one to host AD FS 2.0 and the other to host Access Manager.

  • AD FS 2.0 is deployed.

  • ADFS 2.0 with WIF is deployed.

    The test deployment that was created in the AD FS 2.0 Federation with a Windows Identity Foundation (WIF) application is used as starting point for this deployment. A single Windows Server 2008 R2 instance (fsweb.contoso.com) is used to host both the AD FS 2.0 federation server and a WIF sample application. It presumes the availability of a Contoso.com domain, in which fsweb.contoso.com is a member server. The same computer can act as the domain controller and federation server in the test deployments.

  • ADFS 2.0 with SharePoint 2010 is deployed.

    The test deployment that was created in Configuring SharePoint 2010 AAM applications with AD FS 2.0 is used as starting point for this deployment. A single Windows Server 2008 R2 instance (fsweb.contoso.com) is used to host the AD FS 2.0 federation server and a Windows Server 2008 R2 instance (SP2010) is used to host the SharePoint 2010 application. It presumes the availability of a Contoso.com domain, in which fsweb.contoso.com is a member server. The same computer can act as the domain controller and federation server in the test deployments.

  • Access Manager is deployed.

    The Access Manager environment in this deployment is hosted by a fictitious company called nam.example.com. Only the Identity Server component of Access Manager is required for this federation. For more information about installation and deployment of Access Manager, see the Access Manager documentation.

NOTE:You can download the evaluation version of Access Manager from NetIQ’s download portal.

Linux Environment

  • Access Manager 3.1 SP4, 3.1 SP5, 3.2.x, or 4.0.

  • SUSE Linux Enterprise Server (SLES) 11 SP1 64-bit or a higher version.

NOTE:Access Manager supports both Windows and Linux. This section discusses only the Linux environment.

IP Connectivity

Ensure that the Access Manager (nam.example.com) and AD FS 2.0 (fsweb.contoso.com) systems have IP connectivity between them. The Contoso.com domain controller, if it is running on a separate computer, does not require IP connectivity to the Access Manager system. If the Access Manager firewall is set up, open the ports required for the Identity Server to communicate with the Administration Console.

For more information about these ports, see Setting Up Firewalls in the NetIQ Access Manager 4.1 Installation and Upgrade Guide.

For HTTPS communication, the Access Manager Identity Server uses TCP 8443 by default. Your browsers need to access this port when using the HTTP POST Binding. Or, you can change this port to 443 by using iptables. See Translating the Identity Server Configuration Port in the NetIQ Access Manager 4.1 Installation and Upgrade Guide.

For back-channel communication with cluster members, you need to open two consecutive ports for the cluster, such as 7801 and 7802. The initial port (7801) is configurable. See Configuring a Cluster with Multiple Identity Servers.

All federation servers (AD FS and Access Manager) need access to a reliable Network Time Protocol (NTP) time source.

Name Resolution

The hosts file on the AD FS 2.0 computer (fsweb.contoso.com) is used to configure name resolution of the partner federation servers and sample applications.

Clock Synchronization

Federation events have a short time to live (TTL). To avoid errors based on time-outs, ensure that both computers have their clocks synchronized.

NOTE:For information about how to synchronize a Windows Server 2008 R2 domain controller to an Internet time server, see article 816042 in the Microsoft Knowledge Base.

On SLES 11 SP1 64-bit or a higher version, use the command sntp -P no -p pool.ntp.org to synchronize time with the Internet time server.

Configuring Access Manager as a Claims or Identity Provider and AD FS 2.0 as Relying Party or Service Provider

This section explains how to configure a setup in which an Access Manager user gets federated access to the WIF sample application or SharePoint 2010 through AD FS 2.0. This setup uses the SAML 2.0 POST profile.

Configuring Access Manager

NOTE:To deploy this identity federation for Access Manager 3.1 SP4 or higher, create a new contract with the “urn:oasis:names:tc:SAML:2.0:ac:classes:Password” URI and with the name password form method. Configure this contract as the default contract.

Using Metadata to Add a New Service Provider Connection

The first step in configuring Access Manager is to use the AD FS metadata to add a service provider for Access Manager.

Getting the AD FS 2.0 Metadata

  1. Access the AD FS server metadata URL at https://<<ADFS (hostname or IP)/FederationMetadata/2007-06/FederationMetadata.xml.

  2. Save the AD FS metadata file.

  3. Open the saved AD FS metadata file in Notepad, WordPad, or in any XML editor.

  4. Remove the <RoleDescriptor> tags from the metadata. For example, remove the following tags:

    <RoleDescriptor xsi:type="fed:ApplicationServiceType" protocolSupportEnumeration=http://..................... ……> ……….</RoleDescriptor>

      <RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration=http://.....  ………> </RoleDescriptor>

  5. Save the changes.

Using the Metadata to Add a New Service Provider Connection

  1. In the Access Manager Administration Console, click Devices > Identity Server > Edit > SAML 2.0.

  2. Click New > Add Service Provider.

  3. In the Name field, specify a name by which you want to refer to the provider.

  4. Select Metadata Text from the Source list.

  5. Paste the copied AD FS metadata that you saved in Step 5 into the Text field.

  6. Click Next > Finish.

  7. Update the Identity Server.

Adding an AD FS Server Trusted Certificate

  1. Download the certificate authority (CA) certificate from the AD FS server.

  2. In the Access Manager Administration Console, click Security > Certificates > Trusted Roots.

  3. Click Import.

  4. Specify a name for the certificate and browse for the ADFS certificate.

  5. Click OK.

  6. Click Uploaded AD FS CA.

  7. Click Add to Trusted Store and select config store.

  8. Update the Identity Server.

Creating an Attribute Set in Access Manager

  1. In the Access Manager Administration Console, click Devices > Identity Servers > Shared Settings > Attribute Sets > click New.

  2. Provide the attribute set name as adfs-attributes.

  3. Click Next with the default selections.

  4. In the Create Attribute Set section, click New.

  5. Select ldapattribute mail from the Local Attribute list.

  6. Specify emailaddress in the Remote attribute field.

  7. Select http://schemas.xmlsoap.org/ws/2008/06/identity/claims/ from the Remote namespace list.

  8. Click OK.

  9. Click New.

  10. Select All Roles from the Local Attribute list.

  11. Specify roles in the Remote Attribute field.

  12. Select http://schemas.xmlsoap.org/ws/2008/06/identity/claims/ from the Remote namespace list.

  13. Click OK.

  14. Update the Identity Server.

Configuring the Service Provider in Access Manager

  1. In the Access Manager Administration Console, select the ADFS service provider in the SAML 2.0 tab.

  2. Click Authentication Response.

  3. Select Binding to POST.

  4. Specify the name identifier format default value and select unspecified along with the defaults.

  5. Click Attributes.

  6. Select adfs-attributes from the Attribute Set list.

  7. Select the required attributes to be sent with authentication. For example, the mail and cn attributes.

  8. Click OK.

  9. Update the Identity Server.

Exporting the Identity Provider Metadata to a File

Access https://<<Identity server IP / dns name>>:8443/nidp/saml2/metadata in a browser and save the page as an XML file, such asnam_metadata.xml. AD FS 2.0 uses this file to automate the setup of the Access Manager Claims Provider instance.

Configuring AD FS 2.0
Using Metadata to Add Claims Provider

You need to use the metadata import capabilities of AD FS 2.0 to create the Example.com claims provider. The metadata includes the public key that is used to validate security tokens signed by Access Manager.

Using Metadata to Add a Relying Party

  1. In AD FS 2.0, in the console tree, right-click the Claims Provider Trusts folder, then click Add Claims Provider Trust to start the Add Claims Provider Trust Wizard.

  2. Click Start.

  3. On the Select Data Source page, select Import data about the claims provider from a file.

  4. In the Federation metadata file location field, click Browse.

  5. Navigate to the location where you saved nam_metadata.xml, click Open, then click Next.

  6. On the Specify Display Name page, type NAM Example.

  7. Click Next > Next > Close.

Editing Claim Rules for the Claims Provider Trust

The following claim rule describes how the data from Access Manager is used in the security token that is sent to the WIF sample application or SharePoint 2010.

  1. In AD FS 2.0, click Relying Party Trusts, right click WIF Sample App, and then click Edit Claim Rules.

    or

    In the AD FS 2.0 center pane, under Claims Provider Trusts, right-click NAM Example, then click Edit Claim Rules.

  2. On the Acceptance Transform Rules tab, click Add Rule.

  3. On the Select Rule Template page, select the Pass Through or Filter an Incoming Claim option.

  4. Click Next.

  5. On the Configure Claim Rule page, use the following values:

    Name

    Value

    Claim rule name

    Name ID Rule

    Incoming claim type

    Name ID

    Incoming name ID format

    Unspecified

  6. Select the Pass through all claim values option and click Finish.

  7. Click Add Rule.

  8. On the Select Rule Template page, select the Pass Through or Filter an Incoming Claim option.

  9. Click Next.

  10. On the Configure Claim Rule page, under Claim rule name, use the following values:

    Name

    Value

    Claim rule name

    Name Rule

    Incoming claim type

    Name

  11. Leave the Pass through all claim values option selected and click Finish.

  12. To acknowledge the security warning, click Yes.

  13. Click OK.

  14. Click Add Rule.

  15. On the Select Rule Template page, select the Pass Through or Filter an Incoming Claim option.

  16. Click Next.

  17. On the Configure Claim Rule page, in the Claim rule name field, use the following values:

    Name

    Value

    Claim rule name

    Email Rule

    Incoming claim type

    E-Mail Address

  18. Leave the Pass through all claim values option selected and click Finish.

  19. To acknowledge the security warning, click Yes.

  20. Click OK.

Editing Claim Rules for the WIF Sample Application

At this point, incoming claims have been received at AD FS 2.0, but rules that describe what to send to the WIF sample application have not yet been created. You need to edit the existing claim rules for the sample application to take into account the new Access Manager external claims provider.

  1. In AD FS 2.0, click Relying Party Trusts.

  2. Right-click WIF Sample App, then click Edit Claim Rules.

  3. On the Issuance Transform Rules tab, click Add Rule.

  4. On the Select Rule Template page, click Pass Through or Filter an Incoming Claim > Next.

  5. On the Configure Claim Rule page, enter the following values:

    Name

    Value

    Claim rule name

    Pass Name Rule

    Incoming claim type

    Name

  6. Leave the Pass through all claim values option selected, then click Finish.

  7. On the Issuance Transform Rules tab, click Add Rule.

  8. On the Select Rule Template page, click Pass Through or Filter an Incoming Claim.

  9. Click Next.

  10. On the Configure Claim Rule page, enter the following values:

    Name

    Value

    Claim rule name

    Pass Name ID Rule

    Incoming claim type

    Name ID

    Incoming Name ID format

    Unspecified

  11. Leave the Pass through all claim values option selected, then click Finish.

  12. Click OK.

NOTE:If you changed the rules while federating AD FS 2.0 with the WIF sample application, ensure that you add the Permit All Users issuance rules back to the WIF sample application. See Step 6: – Change Rules in the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide.

Or, as an alternative, add a new Permit or Deny Users Based on an Incoming Claim rule allowing incoming Name ID = john@example.com to access the application.

Editing Claim Rules for the SharePoint 2010 Application

At this point, incoming claims have been received at AD FS 2.0, but the rules that describe what to be sent to the SharePoint 2010 application have not yet been created. You need to edit the existing claim rules for the SharePoint 2010 application, which is added as relying party to ADFS 2.0, to configure the new Access Manager external claims provider.

Editing the Claim Rules for the SharePoint 2010 Application

  1. In AD FS 2.0, click Relying Party Trusts.

  2. Right-click SP2010, then click Edit Claim Rules.

  3. On the Issuance Transform Rules tab, click Add Rule.

  4. On the Select Rule Template page, click Pass Through or Filter an Incoming Claim > Next.

  5. On the Configure Claim Rule page, enter the following values:

    Name

    Value

    Claim rule name

    Pass eMail Rule

    Incoming claim type

    Email Address

  6. Leave the Pass through all claim values option selected and click Finish.

Changing the AD FS 2.0 Signature Algorithm

By default, Access Manager uses the Secure Hash Algorithm 1 (SHA-1) for signing operations. By default, AD FS 2.0 expects partners to use SHA-256. Complete the following steps to set AD FS 2.0 to expect SHA-1 for interoperability with Access Manager.

NOTE:The same procedure is recommended for AD FS 2.0 relying party trusts that use Access Manager. If the Access Manager SP signs authnRequests, artifact resolution requests, or logout requests, AD FS 2.0 errors occur unless this signature algorithm setting is changed.

  1. In AD FS 2.0, click Claims Provider Trusts.

  2. Right-click NAM Example > Properties.

  3. On the Advanced tab, select SHA-1 in the Secure Hash Algorithm list.

  4. Click OK.

Using Certificates and Certificate Revocation Lists

For security reasons, production federation deployments require the use of digitally signed security tokens, and optionally allows encryption of the security token contents. Self-signed private key certificates, which are generated from inside the AD FS 2.0 and Access Manager products, are used for signing security tokens.As an alternative, organizations can use a private key certificate that is issued by a certificate authority (CA) for signing and encryption. The primary benefit of using CA-issued certificates is the ability to check for possible certificate revocation against the certificate revocation list (CRL) from the issuing CA. Also, to avoid the untrusted certificate messages in browsers, the trusted root certificate of the CA must also be imported into your browsers. Many well-known CA's trusted roots are included with common browsers. Using one of these existing CAs to mint your certificates also prevents the untrusted certificate messages.

In AD FS 2.0 and in Access Manager, CRL checking is enabled by default for all partner connections, if the certificate being used by the partner includes a CRL Distribution Point (CDP) extension. This has implications in federation deployments between Access Manager and AD FS 2.0:

  • If a signing/encryption certificate provided by one side of a federation includes a CDP extension, that location must be accessible by the other side's federation server. Otherwise, CRL checking fails, resulting in a failed access attempt. The CDP extensions are added by default to certificates that are issued by Active Directory Certificate Services (AD CS) in Windows Server 2008 R2.

  • If the signing/encryption certificate does not include a CDP extension, no CRL checking is performed by AD FS 2.0 or Access Manager.

Disabling CRL Checking in the Linux Identity Server

  1. In Access Manager 3.1 SP4 or 3.1 SP5, modify the /opt/novell/nam/idp/conf/tomcat7.conf file and add JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"

    or

    In Access Manager 3.2.x or 4.0, modify /opt/novell/nam/idp/conf/tomcat7.conf and add JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"

  2. To apply the changes, restart the Identity Server by running the /etc/init.d/novell-idp restart command.

Disabling CRL Checking in AD FS 2.0

  1. Click Start > Administrative Tools > Windows PowerShell Modules.

  2. Enter the following command at the PowerShell command prompt:

    set-ADFSClaimsProviderTrust -TargetName "NAM Example"

    -SigningCertificateRevocationCheck None

NOTE:You can make many configuration changes to AD FS 2.0 by using the Windows PowerShell command line and scripting environment. For more information, see the AD FS 2.0 Windows PowerShell Administration section of the AD FS 2.0 Operations Guide and the AD FS 2.0 Cmdlets Reference.

Example Scenario: Access Manager as the Claims Provider and AD FS 2.0 as the Relying Party
Accessing the WIF Sample Application

In this scenario, John from Example.com accesses the Contoso WIF sample application.

NOTE:Clear all the cookies in the Internet Explorer on the AD FS 2.0 computer (fsweb.contoso.com). To clear the cookies, click Tools > Internet Options > Delete under Browsing History, and then select cookies for deletion.

  1. On the AD FS 2.0 computer, open a browser window, then navigate to https://fsweb.contoso.com/ClaimsAwareWebAppWithManagedSTS/default.aspx.

    The first page prompts you to select your organization from a list.

  2. Select NAM Example, then click Continue to sign in.

    When only one Identity Provider is available, AD FS 2.0 forwards the request to that Identity Provider by default.

  3. The NAM login page appears. Type the user name john, type the password test, then click Login.

Accessing the SharePoint 2010 Application

The user's email ID is used as the mapped attribute to access the SharePoint 2010 application. Assume that a user is created in the NetIQ Identity Server. The email ID configured for this user is namuser1@namidp.com.

NOTE:Clear all the cookies in the Internet Explorer on the AD FS 2.0 computer (fsweb.contoso.com). To clear the cookies, click Tools > Internet Options > Delete under Browsing History, then select cookies for deletion.

  1. Ensure that an email ID has been configured for the user in the Access Manager user store.

    For this example, use namuser1@namidp.com.

  2. Access the SharePoint 2010 application.

    The user is redirected to AD FS 2.0.

  3. Select NetIQ Identity Server.

    The user is redirected to the NAM IDP nidp page for authentication.

  4. Provide namuser1 as the username and password.

    After authentication, the user is redirected to the SharePoint application.

Configuring AD FS 2.0 as the Claims or Identity Provider and Access Manager as the Relying Party or Service Provider

This section explains how to configure an application through AD FS 2.0 that gets federated access to an application by using Access Manager. The setup uses the SAML 2.0 POST profile.

Configuring Access Manager

The AD FS metadata is used to add an Identity Provider to Access Manager.

Getting the AD FS 2.0 Metadata

  1. Access the AD FS server metadata by going to https://<<ADFS hostname or IP/FederationMetadata/2007-06/FederationMetadata.xml

  2. Save the AD FS metadata data.

  3. Open the AD FS metadata file in Notepad, WordPad, or an XML editor).

  4. Remove the <RoleDescriptor> tags from the metadata.

    For example, remove the following tags:

      "<RoleDescriptor xsi:type="fed:ApplicationServiceType"
              protocolSupportEnumeration=http://..................... ……> ……….</RoleDescriptor>

      "<RoleDescriptor xsi:type="fed:SecurityTokenServiceType"
              protocolSupportEnumeration=http://.....  ………> </RoleDescriptor>

  5. Save the changes.

Using the Metadata to Add a New Identity Provider Connection

  1. In the Access Manager Administration Console, select Devices > Identity Server.

  2. Click Edit.

  3. Select SAML 2.0.

  4. Click New > Identity Provider.

  5. Specify the name as ADFS in the Name field.

  6. Select Metadata Text from the Source list.

  7. Paste the copied ADFS metadata that you saved in Step 5 into the Text field.

  8. Click Next.

  9. Specify an alphanumeric value that identifies the card in the ID field.

  10. Specify the image to be displayed on the card in the Image field.

  11. Update the Identity Server.

Adding the AD FS Server Trusted Certificate

  1. Retrieve the AD FS server's CA trusted root certificate.

  2. In the Access Manager Administration Console, select Security > Certificates.

  3. Select Trusted Roots.

  4. Click Import.

  5. Specify the certificate name, and browse for the AD FS certificate authority.

  6. Click OK.

  7. Click uploaded AD FS CA.

  8. Click Add to Trusted Store and select config store.

  9. Update the Identity Server.

Configuring the Identity Provider in Access Manager

  1. Select the AD FS Identity Provider in the SAML 2.0 tab.

  2. Click Authentication Card > Authentication Request.

  3. Select Response Protocol Binding to POST.

  4. Select NAME Identifier Format as Transient.

  5. Click OK.

  6. Update the Identity Server.

Configuring AD FS 2.0

Using the Metadata to Add a Relying Party

The metadata import capability of AD FS 2.0 is used to create a relying party. The metadata includes the public key that is used to validate security tokens signed by Access Manager.

  1. In AD FS 2.0, right-click the Relying Party Trusts folder, then click Add Relying Party Trust to start the Add Relying Party Trust Wizard.

  2. Click Start.

  3. On the Select Data Source page, select Import data about the claims provider from a file.

  4. In the Federation metadata file location section, click Browse.

  5. Navigate to the location where you saved nam_metadata.xml earlier, select the file, then click Open > Next.

  6. On the Specify Display Name page, specify NAM Example.

  7. Click Next > Next > Close.

Editing Claim Rules for a Relying Party Trust

The data from AD FS is used in the security token that is sent to Access Manager.

  1. The Edit Claim Rules dialog box should already be open. If not, in the AD FS 2.0 center pane, under Relying Party Trusts, right-click NAM Example, then clickEdit Claim Rules.

  2. On the Issuance Transform Rules tab, click Add Rule.

  3. On the Select Rule Template page, leave the Send LDAP Attributes as Claims option selected, then click Next.

  4. On the Configure Claim Rule page, specify Get attributes in the Claim rule name field.

  5. Select Active Directory from the Attribute Store list.

  6. In the Mapping of LDAP attributes section, create the following mappings:

    LDAP Attribute

    Outgoing Claim Type

    User-Principal-Name

    UPN

    E-Mail-Address

    E-Mail Address

  7. Click OK.

  8. Click Apply > OK.

  9. On the Issurance Transform Rules tab, click Add Rules.

  10. On the Select Rule Template page, select Transform an Incoming Claim, then click Next.

  11. On the Configure Claim Rule page, use the following values:

    Name

    Value

    Claim rule name

    Mapping To Transient Name Identifier

    Incoming Claim Type

    UPN

    Outgoing Claim Type

    Name ID

    Outgoing name ID format

    Transient Identifier

  12. Select Pass Through All Claims, then click OK.

  13. Click Apply > OK.

Changing the AD FS 2.0 Signature Algorithm

By default, Access Manager uses the Secure Hash Algorithm 1 (SHA-1) for signing operations. By default, AD FS 2.0 expects partners to use SHA-256.

Perform the following steps to setup AD FS 2.0 to expect SHA-1 for interoperability with the Access Manager Identity Provider:

  1. In AD FS 2.0, click Claims Provider Trusts > right-click Ping Example > Properties.

  2. On the Advanced tab, select SHA-1 in the Secure Hash Algorithm list.

  3. Click OK.

Disabling the Certificate Revocation List

For more information about signing and encryption certificates, see Using Certificates and Certificate Revocation Lists.

Disabling the CRL Checking Option in the Linux Identity Provider

In Access Manager 3.1 SP4 or 3.1 SP5, modify the /opt/novell/nam/idp/conf/tomcat7.conf file and add JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"

In Access Manager 3.2.x or 4.0, modify /opt/novell/nam/idp/conf/tomcat7.conf and add JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"

Disabling the CRL Checking Option in AD FS 2.0

  1. Click Start > Administrative Tools > Windows PowerShell Modules.

  2. Enter the following command at the PowerShell command prompt:

    set-ADFSRelyingPartyTrust -TargetName "NAM Example"

    -SigningCertificateRevocationCheck None

AD FS 2.0 Encryption Strength

In AD FS 2.0, encryption of the outbound assertions is enabled by default. Assertion encryption occurs for any relying party or service provider for which AD FS 2.0 possesses an encryption certificate. AD FS 2.0 uses 256-bit Advanced Encryption Standard (AES) keys or AES-256 for encryption. In contrast, Failing to reconcile these conflicting defaults can result in the failed SSO attempts. To resolve this issue, disable the encryption in AD FS 2.0.

  1. In AD FS 2.0, click Start > Administrative Tools > Windows PowerShell Modules.

  2. Enter the following command in at the PowerShell command prompt:

    set-ADFSRelyingPartyTrust -TargetName "NAM Example"

    -EncryptClaims $False

AD FS 2.0 Basics

Configuring the Token-Decrypting Certificate

  1. Open the AD FS 2.0 Management tool, then click Start > Administrative Tools > AD FS 2.0 Management.

  2. In the left pane, expand the Service folder and click Certificates.

  3. In the Certificates section, select Add Token-Decrypting Certificate.

  4. (Conditional) If you see an error prompting you to run certain commands during the token-decrypting process, run the following PowerShell commands:

    Add-PSSnapin Microsoft.Adfs.PowerShell

    Set-ADFSProperties -AutoCertificateRollover $false

    These commands allow you to select other certificates. The certificate must be installed on the server. The certificates are configured on the IIS Manager.

  5. Click Start > Administrative Tools > Internet Information Services (IIS) Manager.

  6. Click ServerName.

  7. Click Server Certificates in the IIS section.

Adding CA Certificates to AD FS 2.0

  1. In Windows, Start > Run > mmc.

  2. Attach snapshot certificates as service.

  3. Select AD FS.

  4. Import the CA certificate to trusted authorities.

Debugging AD FS 2.0

  1. In the Event Viewer, click Applications > AD FS. You can access the troubleshooting help at Troubleshooting certificate problems with AD FS 2.0.

Power Shell Commands Help:

5.2.5 Configuring SAML 1.1

This section explains how to use the SAML 1.1 protocol to set up the trust with internal and external identity providers, service providers, and Embedded Service Providers (ESPs). Topics include:

Configuring a SAML 1.1 Profile

You can configure the methods of communication that are available at the server for requests and responses sent between providers. These settings affect the metadata for the server and should be determined prior to publishing to other sites.

Profiles control what methods of communication are available at the server for the SAML 1.1 protocol. These settings affect the metadata for the server and should be determined prior to publishing to other sites. If you have set up trusted providers, and then modify these profiles, the trusted providers need to reimport the metadata from this Identity Server.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 1.1 > Profiles.

  2. Configure the following fields:

    Login: Specifies the communication channel when the user logs in. Select one or more of these methods for the identity provider and the identity consumer:

    • The Artifact binding provides an increased level of security by using the back channel for communication between the two servers during authentication.

    • The Post method uses HTTP redirection to accomplish communication between servers.

      The Post method is enabled by default and you are not able to modify the default settings.The Post profile creates a metadata that includes only a Post binding on the Service Provider. If you have the default setup, then always both Artifact and Post options are enabled. If both the options are enabled, then by default Artifact binding is used. If Artifcact binding is disabled or removed, only Post method is used.

    Source ID: Displays the hexadecimal ID generated by the Identity Server for the SAML 1.1 service provider. This is a required value when establishing trust with a service provider.

  3. Click OK, then update the Identity Server.

  4. (Conditional) If you have set up trusted providers and have modified the profile, these providers need to reimport the metadata from this Identity Server.

Creating a Trusted Service Provider for SAML 1.1

Before you can create a trusted service provider, you must complete the following tasks:

  • Imported the trusted root of the provider’s SSL certificate into the NIDP trust store. For instructions, see Section 8.4.4, Managing the Keys, Certificates, and Trust Stores.

  • Shared the trusted root of the SSL certificate of your Identity Server with the service provider so that the administrator can imported it into the service provider’s trust store.

  • Obtained the metadata URL from the service provider, an XML file with the metadata, or the information required for manual entry. For more information about the manual entry option, see Editing a SAML 1.1 Service Provider’s Metadata.

  • Shared the metadata URL of your Identity Server with the service provider or an XML file with the metadata.

  • Enabled the protocol. Click Devices > Identity Servers > Edit, and on the Configuration page, verify that the required protocol in the Enabled Protocols section has been enabled.

To create a service provider:

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 1.1.

  2. Click New, then click Service Provider.

  3. In the Name option, specify a name by which you want to refer to the provider.

  4. Select one of the following sources for the metadata:

    Metadata URL: Specify the metadata URL for a trusted provider. The system retrieves protocol metadata using the specified URL. Examples of metadata URLs for an Identity Server acting as a service provider with an IP address of 10.1.1.1:

    http://10.1.1.1:8080/nidp/saml/metadata
https://10.1.1.1:8443/nidp/saml/metadata

    The default values nidp and 8080 are established during product installation; nidp is the Tomcat application name. If you have set up SSL, you can use https and port 8443.

    If your Identity Server and Administration Console are on different machines, use HTTP to import the metadata. If you are required to use HTTPS with this configuration, you must import the trusted root certificate of the provider into the trust store of the Administration Console. You need to use the Java keytool to import the certificate into the cacerts file in the security directory of the Administration Console.

    Linux: /opt/novell/java/jre/lib/security

    Windows Server 2008: \Program Files (x86)\Novell\jre\lib\security

    If you do not want to use HTTP and you do not want to import a certificate into the Administration Console, you can use the Metadata Text option. In a browser, enter the HTTP URL of the metadata. View the text from the source page, save the source metadata, then paste it into the Metadata Text option.

    Metadata Text: Paste the copied metadata text from an XML document, assuming you obtained the metadata via e-mail or disk and are not using a URL. If you copy metadata text from a Web browser, you must copy the text from the page source.

    Manual Entry: Allows you to enter metadata values manually. When you select this option, the system displays the Enter Metadata Values page. See Editing a SAML 1.1 Service Provider’s Metadata.

    Metadata Repositories: Allows you to configure several identity and/or service providers using a multi-entity metadata file available in a central repository. For more information about creating Identity and/or Service Providers see, Creating Identity Providers and Service Providers.

  5. Click Next.

  6. Review the metadata certificates, then click Finish.

  7. Click OK, then update the Identity Server.

    The wizard allows you to configure the required options and relies upon the default settings for the other options. For information about how to configure the default settings and how to configure the other available options, see Section 3.9.4, Modifying a Trusted Provider.

Configuring Communication Security for SAML 1.1

Liberty and SAML 1.1 have the same security options for the SOAP back channel for both identity and service providers. See Configuring Communication Security for Liberty

Editing a SAML 1.1 Identity Provider’s Metadata

Access Manager allows you to import metadata for SAML 1.1 providers. However, metadata for SAML 1.1 might not be available for some trusted providers, so you can enter metadata manually. The page for this is available if you clicked the Manual Entry option when you created the trusted provider.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 1.1 > [Identity Provider] > Metadata.

    You can reimport the metadata (see Step 2) or edit it (see Step 4).

  2. To reimport the metadata from a URL or text, click Reimport on the View page.

    The system displays the Create Trusted Identity Provider Wizard that lets you obtain the metadata. Follow the on-screen instructions to complete the steps in the wizard.

  3. Select either Metadata URL or Metadata Text, then fill in the field for the metadata.

  4. To edit the metadata manually, click Edit.

  5. Fill in the following fields as necessary:

    Supported Version: Specifies the version of SAML that you want to use. You can select SAML 1.0, SAML 1.1, or both SAML 1.0 and SAML 1.1.

    Provider ID: (Required) The SAML 1.1 metadata unique identifier for the provider. For example, https://<dns>:8443/nidp/saml/metadata. Replace <dns> with the DNS name of the provider.

    In the metadata, this is the entityID value.

    Source ID: The SAML Source ID for the trusted provider. The Source ID is a 20-byte value that is used as part of the Browser/Artifact profile. It allows the receiving site to determine the source of received SAML artifacts. If none is specified, the Source ID is auto-generated by using a SHA-1 hash of the site provider ID.

    Metadata expiration: The date upon which the metadata is no longer valid.

    SAML attribute query URL: The URL location where an attribute query is to be sent to the partner. The attribute query requests a set of attributes associated with a specific object. A successful response contains assertions that contain attribute statements about the subject. A SAML 1.1 provider might use the base URL, followed by /saml/soap. For example, https://<dns>:8443/nidp/saml/soap. Replace <dns> with the DNS name of the provider.

    In the metadata, this URL value is found in the AttributeService section of the metadata.

    Artifact resolution URL: The URL location where artifact resolution queries are sent. A SAML artifact is included in the URL query string. The target URL on the destination site the user wants to access is also included on the query string. A SAML 1.1 provider might use the base URL, followed by /saml/soap. For example, https://<dns>:8443/nidp/saml/soap. Replace <dns> with the DNS name of the provider.

    In the metadata, this URL value is found in the ArtifactResolutionService section of the metadata.

  6. To specify signing certificate settings, fill in the followi

    ng fields:

    Attribute authority: Specifies the signing certificate of the partner SAML 1.1 attribute authority. The attribute authority relies on the identity provider to provide it with authentication information so that it can retrieve attributes for the appropriate entity or user. The attribute authority must know that the entity requesting the attribute has been authenticated to the system.

    Identity provider: (Required) Appears if you are editing identity provider metadata. This field specifies the signing certificate of the partner SAML 1.1 identity provider. It is the certificate the partner uses to sign authentication assertions.

  7. Click OK.

  8. On the Identity Servers page, click Update All to update the configuration.

Editing a SAML 1.1 Service Provider’s Metadata

Access Manager allows you to obtain metadata for SAML 1.1 providers. However, metadata for SAML 1.1 might not be available for some trusted providers, so you can enter the metadata manually. The page for this is available if you clicked the Manual Entry option when you created the trusted provider.

For conceptual information about how Access Manager uses SAML, see Understanding How Access Manager Uses SAML.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 1.1 > [Service Provider] > Metadata.

    You can reimport the metadata (see Step 2) or edit it (see Step 3).

  2. To reimport the metadata, click Reimport on the View page.

    Follow the on-screen instructions to complete the steps in the wizard.

  3. To edit the metadata manually, click Edit.

  4. Fill in the following fields:

    Supported Version: Specifies which version of SAML that you want to use. You can select SAML 1.0, SAML 1.1, or both SAML 1.0 and SAML 1.1.

    Provider ID: (Required) Specifies the SAML 1.1 metadata unique identifier for the provider. For example, https://<dns>:8443/nidp/saml/metadata. Replace <dns> with the DNS name of the provider.

    In the metadata, this is the entityID value.

    Metadata expiration: Specifies the date upon which the metadata is no longer valid.

    Want assertion to be signed: Specifies that authentication assertions from the trusted provider must be signed.

    Artifact consumer URL: Specifies where the partner receives incoming SAML artifacts. For example, https://<dns>:8443/nidp/saml/spassertion_consumer. Replace <dns> with the DNS name of the provider.

    In the metadata, this URL value is found in the AssertionConsumerService section of the metadata.

    Post consumer URL: Specifies where the partner receives incoming SAML POST data. For example, https://<dns>:8443/nidp/saml/spassertion_consumer. Replace <dns> with the DNS name of the provider.

    In the metadata, this URL value is found in the AssertionConsumerService section of the metadata.

    Service Provider: Specifies the public key certificate used to sign SAML data. You can browse to locate the service provider certificate.

  5. Click Finish.

Configuring the SAML 1.1 Authentication Response

You can specify the name identifier and its format when the Identity Server sends an authentication response. You can also restrict the use of the assertion.

When an identity provider sends an assertion, the assertion can be restricted to an intended audience. The intended audience is defined to be any abstract URI in SAML 1.1. The URL reference can also identify a document that describes the terms and conditions of audience membership.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 1.1 > [Service Provider] > Authentication Response.

  2. To specify a name identifier format, select one of the following:

    • E-mail: Specifies that an e-mail attribute can be used as the identifier.

    • X509: Specifies that an X.509 certificate can be used as the identifier.

    • Unspecified: Specifies that an unspecified format can be used and any value can be used. The service provider and the identity provider need to agree on what value is placed in this identifier.

  3. To specify the format of the name identifier, select an attribute.

    The available attributes depend upon the attributes that you have selected to send with authentication (see the Attributes page for the service provider).

  4. To configure an audience, click New.

  5. Specify the SAML Audience URL value.

    The Provider ID, which can be used for the audience, is displayed on the Edit page for the metadata.

  6. You can manually set the assertion validity time for the SAML service provider in the Assertion Validity field to accommodate clock skew between the service provider and SAML Identity Server (IDP).

  7. Click OK twice, then update the Identity Server.

Defining Options for SAML 1.1 Service Provider

For more information about Options, see Defining Options for SAML 2.0 Service Provider

  1. In Administration Console, click Devices > Identity Servers > Servers > Edit > SAML 1.1 > Service Provider > Options.

  2. Select the required step up authentication contracts from the Available Contracts list and move them to the Selected Contracts list. These selected contracts will be used to provide the step up authentication for the service provider.

  3. Click OK.

Modifying the Authentication Card for SAML 1.1

When you create an identity provider, you must also configure an authentication card. After it is created, you can modify it.

  1. In the Administration Console, click Devices > Identity Servers > Edit > SAML 1.1 > [Identity Provider] > Authentication Card.

  2. Modify the values in one or more of the following fields:

    ID: If you have need to reference this card outside of the user interface, specify an alphanumeric value here. If you do not assign a value, the Identity Server creates one for its internal use. The internal value is not persistent. Whenever the Identity Server is rebooted, it can change. A specified value is persistent.

    Text: Specify the text that is displayed on the card to the user. This value, in combination with the image, should identify to the users, which provider they are logging into.

    Login URL: Specify an Intersite Transfer Service URL.The URL has the following format, where idp.sitea.novell.com is the DNS name of the identity provider, idp.siteb.novell.com is the name of the service provider, and idp.siteb.novell.com:8443/nidp/app specifies the URL that you want to users to access after a successful login.

    NOTE:The PID in the login URL must exactly match the entity ID specified in the metadata. 

    https://idp.sitea.novell.com:8443/nidp/saml/idpsend?PID=https://idp.siteb.novell.com:8443/nidp/saml/metadata&TARGET=https://idp.siteb.novell.com:8443/nidp/app

    For more information, see Specifying the Intersite Transfer Service URL for the Login URL Option.

    If your identity provider is a NetIQ Identity Server and you know the ID specified for the target, you can use the following simplified format for the Login URL:

    <URL for site a>?id=<ID of target>

    https://idp.sitea.novell.com:8443/nidp/saml/idpsend?id=206test

    The target and the target ID are specified in the service provider configuration at the identity provider. See Configuring an Intersite Transfer Service Target for a Service Provider.

    Image: Specify the image to be displayed on the card. Select the image from the drop-down list. To add an image to the list, click <Select local image>.

    Show Card: Determine whether the card is shown to the user, which allows the user to select and use the card for authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.

  3. Click OK twice, then update the Identity Server.

5.2.6 Configuring Liberty

This section explains how to use the Liberty protocol to set up the trust with internal and external identity providers, service providers, and Embedded Service Providers (ESPs). Topics include:

About Liberty

The Liberty Alliance is a consortium of business leaders with a vision to enable a networked world in which individuals and businesses can more easily conduct transactions while protecting the privacy and security of vital identity information.

To accomplish its vision, the Liberty Alliance established an open standard for federated network identity through open technical specifications. In essence, this open standard is a structured version of the Security Assertions Markup Language, commonly referred to as SAML, with the goal of accelerating the deployment of standards-based single sign-on technology.

For general information about the Liberty Alliance, visit the Liberty Alliance Project Web site.

Liberty resources, including specifications, white papers, FAQs, and presentations, can be found at the Liberty Alliance Resources Web site.

The following table provides links to specific Liberty Alliance specifications:

Table 5-14 Liberty Alliance Links

Liberty Specification

Location

Liberty Alliance Project Overview

Liberty Alliance Project Overview

Liberty White Papers

Papers

Identity Federation Specifications

Liberty ID-FF 1.2 Specification

Web Service Framework Specifications

Liberty ID-WSF 1.1 Specifications

Liberty Profile Service Specifications

Liberty Alliance ID-SIS 1.0 Specifications

OASIS Standards (SAML)

Oasis Standards

Configuring a Liberty Profile

You can configure the methods of communication that are available at the server for requests and responses sent between providers. These settings affect the metadata for the server and should be determined prior to publishing to other sites.

The profile specifies what methods of communication are available at the server for the Liberty protocol. These settings affect the metadata for the server and should be determined prior to publishing to other sites. If you have set up trusted providers, and then modify these profiles, the trusted providers need to reimport the metadata from this Identity Server.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Profiles.

  2. Configure the following fields for identity providers and service providers:

    Login: Specifies whether to support Artifact or Post binding for login. Select one or more of the following for the identity provider and the service provider:

    • The Artifact binding provides an increased level of security by using a back channel means of communication between the two servers during authentication.

    • The Post method uses HTTP redirection to accomplish communication between the servers.

    Single Logout: Specifies the communication method to use when the user logs out. Typically, you select both of these options, which enables the identity provider or service provider to accept both HTTP and SOAP requests. SOAP is used if both options are selected, or if the service provider has not specified a preference.

    • HTTP: Uses HTTP 302 redirects or HTTP GET requests to communicate logout requests from this identity site to the service provider.

    • SOAP: Uses SOAP over HTTP messaging to communicate logout requests from this identity provider to the service provider.

    Federation Termination: Specifies the communication channel to use when the user selects to defederate an account. Typically, you select both of these options, which enables the identity provider or service provider to accept both HTTP and SOAP requests. SOAP is the default setting if the service provider has not specified a preference.

    • HTTP: Uses HTTP 302 redirects to communicate federation termination requests from this server.

    • SOAP: Uses SOAP back channel over HTTP messaging to communicate logout requests from this server

    Register Name: Specifies the communication channel to use when the provider supplies a different name to register for the user. Typically, you select both of these options, which enables the identity provider or service provider to accept both HTTP and SOAP requests. SOAP is the default setting if the service provider has not specified a preference.

    • HTTP: Uses HTTP 302 redirects to communicate federation termination requests from this server.

    • SOAP: Uses SOAP back channel over HTTP messaging to communicate logout requests from this server.

  3. Click OK, then update the Identity Server.

  4. (Conditional) If you have set up trusted providers and have modified the profile, these providers need to reimport the metadata from this Identity Server.

Creating a Trusted Service Provider for Liberty

Before you can create a trusted service provider, you must complete the following tasks:

  • Imported the trusted root of the provider’s SSL certificate into the NIDP trust store. For instructions, see Section 8.4.4, Managing the Keys, Certificates, and Trust Stores.

  • Shared the trusted root of the SSL certificate of your Identity Server with the service provider so that the administrator can imported it into the service provider’s trust store.

  • Obtained the metadata URL from the service provider, an XML file with the metadata, or the information required for manual entry. For more information about the manual entry option, see Editing a SAML 1.1 Service Provider’s Metadata.

  • Shared the metadata URL of your Identity Server with the service provider or an XML file with the metadata.

  • Enabled the protocol. Click Devices > Identity Servers > Edit, and on the Configuration page, verify that the required protocol in the Enabled Protocols section has been enabled.

To create a service provider:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty.

  2. Click New, then click Service Provider.

  3. In the Name option, specify a name by which you want to refer to the provider.

  4. Select one of the following sources for the metadata:

    Metadata URL: Specify the metadata URL for a trusted provider. The system retrieves protocol metadata using the specified URL. Examples of metadata URLs for an Identity Server acting as a service provider with an IP address of 10.1.1.1:

    http://10.1.1.1:8080/nidp/saml/metadata
https://10.1.1.1:8443/nidp/saml/metadata

    The default values nidp and 8080 are established during product installation; nidp is the Tomcat application name. If you have set up SSL, you can use https and port 8443.

    If your Identity Server and Administration Console are on different machines, use HTTP to import the metadata. If you are required to use HTTPS with this configuration, you must import the trusted root certificate of the provider into the trust store of the Administration Console. You need to use the Java keytool to import the certificate into the cacerts file in the security directory of the Administration Console.

    Linux: /opt/novell/java/jre/lib/security

    Windows Server 2008: \Program Files (x86)\Novell\jre\lib\security

    If you do not want to use HTTP and you do not want to import a certificate into the Administration Console, you can use the Metadata Text option. In a browser, enter the HTTP URL of the metadata. View the text from the source page, save the source metadata, then paste it into the Metadata Text option.

    Metadata Text: Paste the copied metadata text from an XML document, assuming you obtained the metadata via e-mail or disk and are not using a URL. If you copy metadata text from a Web browser, you must copy the text from the page source.

    Manual Entry: Allows you to enter metadata values manually. When you select this option, the system displays the Enter Metadata Values page. See Editing a SAML 1.1 Service Provider’s Metadata.

    Metadata Repositories: Allows you to configure several identity and/or service providers using a multi-entity metadata file available in a central repository. For more information about creating Identity and/or Service Providers see, Creating Identity Providers and Service Providers.

  5. Click Next.

  6. Review the metadata certificates, then click Finish.

  7. Click OK, then update the Identity Server.

    The wizard allows you to configure the required options and relies upon the default settings for the other options. For information about how to configure the default settings and how to configure the other available options, see Section 3.9.4, Modifying a Trusted Provider.

Configuring Communication Security for Liberty

Liberty and SAML 1.1 have the same security options for the SOAP back channel for both identity and service providers. You cannot configure the trust relationship of the SOAP back channel for the Identity Server and its Embedded Service Providers.

  1. In the Administration Console, click Devices > Identity Servers > Edit > [Protocol].

    For the protocol, select either Liberty or SAML 1.1.

  2. Click the name of a provider.

  3. On the Trust page, fill in the following field:

    Name: Specify the display name for this trusted provider. The default name is the name you entered when creating the trusted provider.

    For an Embedded Service Provider, the Name option is the only available option on the Trust page.

    The Security section specifies how to validate messages received from trusted providers over the SOAP back channel. Both the identity provider and the service provider in the trusted relationship must be configured to use the same security method.

  4. Select one of the following security methods:

    Message Signing: Relies upon message signing using a digital signature.

    Mutual SSL: Specifies that this trusted provider provides a digital certificate (mutual SSL) when it sends a SOAP message.

    SSL communication requires only the client to trust the server. For mutual SSL, the server must also trust the client. For the client to trust the server, the server’s certificate authority (CA) certificate must be imported into the client trust store. For the server to trust the client, the client’s CA certificate must be imported into the server trust store.

    Basic Authentication: Specifies standard header-based authentication. This method assumes that a name and password for authentication are sent and received over the SOAP back channel.

    • Send: The name and password to be sent for authentication to the trusted partner. The partner expects this password for all SOAP back-channel requests, which means that the name and password must be agreed upon.

    • Verify: The name and password used to verify data that the trusted provider sends.

  5. Click OK twice.

  6. Update the Identity Server.

Configuring a Liberty Authentication Request

You can configure how the Identity Server creates an authentication request for a trusted identity provider. When users authenticate, they can be given the option to federate their account identities with the preferred identity provider. This process creates an account association between the identity provider and service provider that enables single sign-on and single log-out.

The authentication request specifies how you want the identity provider to handle the authentication process so that it meets the security needs of the Identity Server.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > [Identity Provider] > Authentication Card > Authentication Request.

  2. Configure the federation options:

    Allow Federation: Determines whether federation is allowed. The federation options that control when and how federation occurs can only be configured if the identity provider has been configured to allow federation.

    • After authentication: Specifies that the federation request can be sent after the user has authenticated (logged in) to the service provider. When you set only this option, users must log in locally, then they can federate by using the Federate option on the card in the Login page of the Access Manager User Portal. Because the user is required to authenticate locally, you do not need to set up user identification.

    • During authentication: Specifies whether federation can occur when the user selects the authentication card of the identity provider. Typically, a user is not authenticated at the service provider when this selection is made. When the identity provider sends a response to the service provider, the user needs to be identified on the service provider to complete the federation. If you enable this option, ensure that you configure a user identification method. See Selecting a User Identification Method for Liberty or SAML 2.0.

  3. Select one of the following options for the Requested By option:

    Do not specify: Specifies that the identity provider can send any type of authentication to satisfy a service provider’s request, and instructs a service provider to not send a request for a specific authentication type or contract.

    Use Types: Specifies that authentication types should be used.

    Select the types from the Available types field to specify which type to use for authentication between trusted service providers and identity providers. Standard types include Name/Password, Secure Name/Password, X509, Token, and so on.

    Use Contracts: Specifies that authentication contracts should be used.

    Select the contract from the Available contracts list. For a contract to appear in the Available contracts list, the contract must have the Satisfiable by External Provider option enabled. To use the contract for federated authentication, the contract’s URI must be the same on the identity provider and the service provider. For information about contract options, see Section 5.1.4, Configuring Authentication Contracts.

    Most third-party identity providers do not use contracts.

  4. Configure the options:

    Response protocol binding: Select Artifact or Post or None. Artifact and Post are the two methods for transmitting assertions between the authenticating system and the target system.

    If you select None, you are letting the identity provider determine the binding.

    Identity Provider proxy redirects: Specifies whether the trusted identity provider can proxy the authentication request to another identity provider. A value of None specifies that the trusted identity provider cannot redirect an authentication request. Values 1-5 determine the number of times the request can be proxied. Select Configured on IDP to let the trusted identity provider decide how many times the request can be proxied.

    Force authentication at Identity Provider: Specifies that the trusted identity provider must prompt users for authentication, even if they are already logged in.

    Use automatic introduction: Attempts single sign-on to this trusted identity provider by automatically sending a passive authentication request to the identity provider. (A passive requests does not prompt for credentials.) The identity provider sends one of the following authentication responses:

    • When the federated user is authenticated at the identity provider: The identity provider returns an authentication response indicating that the user is authenticated. The user gains access to the service provider without entering credentials (single sign-on).

    • When the federated user is not authenticated at the identity provider: The identity provider returns an authentication response indicating that the user is not logged in. The user can then select a card for authentication, including the card for the identity provider. If the user selects the identity provider card, an authentication request is sent to the identity provider. If the credentials are valid, the user is also authenticated to the service provider.

    IMPORTANT:Enable the Use automatic introduction option only when you are confident the identity provider will be up. If the server is down and does not respond to the authentication request, the user gets a page-cannot-be-displayed error. Local authentication is disabled because the browser is never redirected to the login page.

    This option should be enabled only when you know the identity provider is available 99.999% of the time or when the service provider is dependent upon this identity provider for authentication.

  5. Click OK twice, then update the Identity Server.

Configuring the Liberty Authentication Response

After you create a trusted service provider, you can configure how your Identity Server responds to authentication requests from the service provider.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > [Service Provider] > Authentication Response.

  2. Select the binding method.

    If the request from the service provider does not specify a response binding, you need to specify a binding method to use in the response. Select Artifact to provide an increased level of security by using a back-channel means of communication between the two servers. Select Post to use HTTP redirection for the communication channel between the two servers. If you select Post, you might want to require the signing of the authentication requests. See Configuring the General Identity Provider Options.

  3. Specify the identity formats that the Identity Server can send in its response. Select the Use box to choose one or more of the following:

    • Persistent Identifier Format: Specifies a persistent identifier that federates the user profile on the identity provider with the user profile on the service provider. It remains intact between sessions.

    • Transient Identifier Format: Specifies that a transient identifier, which expires between sessions, can be sent.

    If the request from the service provider requests a format that is not enabled, the user cannot authenticate.

  4. Use the Default button to specify whether a persistent or transient identifier is sent when the request from the service provider does not specify a format.

  5. To specify that this Identity Server must authenticate the user, disable the Use proxied requests option. When the option is disabled and the Identity Server cannot authenticate the user, the user is denied access.

    When this option is enabled, the Identity Server checks to see if other identity providers can satisfy the request. If one or more can, the user is allowed to select which identity provider performs the authentication. If a proxied identity provider performs the authentication, it sends the response to the Identity Server. The Identity Server then sends the response to the service provider.

  6. Enable the Provide Discovery Services option if you want to allow the service provider to query the Identity Server for a list of its Web Services. For example, when the option is enabled, the service provider can determine whether the Web Services Framework is enabled and which Web Service Provider profiles are enabled.

  7. Click OK twice, then update the Identity Server.

Defining Options for Liberty Service Provider

NetIQ Access Manager can be used as an identity provider for several service providers.You can configure a specific authentication contract that is required for a Service provider. If more than one authentication contract is configured for a service provider, the contract having minimum level will be selected.

When providing authentication to a service provider, the identity server ensures that the user is authenticated by the required contract. When a user is not authenticated or when user is authenticated, but the authenticated contracts do not satisfy the required contracts, user will be prompted to authenticate with required contract. This is called step up authentication.

If no required contract is configured, then the default contract is executed.

NOTE:This step up authentication is supported only for Intersite Transfer Service (identity provider initiated) requests on Liberty and works for both identity and service provider initiated requests for SAML 2.0.

To Define Options for Liberty Service Provider

  1. In the Administration Console, click Devices > Identity Servers > Servers > Edit > Liberty > Service Provider > Options.

  2. Select the required step up authentication contracts from the Available contracts list and move them to the Selected contracts list. This is to provide the step up authentication for the service provider.

  3. Click OK.

Defining Options for Liberty Identity Provider

  1. In Administration Console, click Devices > Identity Servers > Servers > Edit > Liberty or SAML 2.0 > Identity Provider > Options.

  2. Enable Front Channel Logout: After this option is enabled, Service Provider initiates a logout at the Identity Provider by using the HTTP Redirect method.

  3. Configure Front Channel Logout for Access Gateway Initiated Logout: In addition to enabling the front channel logout, add the following parameters at the NESP web.xml and restart tomcat:

    Add the following parameters in the web.xml below the ldapLoadThreshold context param:

    <context-param> <param-name>forceESPSLOHTTP</param-name> <param-value>true</param-value> </context-param>

    To restart tomcat:

    Linux: Enter the following command:/etc/init.d/novell-idp restart

    Windows: Enter the following commands:net stop Tomcat7net start Tomcat7

Configuring the Session Timeout

See Configuring the Liberty or SAML 2.0 Session Timeout.

Modifying the Authentication Card

See Modifying the Authentication Card for Liberty or SAML 2.0.

5.2.7 Configuring Liberty Web Services

A Web service uses Internet protocols to provide a service. It is an XML-based protocol transported over SOAP, or a service whose instances and data objects are addressable via URIs.

Access Manager consists of several elements that comprise Web services:

  • Web Service Framework: Manages all Web services. The framework defines SOAP header blocks and processing rules that enable identity services to be invoked via SOAP requests and responses.

  • Web Service Provider: An entity that provides data via a Web service. In Access Manager, Web service providers host Web service profiles, such as the Employee Profile, Credential Profile, Personal Profile, and so on.

  • Web Service Consumer: An entity that uses a Web service to access data. Web service consumers discover resources at the Web service provider, and then retrieve or update information about a user, or on behalf of a user. Resource discovery among trusted partners is necessary because a user might have many kinds of identities (employee, spouse, parent, member of a group), as well as several identity providers (employers or other commercial Web sites).

  • Discovery Service: The service assigned to an identity provider that enables a Web Service Consumer to determine which Web service provider provides the required resource.

  • LDAP Attribute Mapping: Access Manager’s solution for mapping Liberty attributes with established LDAP attributes.

This section describes the following topics:

For additional resources about the Liberty Alliance specifications, visit the Liberty Alliance Specification page.

Web Services Framework

The Web Services Framework page lets you edit and manage all the details that pertain to all Web services. This includes the framework for building interoperable identity services, permission-based attribute sharing, identity service description and discovery, and the associated security mechanisms.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Framework.

  2. Fill in the following fields:

    Enable Framework: Enables Web Services Framework.

    Axis SOAP Engine Settings: Axis is the SOAP engine that handles all Web service requests and responses. Web services are deployed using XML-based files known as Web service deployment descriptors (WSDD). On startup, Access Manager automatically creates the server-side and client-side configuration for Axis to handle all enabled Web services.

    If you need to override this default configuration, use the Axis Server Configuration WSDD XML field and the Axis Client Configuration WSDD XML field to enter valid WSDD XML. If either or both of these controls contain valid XML, then Access Manager does not automatically create the configuration (server or client) on startup.

  3. Click OK.

Managing Web Services and Profiles

After a service has been discovered and data has been received from a trusted identity provider, the Web service consumer can invoke the service at the Web service provider. A Web service provider is the hosting or relying entity on the server side that can make access control decisions based on this data and upon its business practices and preferences.

  1. In the Administration Console click Identity Servers > Edit > Liberty > Web Service Provider.

  2. Select one of the following actions

    New: To create a new Web service, click New. This activates the Create Web Service Wizard. You can create a new profile only if you have deleted one.

    Delete: To delete an existing profile, select the profile, then click Delete.

    Enable: To enable a profile, select the profile, then click Enable.

    Disable: To disable a profile, select the profile, then click Disable.

    Edit a Policy: To edit the policy associated with a profile, click the Policy link. For configuration information, see Editing Web Service Policies.

    Edit a profile: To edit a profile, click the name of a profile. For information about configuring the details, see Modifying Service and Profile Details for Employee, Custom, and Personal Profiles and Modifying Details for Authentication, Discovery, LDAP, and User Interaction Profiles.

    For information about modifying the description, see Editing Web Service Descriptions.

    The Identity Server comes with the following Web service profile types:

    Authentication Profile: Allows the system to access the roles and authentication contracts in use by current authentications. This profile is enabled by default so that Embedded Service Providers can evaluate roles in policies. This profile can be disabled. When it is disabled, all devices assigned to use this Identity Server cluster configuration cannot determine which roles a user has been assigned, and the devices evaluate policies as if the user has no roles.

    WARNING:Do not delete this profile. In normal circumstances, this profile is used only by the system.

    Credential Profile: Allows users to define information to keep secret. It uses encryption to store the data in the directory the user profile resides in.

    Custom Profile: Used to create custom attributes for general use.

    Discovery: Allows requesters to discover where the resources they need are located. Entities can place resource offerings in a discovery resource, allowing other entities to discover them. Resources might be a personal profile, a calendar, travel preferences, and so on.

    Employee Profile: Allows you to manage employment-related information and how the information is shared with others. A company address book that provides names, phones, office locations, and so on, is an example of an employee profile.

    LDAP Profile: Allows you to use LDAP attributes for and general use.

    Personal Profile: Allows you to manage personal information and to determine how to share that information with others. A shopping portal that manages the user’s account number is an example of a personal profile.

    User Interaction: Allows you to set up a trusted user interaction service, used for identity services that must interact with the resource owner to get information or permission to share data with another Web service consumer. This profile enables a Web service consumer and Web service provider to cooperate in redirecting the resource owner to the Web service provider and back to the Web service consumer.

  3. Click OK.

  4. On the Servers page, update the Identity Server.

Modifying Service and Profile Details for Employee, Custom, and Personal Profiles

The settings on the Details page are identical for the Employee, Custom, and Personal Profiles. This page allows you to specify the display name, resource ID encryption, and how the system reads and writes data.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Provider.

  2. Click Custom Profile, Employee Profile, or Personal Profile, depending on which profile you want to edit.

  3. Click the Details tab (it is displayed by default).

  4. Specify the general settings, as necessary:

    Display Name: The Web service name. This specifies how the profile is displayed in the Administration Console.

    Have Discovery Encrypt This Service’s Resource Ids: Specifies whether the Discovery Service encrypts resource IDs. A resource ID is an identifier used by Web services to identify a user. The Discovery Service returns a list of resource IDs when a trusted service provider queries for the services owned by a given user. The Discovery Service has the option of encrypting the resource ID or sending it unencrypted.

  5. Specify data location settings:

    Selected Read Locations: The list of selected locations from which the system reads attributes containing profile data. If you add multiple entries to this list, the system searches attributes in each location in the order you specify. When a match is found for an attribute, the other locations are not searched. Use the up/down and left/right arrows to control which locations are selected and the order in which to read them. Read locations can include:

    • Configuration Datastore: Liberty attribute values can be stored in the configuration store of the Administration Console. If your users have access to the User Portal, they can add values to a number of Liberty attributes.

    • LDAP Data Mappings: If you have mapped a Liberty attribute to an LDAP attribute in your user store, the values can be read from the LDAP user store. To create LDAP attribute maps, see Mapping LDAP and Liberty Attributes.

    • Remote Attributes: If you set up federation, the Identity Server can read attributes from these remote service providers. Sometimes, the service provider is set up to push a set of attribute values when the user logs in. These pushed attributes are cached, and the Identity Server can quickly read them. If a requested attribute has not been pushed, a request for the Liberty attribute is sent to remote service provider. This can be time consuming, especially if the user has federated with more than one remote service provider. Remote Attributes should always be the last item in this list.

    Available Read Locations: The list of available locations from which the system can read attributes containing profile data. Locations in this list are currently not being used.

    Selected Write Locations: The list of selected locations to write attribute data to. If you add multiple entries to this list, the system searches attributes in each location in the order you specify. When a match is found for an attribute, the other locations are not searched. Use the up/down and left/right arrows to control which locations are selected and the order in which they are selected.

    • Configuration Datastore: Liberty attribute values can be stored in the configuration store of the Administration Console. The Identity Server can write values to these attributes. If this location appears first in the list of Selected Write Locations, all Liberty attribute values are written to this location. If you want values written to the LDAP user store, the LDAP Data Mappings location must appear first in the list.

    • LDAP Data Mappings: If you have mapped a Liberty attribute to an LDAP attribute in your user store, the Identity Server can write values to the attribute in the LDAP user store. To create LDAP attribute maps, see Mapping LDAP and Liberty Attributes.

    Available Write Locations: The list of available locations to write attributes containing profile data. Locations in this list are currently not being used.

  6. (Optional) Specify data model extensions.

    Data Model Extension XML: The data model for some Web services is extensible. You can enter XML definitions of data model extensions in this field. Data model extensions hook into the existing Web service data model at predefined locations.

    All schema model extensions reside inside of a schema model extension group. The group exists to bind model data items together under a single localized group name and description. Schema model extension groups can reside inside of a schema model extension root or inside of a schema model extension. There can only be one group per root or extension. Each root is hooked into the existing Web service data model. Multiple roots can be hooked into the same location in the existing Web service data model. This conceptual model applies to the structure of the XML that is required to define data model extensions.

    See Section B.0, Data Model Extension XML for more information.

  7. Click OK, then click OK on the Web Service Provider page.

  8. Update the Identity Server.

Modifying Details for Authentication, Discovery, LDAP, and User Interaction Profiles

This page allows you to specify information for Discovery, LDAP, and User Interaction Web service profiles. If you are creating a Web service type, this is Step 2 of the Create Web Service Wizard.

For conceptual information about profiles, see Managing Web Services and Profiles.

  1. In the Administration Console, click Devices> Identity Servers > Edit > Liberty > Web Service Provider > [Profile].

  2. Click Authentication, Discovery, LDAP, or User Interaction, depending on which profile you want to edit.

  3. Configure the following fields:

    Display name: The Web service name. This specifies how the profile is displayed in the Administration Console.

    Have Discovery Encrypt This Service’s Resource Ids: (Not applicable for the Discovery profile) Specifies whether the Discovery Service encrypts resource IDs. A resource ID is an identifier used by Web services to identify a user. The Discovery Service returns a list of resource IDs when a trusted service provider queries for the services owned by a given user. The Discovery Service has the option of encrypting the resource ID or sending it unencrypted. This ID is encrypted with the public key of the resource provider generated at installation. Encrypting resource IDs is turned off by default.

  4. Click OK.

Editing Web Service Descriptions

All of the Description pages on each profile are identical. You can define how a service provider gains access to portions of the user’s identity information that can be distributed across multiple providers. The service provider uses the Discovery Service to ascertain the location of a specific identity service for a user. The Discovery Service enables various entities to dynamically and securely discover a user’s identity service, and it responds, on a permission basis, with a service description of the desired identity service.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Provider.

  2. Click the profile or service.

  3. Click Descriptions.

  4. Click the description name, or click New.

  5. Fill in the following fields:

    Name: The Web Service Description name.

    Security Mechanism: (Required) Liberty uses channel security (TLS 1.0) and message security in conjunction with the security mechanism. Channel security addresses how communication between identity providers, service providers, and user agents is protected. For authentication, service providers are required to authenticate identity providers by using identity provider server-side certificates. Identity providers have the option to require authentication of service providers by using service provider client-side certificates.

    Message security addresses security mechanisms applied to the discrete Liberty protocol messages passed between identity providers, service providers, and user agents.

    Select the mechanism for message security. Message authentication mechanisms indicate which profile is used to ensure the authenticity of a message.

    • X.509: Used for message exchanges that generally rely upon message authentication as the principle factor in making decisions.

    • SAML: Used for message exchanges that generally rely upon message authentication as well as the conveyance and attestation of information.

    • Bearer: Based on the presence of the security header of a message. In this case, the bearer token is verified for authenticity rather than proving the authenticity of the message.

  6. Under Select Service Access Method, select either Brief Service Access Method or WSDL Service Access Method.

    Brief Service Access Method: Provides the information necessary to invoke basic SOAP-over-HTTP-based service instances without using WSDL.

    • EndPoint URL: This is the SOAP endpoint location at the service provider to which Liberty SOAP messages are sent. An example of this for the Employee Profile is [BASEURL]/services/IDSISEmployeeProfile. If the service instance exposes an endpoint that is different from the logically generated concrete WSDL, you must use the WSDL URI instead.

      A WSF service description endpoint cannot contain double-byte characters.

    • SOAP Action: The SOAP action HTTP header required on HTTP-bound SOAP messages. This header can be used to indicate the intent of a SOAP message to the recipient.

    WSDL Service Access Method: Specify the method used to access the WSDL service. WSDL (Web Service Description Language) describes the interface of a Web service.

    • Service Name Reference: A reference name for the service.

    • WSDL URI: Provides a URI to an external concrete WSDL resource containing the service description. URIs need to be constant across all implementations of a service to enable interoperability.

  7. Click OK.

  8. Update the Identity Server configuration.

Editing Web Service Policies

Web Service policies are permission policies (query and modify) that govern how identity providers share end-user data with service providers. Administrators and policy owners (users) can control whether private information is always allowed to be given, never allowed, or must be requested.

As an administrator, you can configure this information for the policy owner, for specific service providers, or globally for all service providers. You can also specify what policies are displayed for the end user in the User Portal, and whether users are allowed to edit them.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Provider.

  2. Click the Policy link next to the service name.

  3. Click the category you want to edit.

    All Trusted Providers: Policies that are defined by the service provider’s ability to query and modify the particular Liberty attributes or groups of attributes for the Web service. When All Trusted Providers permissions are established, and a service provider needs data, the system first looks here to determine whether user data is allowed, never allowed, or must be asked for. If no solution is found in All Trusted Providers, the system examines the permissions established within the specific service provider.

    Owners: Policies that limit the end user’s ability to modify or query data from his or her own profile. The settings you specify in the Owner group are reflected on the My Profile page in the User Portal. Portal users have the authority to modify the data items in their profiles. The data items include Liberty and LDAP attributes for personal identity, employment, and any customized attributes defined in the Identity Server configuration. Any settings you specify in the Administration Console override what is displayed in the User Portal. Overrides are displayed in the Inherited column.

    If you want the user to have Write permission for a given data item, and that data item is used in an LDAP Attribute Map, then you must configure the LDAP Attribute Map with Write permission.

  4. On the All Service Policy page, select the policy’s check box, then click Edit Policy.

    This lets you modify the parent service policy attribute. Any selections you specify on this page are inherited by child policies.

    Query Policy: Allows the service provider to query for the data on a particular attribute. This is similar to read access to a particular piece of data.

    Modify Policy: Allows the service provider to modify a particular attribute. This is similar to write access to a particular piece of data.

    Query and Modify: Allows you to set both options at once.

  5. To edit child attributes of the parent, click the policy.

    In the following example, child attributes are inheriting Ask Me permission from the parent Entire Personal Identity attribute. The Postal Address attribute, however, is modified to never allow permission for sharing.

    If you click the Postal Address attribute, you can see that all of its child attributes have inherited the Never Allow setting. You can specify different permission attributes for Address Type (for example), but the inherited policy still overrides changes made at the child level, as shown below.

    The interface allows these changes to simplify switching between configurations if, for example, you want to remove an inherited policy.

    Inherited: Specifies the settings inherited from the parent attribute policy, when you view a child attribute. In the User Portal, settings displayed under Inherited are not modifiable by the user. At the top-level policy in the User Portal, the values are inherited from the settings in the Administration Console. Thereafter, inheritance can come from the service policy or the parent data item’s policy.

    Ask Me: Specifies that the service provider requests from the user what action to take.

    Always Allow: Specifies that the identity provider always allows the attribute data to be sent to the service provider.

    Never Allow: Specifies that the identity provider never allows the attribute data to be sent to the service provider.

    When a request for data is received, the Identity Server examines policies to determine what action to take. For example, if a service provider requires a postal address for the user, the Identity Server performs the following actions:

    • Checks the settings specified in All Service Providers.

    • If no solution is found, checks for the policy settings configured for the service provider.

  6. Click OK until the Web Service Provider page is displayed.

  7. Click OK, then update the Identity Server as prompted.

Create Web Service Type

This page allows you to create a Web service profile type. This is Step 1 of the Create Web Service Wizard. Access Manager comes with several Web service profiles, but if you have deleted a profile type, you can create it again.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Provider > New.

  2. Select the Web service type from the drop-down list, then click Next.

  3. Continue with one of the following:

Configuring Credential Profile Security and Display Settings

On the Credential Profile Details page, you can specify whether this profile is displayed for end users, and determine how you control and store encrypted secrets. You can store and access secrets locally, on remote eDirectory servers that are running Novell SecretStore, or on a user store that has been configured with a custom attribute for secrets.

For more information about storing encrypted secrets, see the following:

To configure the Credential Profile:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Providers.

  2. Click Credential Profile.

  3. On the Credential Profile Details page, fill in the following fields as necessary:

    Display name: The name you want to display for the Web service.

    Have Discovery Encrypt This Service’s Resource Ids: Specify whether the Discovery Service encrypts the resource IDs. A resource ID is an identifier used by Web services to identify a user. The Discovery Service returns a list of resource IDs when a trusted service provider queries for the services owned by a given user. The Discovery Service has the option of encrypting the resource ID or sending it unencrypted. Encrypting resource IDs is disabled by default.

  4. Under Credential Profile Settings, enable the following option if necessary:

    Allow End Users to See Credential Profile: Specify whether to display or hide the Credential Profile in the Access Manager User Portal. Profiles are viewed on the My Profile page, where the user can modify his or her profile.

  5. Specify how you want to control and store secrets:

    1. To locally control and store secrets, configure the following fields:

      Encryption Password Hash Key: (Required) Specify the password that you want to use as a seed to create the encryption algorithm. To increase the security of the secrets, ensure that you change the default password to a unique alphanumeric value.

      Preferred Encryption Method: Specify the preferred encryption method. Select the method that complies with your security model:

      • Password Based Encryption With MD5 and DES: MD5 is an algorithm that is used to verify data integrity. Data Encryption Standard (DES) is a widely used method of data encryption that uses a private key.

      • DES: Data Encryption Standard (DES) is a widely used method of data encryption that uses a private key. Like other private key cryptographic methods, both the sender and the receiver must know and use the same private key.

      • Triple DES: A variant of DES in which data is encrypted three times with standard DES by using two different keys.

    2. Specify where to store secret data. (For more information about setting up a user store for secret store, see Configuring a User Store for Secrets.)

      • To have the secrets stored in the configuration database, do not configure the list in the Extended Schema User Store References section. You only need to configure the fields in Step 5.a.

      • To store the secrets in your LDAP user store, click New in Extended Schema User Store References and configure the following fields:

        User Store: Select a user store where secret data is stored.

        Attribute Name: Specify the LDAP attribute of the User object that can be used to store the secrets. When a user authenticates by using the user store specified here, the secret data is stored in an XML document of the specified attribute of the user object. This attribute should be a single-valued case ignore string that you have defined and assigned to the user object in the schema.

        NOTE:Do not use this LDAP attribute in Policy configuration as shared secrets. Instead you create the shared secrets attributes. The Shared secret attributes are populated in the configured LDAP attribute, and are used by policy for mapping. For more information about how to create shared secret, see Section 6.5, Form Fill Policies.

      • To use Novell SecretStore to remotely store secrets, click New under Novell Secret Store User Store References.

        Click the user store that you have configured for SecretStore.

        Secure LDAP must be enabled between the user store and the Identity Server to add this user store reference.

    3. Click OK twice.

  6. On the Identity Server page, update the Identity Server.

Customizing Attribute Names

You can change the display names of the attributes for the Credential, Custom, Employee, and Personal profiles. The customized names are displayed on the My Profile page in the User Portal. The users see the custom names applicable to their language. Custom Attributes are displayed on the My Profile page in the User Portal in place of the corresponding English attribute name when the language in the drop-down list is the accepted language of the browser.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Provider > [Profile] > Custom Attribute Names.

  2. Click the data item name to view the customized attribute names.

  3. Click New to create a new custom name.

  4. Type the name and select a language.

  5. Click OK.

  6. On the Custom Attribute Names page, click OK.

  7. On the Web Service Provider page, click OK.

  8. Update the Identity Server configuration on the Servers page.

Configuring the Web Service Consumer

The Web service consumer is the component within the identity provider that requests attributes from Web service providers. The identity provider and Web services consumer cooperate to redirect the user or resource owner to the identity provider, allowing interaction. You can configure an interaction service, which allows the identity provider to pose simple questions to a user. This service can be offered by trusted Web services consumers, or by a dedicated interaction service provider that has a reliable means of communication with the users.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Consumers

    The following general settings configure time limits and processing speed:

    Protocol Timeout (seconds): Limits the time the transport protocol allows.

    Provider Timeout (seconds): Limits the request processing at the Web service provider. This value must always be equal to or greater than the Protocol Timeout value.

    Attribute Cache Enabled: A subsystem of the Web service consumer that caches attribute data that the Web service consumer requests. For example, if the Web service consumer has already requested a first name attribute from a Web service provider, the Web service consumer does not need to request the attribute again. This setting improves performance when enabled. However, you can disable this option to increase system memory.

  2. Specify how and when the identity provider interacts with the user:

    Always Allow Interaction: Allows interaction to take place between users and service providers.

    Never Allow Interaction: Never allows interaction between users and service providers.

    Always Allow Interaction for Permissions, Never for Data: Allows interaction for permissions, never for data.

    Maximum Allowed Interaction Time: Specifies the allowed time (in seconds).

  3. To specify the allowable methods that a Web service provider can use for user interaction, click one of the following options:

    Redirect to a User Interaction Service: Allows the Web service consumer to redirect the user agent to the Web service provider to ask questions. After the Web service provider has obtained the information it needs, it can redirect the user back to the Web service consumer.

    Call a Trusted User Interaction Service: Allows the Web service provider to trust the Web service consumer to act as proxy for the resource owner.

  4. Under Security Settings, fill in the following fields:

    WSS Security Token Type: Instructs the Web service consumer/requestor how to place the token in the security header as outlined in the Liberty ID-WSF Security Mechanisms.

    Signature Algorithm: The signature algorithm to use for signing the payload.

  5. Click OK, then update the Identity Server configuration as prompted.

Mapping LDAP and Liberty Attributes

You can create an LDAP attribute map or edit an existing one. To create an attribute map, you specify how single-value and multi-value data items map to single-value and multi-value LDAP attributes. A single-value attribute can contain no more than one value, and a multi-value attribute can contain more than one. An example of a single-value attribute might be a person’s gender, and an example of a multi-value attribute might be a person’s various e-mail addresses, phone numbers, or titles.

  1. In the Administration Console, click Devices> Identity Servers > Edit > Liberty >LDAP Attribute Mapping.

  2. Select one of the following actions:

    New: Allows you create an LDAP attribute mapping. Select from the following types:

    Delete: Deletes the selected mapping.

    Enable: Enables the selected mapping.

    Disable: Disables the selected mapping. When the mapping is disabled, the server does not load the definition. However, the definition is not deleted.

  3. Click OK, then update the Identity Server.

Configuring One-to-One Attribute Maps

A one-to-one map enables you to map single-value and multiple-value LDAP attribute names to standard Liberty attributes. A default one-to-one attribute map is provided with Access Manager, but you can also define your own.

An example of a one-to-one attribute map might be the single-valued Liberty attribute Common Name (CommonName) used by the Personal Profile that is mapped to the LDAP attribute givenName. You can further configure the various Liberty values to map to any LDAP attribute names that you use.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > LDAP Attribute Mapping > New > One to One.

  2. Configure the following fields:

    Type: Displays the type of mapping you are modifying or creating:

    Name: The name you want to give the map.

    Description: A description of the map.

    Access Rights: A drop-down menu that provides the broadest control for the page. If you set this to Read/Write, you can specify rights for individual data items.

    For user provisioning to succeed, you must select Read/Write from the Access Rights drop-down menu for any maps that use an attribute during user provisioning.

    User Stores: The user store that a map applies to. If a user logs into a user store that is not in the map’s user store list, that map is not used to read or write attributes for that user.

  3. Use the following guidelines to configure the map:

  4. After you create the mapping, click Finish.

  5. On the LDAP Attribute Mapping page, click OK.

  6. Update the Identity Server.

Mapping Personal Profile Single-Value Data Items to LDAP Attributes

The data items displayed are single-value Liberty Personal Profile attributes that you can map to the single-valued LDAP attributes that you have defined for your directory.

One-to-One attribute map

Mapping Personal Profile Multiple-Value Data Items to LDAP Attributes

Use the fields on this page to map multiple-value attributes from the Liberty Personal Profile to the multiple-value LDAP attributes you have defined for your directory. For example, you can map the Liberty attribute Alternate Every Day Name (AltCN) to the LDAP attribute you have defined for this purpose in your directory.

One-to-One attribute map

Mapping Employee Profile Single-Value Data Items to LDAP Attributes

Map the Liberty Employee Profile single-value attributes to the LDAP attributes you have defined in your directory for entries such as ID, Date of Hire, Job Start Date, Department, and so on.

Mapping Employee Profile Multiple-Value Data Items to LDAP Attributes

Map the Liberty Employee Profile multiple-value attributes to the LDAP attributes you have defined in your directory.

Mapping Custom Profile Single-Value Data Items to LDAP Attributes

Map custom Liberty profile single-value attributes to LDAP attributes you have defined in your directory. These attributes are customizable strings associated with the Custom Profile.

One-to-One attribute map

Customizable String (1 - 10): The Custom Profile allows custom single-value and multiple-value attributes to be defined without using the Data Model Extension XML to extend a service’s schema. To use a customizable attribute, navigate to the Custom Attribute Names tab on the Custom Profile Details page (see Customizing Attribute Names). Use the page to customize the name of any of the predefined single-value or multiple-value customizable attributes in the Custom Profile. After you customize a name, you can use that attribute in the same way you use any other profile attribute.

Mapping Custom Profile Multiple-Value Data Items to LDAP Attributes

Customizable Multi-Valued Strings (1 - 5): Similar to customizable strings for single-value attributes, except these attributes can have multiple values. Use this list of fields to map directory attributes that can have multiple values to multiple-value strings from the Custom Profile.

Configuring Employee Type Attribute Maps

You can map the LDAP attribute name and values to the Liberty profile values for Employee Type. This is an Employee Profile attribute. Examples of Liberty values appended to this attribute include Contractor Part Time, Contractor Full Time, Full Time Regular, and so on.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > LDAP Attribute Mapping > New > Employee Type.

  2. Configure the following fields:

    Name: The name you want to give the map.

    Description: A description of the map.

    Access Rights: A drop-down menu that provide the broadest control for the page. If you set this to Read/Write, you can specify rights for individual data items.

    For user provisioning to succeed, you must select Read/Write from the Access Rights drop-down menu for any maps that use an attribute during user provisioning.

    User Stores: The user store that a map applies to. If a user logs into a user store that is not in the map’s user store list, that map is not used to read or write attributes for that user.

  3. In the LDAP Attribute Name field, type the LDAP attribute name that you want to map to the Liberty Employee Type attribute.

  4. In the LDAP Attribute Value fields, type the predefined LDAP attribute values that you want to map to the Liberty Employee Type values.

    These are the values that you want to store in the LDAP attribute for each given Liberty attribute value. The LDAP attribute map then maps the actual Liberty URI value, back and forth, to this supplied value.

  5. Click Finish.

  6. On the LDAP Attribute Mapping page, click OK.

  7. Update the Identity Server.

Configuring Employee Status Attribute Maps

You can map the LDAP attribute name and values to the Liberty profile values for Employee Status. This is an Employee Profile attribute. Examples of the values appended to this Liberty attribute include Active, Trial, Retired, Terminated, and so on.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > LDAP Attribute Mapping > New > Employee Status.

  2. Configure the following fields:

    Name: The name you want to give the map.

    Description: A description of the map.

    Access Rights: A drop-down menu that provide the broadest control for the page. If you set this to Read/Write, you can specify rights for individual data items.

    For user provisioning to succeed, you must select Read/Write from the Access Rights drop-down menu for any maps that use an attribute during user provisioning.

    User Stores: The user store that a map applies to. If a user logs into a user store that is not in the map’s user store list, that map is not used to read or write attributes for that user.

  3. In the LDAP Attribute Name field, type the LDAP attribute name that you want to map to the Liberty Employee Status element.

  4. In the LDAP Attribute Value fields, type the predefined LDAP attribute values that you want to map to the Liberty Employee Status values.

    These are the values that you want to store in the LDAP attribute for each given Liberty attribute value. The LDAP attribute map then maps the actual Liberty URI value, back and forth, to this supplied value.

  5. Click Finish.

  6. On the LDAP Attribute Mapping page, click OK.

  7. Update the Identity Server.

Configuring Postal Address Attribute Maps

You can map the LDAP attribute name and values to the Liberty profile values for Postal Address. The PostalAddress element refers to the local address, including street or block with a house number, and so on. This is a Personal Profile attribute.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > LDAP Attribute Mapping > New > Postal Address.

  2. Configure the following fields:

    Name: The name you want to give the map.

    Description: A description of the map.

    Access Rights: A drop-down menu that provide the broadest control for the page. If you set this to Read/Write, you can specify rights for individual data items.

    For user provisioning to succeed, you must select Read/Write from the Access Rights drop-down menu for any maps that use an attribute during user provisioning.

    User Stores: The user store that a map applies to. If a user logs into a user store that is not in the map’s user store list, that map is not used to read or write attributes for that user.

  3. In the Mode drop-down menu, select either Multiple LDAP Attributes or Single Delimited LDAP Attributes.

    Multiple LDAP Attributes: Allows you to map multiple LDAP attributes to multiple Liberty Postal Address elements. When you select this option, the following Liberty Postal Address elements are displayed under the Postal Address to LDAP Attributes group. Type the LDAP attributes that you want to map to the Liberty elements.

    • Postal Address

    • Postal Code

    • City

    • State

    • Country

    Single Delimited LDAP Attributes: Allows you to specify one LDAP attribute that is used to hold multiple elements of a Liberty Postal Address in a single delimited value. When you select this option, the page displays the following fields:

    • Delimited LDAP Attribute Name: The delimited LDAP attribute name you have defined for the LDAP postal address that you want to map to the Liberty Postal Address attribute.

    • Delimiter: The character to use to delimit single-value entries. A $ sign is the default delimiter.

  4. (Single Delimited LDAP Attributes mode) Under One-Based Field Position in Delimited LDAP Attribute, specify the order in which the information is contained in the string. Select 1 for the value that comes first in the string, 2 for the value that follows the first delimiter, etc.

  5. (Multiple LDAP Attributes mode) Under Postal Address Template Data, fill in the following options:

    Nickname: (Required) A Liberty element name used to identify the Postal Address object.

    Contact Method Type: Select the contact method type, such as Domicile, Work, Emergency, and so on.

  6. Click Finish.

  7. On the LDAP Attribute Mapping page, click OK.

  8. Update the Identity Server.

Configuring Contact Method Attribute Maps

You can map the LDAP attribute you have defined for contact methods to the Liberty attribute Contact Method (MsgContact).

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > LDAP Attribute Mapping > New > Contact Method.

  2. Configure the following fields:

    Name: The name you want to give the map.

    Description: A description of the map.

    Access Rights: A drop-down menu that provide the broadest control for the page. If you set this to Read/Write, you can specify rights for individual data items.

    For user provisioning to succeed, you must select Read/Write from the Access Rights drop-down menu for any maps that use an attribute during user provisioning.

    User Stores: The user store that a map applies to. If a user logs into a user store that is not in the map’s user store list, that map is not used to read or write attributes for that user.

  3. Under Contact Method to LDAP Attributes, fill in the following fields to map to the Liberty Contact Method attribute:

    Provider LDAP Attribute: Maps to the Liberty attribute MsgProvider, which is the service provider or domain that provides the messaging service.

    Account LDAP Attribute: Maps to the Liberty attribute MsgAccount, which is the account or address information within the messaging provider.

    SubAccount LDAP Attribute: Maps to the Liberty MsgSubaccount, which is the subaccount within a messaging account, such as the voice mail box associated with a phone number.

  4. Under Contact Method Template Data, specify the settings for the following Liberty attribute values:

    Nickname: Maps to the Liberty attribute Nick, which is an informal name for the contact.

    Type: Maps to the Liberty attribute MsgType (such as Mobile, Personal, or Work).

    Method: Maps to the Liberty MsgMethod (such as Voice, Fax, or E-mail).

    Technology: Maps to the Liberty attribute MsgTechnology (such as Pager, VOIP, and so on).

  5. Click Finish.

  6. On the LDAP Attribute Mapping page, click OK.

  7. Update the Identity Server.

Configuring Gender Attribute Maps

You can map the LDAP attribute name and values to the Liberty profile values for the Gender attribute. You can use gender to differentiate between people with the same name, especially in countries where national ID numbers cannot be collected. This is a Personal Profile attribute.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > LDAP Attribute Mapping > New > Gender.

  2. Configure the following fields:

    Name: The name you want to give the map.

    Description: A description of the map.

    Access Rights: A drop-down menu that provide the broadest control for the page. If you set this to Read/Write, you can specify rights for individual data items.

    For user provisioning to succeed, you must select Read/Write from the Access Rights drop-down menu for any maps that use an attribute during user provisioning.

    User Stores: The user store that a map applies to. If a user logs into a user store that is not in the map’s user store list, that map is not used to read or write attributes for that user.

  3. In the LDAP Attribute Name field, type the LDAP attribute name that you want to map to the Liberty element Gender.

  4. In the LDAP Attribute Value fields, type the predefined LDAP attribute values that you want to map to the Gender values.

    These are the values that you want to store in the LDAP attribute for each given Liberty attribute value. The LDAP attribute map then maps the actual Liberty URI value, back and forth, to this supplied value.

  5. Click Finish.

  6. On the LDAP Attribute Mapping page, click OK.

  7. Update the Identity Server.

Configuring Marital Status Attribute Maps

You can map the LDAP marital status attribute to the Liberty attribute. The Liberty Marital Status (MaritalStatus) element includes appended values such as single, married, divorced, and so on. For example, urn:liberty:id-sis-pp:maritalstatus:single. This is a Personal Profile attribute.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > LDAP Attribute Mapping > New > Marital Status.

  2. Configure the following fields:

    Name: The name you want to give the map.

    Description: A description of the map.

    Access Rights: A drop-down menu that provide the broadest control for the page. If you set this to Read/Write, you can specify rights for individual data items.

    For user provisioning to succeed, you must select Read/Write from the Access Rights drop-down menu for any maps that use an attribute during user provisioning.

    User Stores: The user store that a map applies to. If a user logs into a user store that is not in the map’s user store list, that map is not used to read or write attributes for that user.

  3. In the LDAP Attribute Name field, type the LDAP attribute name that you want to map to the Liberty element Marital Status (MaritalStatus).

  4. In the LDAP Attribute Value fields, type the predefined LDAP attribute values that you want to map to the MaritalStatus values.

    These are the values that you want to store in the LDAP attribute for each given Liberty attribute value. The LDAP attribute map then maps the actual Liberty URI value, back and forth, to this supplied value.

  5. Click Finish.

  6. On the LDAP Attribute Mapping page, click OK.

  7. Update the Identity Server.

5.2.8 Configuring WS Federation

The first two topics in this section describe two different methods for setting up federation with a SharePoint server. The next sections describe how you can manage and modify WS Federation providers and configure Security Token Service (STS). STS is used to process authentication requests received at the Identity Server for the WS Federation protocol.

Using the Identity Server as an Identity Provider for ADFS

The Identity Server can provide authentication for resources protected by an Active Directory Federation Services (ADFS) server. This allows the Identity Server to provide single sign-on to Access Manager resources and ADFS resources, such as a SharePoint server. Figure 5-26 illustrates this configuration.

Figure 5-26 Accessing SharePoint Resources with an Identity Server

In this scenario, the following exchanges occur:

  1. The user requests access to a SharePoint server protected by the ADFS server.

  2. The resource sends an authentication request to the ADFS server.

  3. The ADFS server, which has been configured to use the Identity Server as an identity provider, gives the user the option of logging in to the Identity Server.

  4. The user logs in to the Identity Server and is provided a token that is sent to the ADFS server and satisfies the request of the resource.

  5. The user is allowed to access the resource.

The following section describe how to configure your servers for this scenario:

Configuring the Identity Server

Prerequisites
Creating a New Authentication Contract

The Microsoft ADFS server rejects the contract URI names of the default Access Manager contracts, which have a URI format of secure/name/password/uri. The ADFS server expects the URI to look like a URL.

We suggest that you use the following format for the URI of all contracts that you want to use with the ADFS server:

<baseurl>/name/password/uri

If the DNS name of your Identity Server is idp-50.amlab.net, the URI would have the following format:

https://idp-50.amlab.net:8443/nidp/name/password/uri

This URL doesn't resolve to anything because the Identity Server interprets it as a contract URI and not a URL.

To create a new authentication contract:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Local > Contracts.

  2. Click New, then fill in the following fields:

    Display name: Specify a name, for example WS-Fed Contract.

    URI: Specify a URI, for example https://idp-50.amlab.net:8443/nidp/name/password/uri.

    Satisfiable by External Provider: Enable this option. The ADFS server needs to satisfy this contract.

  3. Move Name/Password – Form to the Methods list.

  4. Click Next, then fill in the following fields:

    ID: Leave this field blank. You only need to supply a value when you want a reference that you can use externally.

    Text: Specify a description that is available to the user when the user mouses over the card.

    Image: Select an image, such as Form Auth Username Password. This is the default image for the Name/Password - Form contract.

    Show Card: Enable this option so that the card can be presented to the user as a login option.

  5. Click Finish.

  6. Continue with Setting the WS-Fed Contract to Be the Default Contract.

Setting the WS-Fed Contract to Be the Default Contract

It is not possible to specify the contract to request from the ADFS service provider to the Identity Server. You must either set the contract for WS-Fed to be the default, or have your users remember to click that contract every time.

  1. On the Local page of the Identity Server, click Defaults.

  2. For the Authentication Contract option, select the WS-Fed Contract.

  3. Click Apply.

  4. Continue with Enabling the WS Federation Protocol.

Enabling the WS Federation Protocol

Access Manager ships with only SAML 1.1, Liberty, and SAML 2.0 enabled by default. To use the WS Federation protocol, you must enable it on the Identity Server.

  1. Click the General tab.

  2. In the Enabled Protocols section, select WS Federation.

  3. Click OK.

  4. Update the Identity Server.

  5. Continue with Creating an Attribute Set for WS Federation.

Creating an Attribute Set for WS Federation

The WS Federation namespace is http://schemas.xmlsoap.org/claims. With WS Federation, you need to decide which attributes you want to share during authentication. This scenario uses the LDAP mail attribute and the All Roles attribute.

  1. On the Identity Servers page, click Shared Settings.

  2. To create a new attribute set, click New, then fill in the following fields:

    Set Name: Specify a name that identifies the purpose of the set, for example, wsfed_attributes.

    Select set to use as template: Select None.

  3. Click Next.

  4. To add a mapping for the mail attribute:

    1. Click New.

    2. Fill in the following fields:

      Local attribute: Select LDAP Attribute:mail [LDAP Attribute Profile].

      Remote attribute: Specify emailAddress. This is the attribute that this scenario uses for user identification.

      Remote namespace: Select the radio button by the text box, then specify the following namespace:

      http://schemas.xmlsoap.org/claims

    3. Click OK.

  5. To add a mapping for the All Roles attribute:

    1. Click New.

    2. Fill in the following fields:

      Local attribute: Select All Roles.

      Remote attribute: Specify group. This is the name of the attribute that is used to share roles.

      Remote namespace: Select the radio button by the text box, then specify the following namespace:

      http://schemas.xmlsoap.org/claims

    3. Click OK.

  6. Click Finish.

  7. Continue with Enabling the Attribute Set.

Enabling the Attribute Set

Because the WS Federation protocol uses STS, you must enable the attribute set for STS to use it in an WS Federation relationship.

  1. On the Identity Servers page, click Servers > Edit > WS Federation > STS Attribute Sets.

  2. Move the WS Federation attribute set to the Attribute sets list.

  3. Select the WS Federation attribute set and use the up-arrow to make it first in the Attribute set list.

  4. Click OK, then update the Identity Server.

Creating a WS Federation Service Provider

To establish a trusted relationship with the ADFS server, you need to set up the Trey Research site as a service provider. The trusted relationship allows the service provider to trust the Identity Server for user authentication credentials.

Trey Research is the default name for the ADFS resource server. If you have used another name, substitute it when following these instructions. To create a service provider, you need to know the following about the ADFS resource server.

Table 5-15 ADFS Resource Server Information

What You Need to Know

Default Value and Description

Provider ID

Default Value: urn:federation:treyresearch

This is the value that the ADFS server provides to the Identity Server in the realm parameter of the query string. This value is specified in the Properties of the Trust Policy page on the ADFS server. The parameter label is Federation Service URI.

Sign-on URL

Default Value: https://adfsresource.treyresearch.net/adfs/ls/

This is the value that the identity provider redirects the user to after login. Although it is listed as optional, and is optional between two NetIQ Identity Servers, the ADFS server doesn't send this value to the identity provider. It is required when setting up a trusted relationship between an ADFS server and a NetIQ Identity Server.

This URL is listed in the Properties of the Trust Policy page on the ADFS server. The parameter label is Federation Services endpoint URL.

Logout URL

Default Value: https://adfsresource.treyresearch.net/adfs/ls/

This parameter is optional. If it is specified, the user is logged out of the ADFS server and the Identity Server.

Signing Certificate

This is the certificate that the ADFS server uses for signing.

You need to export it from the ADFS server. It can be retrieved from the properties of the Trust Policy on the ADFS Server on the Verification Certificates tab.This certificate is a self-signed certificate that you generated when following the Active Directory step-by-step guide.

To create a service provider configuration:

  1. On the Identity Servers page, click Edit > WS Federation.

  2. Click New > Service Provider, then fill in the following fields:

    Name: Specify a name that identifies the service provider, such as TreyResearch.

    Provider ID: Specify the provider ID of the ADFS server. The default value is urn:federation:treyresearch.

    Sign-on URL: Specify the URL that the user is redirected to after login. The default value is https://adfsresource.treyresearch.net/adfs/ls/.

    Logout URL: (Optional) Specify the URL that the user can use for logging out. The default value is https://adfsresource.treyresearch.net/adfs/ls.

    Service Provider: Specify the path to the signing certificate of the ADFS server.

  3. Click Next, confirm the certificate, then click Finish.

  4. Continue with Configuring the Name Identifier Format.

Configuring the Name Identifier Format

The Unspecified Name Identifier format is the default for a newly created WS Federation service provider, but this name identifier format doesn't work with the ADFS federation server. Additionally, some Group Claims (Adatum ClaimApp Claim and Adatum TokenApp Claim) must be satisfied in order to gain access to the SharePoint server.

  1. On the WS Federation page, click the name of the TreyResearch service provider.

  2. Click Attributes, then fill in the following fields:

    Attribute set: Select the WS Federation attribute set you created.

    Send with authentication: Move the All Roles attribute to the Send with authentication list.

  3. Click Apply, then click Authentication Response.

  4. Select E-mail for the Name Identifier Format.

  5. Select LDAP Attribute:mail [LDAP Attribute Profile] as the value for the e-mail identifier.

  6. Click OK twice, then update the Identity Server.

  7. Continue with Setting Up Roles for ClaimApp and TokenApp Claims.

Setting Up Roles for ClaimApp and TokenApp Claims

When users access resources on the ADFS server, they need to have two roles assigned: a ClaimApp role and a TokenApp role. The following steps explain how to create these two roles so that they are assigned to all users that log in to the Identity Server.

  1. On the Identity Servers page, click Edit > Roles > Manage Policies.

  2. Click New, specify a name for the policy, select Identity Server: Roles, then click OK.

  3. On the Rule 1 page, leave Condition Group 1 blank.

    With no conditions to match, this rule matches all authenticated users.

  4. In the Actions section, click New > Activate Role.

  5. In the text box, specify ClaimApp.

  6. In the Actions section, click New > Activate Role.

  7. In the text box, specify TokenApp.

  8. Click OK twice, then click Apply Changes.

  9. Click Close.

  10. On the Roles page, select the role policy you just created, then click Enable.

  11. Click OK, then update the Identity Server.

  12. Continue with Importing the ADFS Signing Certificate into the NIDP-Truststore.

Importing the ADFS Signing Certificate into the NIDP-Truststore

The NetIQ Identity Provider (NIDP) must have the trusted root of the ADFS signing certificate (or the certificate itself) listed in its Trust Store, as well as specified in the relationship. This is because most ADFS signing certificates are part of a certificate chain, and the certificate that goes into the metadata is not the same as the trusted root of that certificate. However, because the Active Directory step-by-step guide uses self-signed certificates for signing, it is the same certificate in both the Trust Store and in the relationship.

To import the ADFS signing certificate’s trusted root (or the certificate itself) into the NIDP-Truststore:

  1. On the Identity Servers page, click Edit > Security > NIDP Trust Store.

  2. Click Add.

  3. Next to the Trusted Root(s) field, click the Select Trusted Root(s) icon.

    This adds the trusted root of the ADFS signing certificate to the Trust Store.

  4. On the Select Trusted Roots page, select the trusted root or certificate that you want to import, then click Add Trusted Roots to Trust Stores.

    If there is no trusted root or certificate in the list, click Import. This enables you to import a trusted root or certificate.

  5. Next to the Trust store(s) field, click the Select Keystore icon.

  6. Select the trust stores where you want to add the trusted root or certificate, then click OK twice.

  7. Update the Identity Server so that the changes can take effect.

This finishes the configuration that must be done on the Identity Server for the Identity Server to trust the ADFS server. The ADFS server must be configured to trust the Identity Server. Continue with Configuring the ADFS Server.

Configuring the ADFS Server

The following tasks must be completed on the Trey Research server (adfsresouce.treyresearch.net) to establish trust with the NetIQ Identity Server.

Enabling E-mail as a Claim Type

There are three types of claims for identity that can be enabled on an ADFS server. They are Common Name, E-mail, and User Principal Name. The ADFS step-by-step guide specifies that you do everything with a User Principal Name, which is an Active Directory convention. Although it could be given an e-mail name that looks the same, it is not. This scenario selects to use E-mail instead of Common Name because E-mail is a more common configuration.

  1. From the Administrative Tools, open the Active Directory Federation Services tool.

  2. Navigate to the Organizational Claims by clicking Federation Service > Trust Policy > My Organization.

  3. Verify that E-mail is in this list. If it isn’t, move it to the list.

  4. Navigate to your Token-based Application and enable e-mail by right-clicking the application, editing the properties, and clicking the Enabled box.

  5. Navigate to your Claims-aware Application and repeat the process.

  6. Continue with Creating an Account Partners Configuration.

Creating an Account Partners Configuration

WS Federation requires a two-way trust relationship. Both the identity provider and the service provider must be configured to trust the other provider. This task sets up the trust between the ADFS server and the Identity Server.

  1. In the Active Directory Federation Services console, navigate to the Account Partners by clicking Federation Services >Trust Policy > Partner Organizations.

  2. Right-click Partner Organizations, then select New > Account Partner.

  3. Supply the following information in the wizard:

    • You do not have an account partner policy file.

    • For the display name, specify the DNS name of the Identity Server.

    • For the Federation Services URI, specify the following:

      https://<DNS_Name>:8443/nidp/wsfed/

      Replace <DNS_Name> with the DNS name of the Identity Server.

      This URI is the base URL of your Identity Server with the addition of /wsfed/ on the end.

    • For the Federation Services endpoint URL, specify the following:

      https://<DNS_Name>:8443/nidp/wsfed/ep

      Replace <DNS_Name> with the DNS name of the Identity Server.

      This URL is the base URL of your Identify Server with the addition of /wsfed/ep at the end.

    • For the verification certificate, import the trusted root of the signing certificate on your Identity Server.

      If you have not changed it, you need the Organizational CA certificate from your Administration Console. This is the trusted root for the test-signing certificate.

    • Select Federated Web SSO.

      The Identity Server is outside of any forest, so do not select Forest Trust.

    • Select the E-mail claim.

    • Add the suffix that you will be using for your e-mail address.

      You need to have the e-mail end in a suffix that the ADFS server is expecting, such as @novell.com, which grants access to any user with that e-mail suffix.

  4. Enable this account partner.

  5. Finish the wizard.

  6. Continue with Enabling ClaimApp and TokenApp Claims.

Enabling ClaimApp and TokenApp Claims

The Active Directory step-by-step guide sets up these roles to be used by the resources. You set them up to be sent in the All Roles attribute from the Identity Server. You must map these roles into the Adatum ClaimApp Claim and the Adatum TokenApp Claim.

  1. In the Active Directory Federation Services console, click the account partner that you created for the Identity Server (see Creating an Account Partners Configuration).

  2. Right click the account partner, then create a new Incoming Group Claim Mapping with the following values:

    Incoming group claim name: Specify ClaimApp.

    Organization group claim: Specify Adatum ClaimApp Claim.

  3. Right-click the account partner, and create another Incoming Group Claim Mapping with the following values:

    Incoming group claim name: Specify TokenApp.

    Organization group claim: Specify Adatum TokenApp Claim.

  4. Continue with Disabling CRL Checking.

Disabling CRL Checking

If you are using the Access Manager certificate authority as your trusted root for the signing certificate (test-signing certificate), there is no CRL information in that certificate. However, the ADFS has a mandatory requirement to do CRL checking on any certificate that they receive. For instructions on how to disable this checking, see “Turn CRL checking on or off”.

Use the following tips as you follow these instructions.

  • Create a file from the script contained at that link called TpCrlChk.vbs.

  • Exit the Active Directory Federation Services console.

    If you do not exit the console, the console overwrites the changes made by the script file and CRL checking is not turned off.

  • Run the command with the following syntax:

    Cscript TpCrlChk.vbs <location of ADFS>\TrustPolicy.xml "<service URI>" None

    Replace <location of ADFS> with the location of the ADFS TrustPolicy.xml file. The default location is C:\ADFS\TrustPolicy.xml.

    Replace <service URI> with the URI you specified in Step 3. If the DNS name of your Identity Server is idp-50.amlab.net, replace it with https://idp-50.amlab.ne:8443/nidp/wsfed/.

    Your command should look similar to the following:

    Cscript TpCrlChk.vbs C:\ADFS\TrustPolicy.xml "https://idp-50.amlab.net:8443/nidp/wsfed/" None

Logging In

  1. In a browser on your client machine, enter the URL of the SharePoint server. For example:

    https://adfsweb.treyresearch.net/default.aspx

  2. Select the IDP from the drop-down list of home realm, then submit the request.

    If you are not prompted for the realm, clear all cookies in the browser and try again.

  3. Log in with a user at the NetIQ Identity Provider

  4. Verify that you can access the SharePoint server.If you only see a page that says Server Error in '/adfs' Application, see Turning On Logging on the ADFS Server and follow the instructions in Common Errors.

Troubleshooting

Turning On Logging on the ADFS Server

If you see the message Server Error in '/adfs' Application displayed in the client's browser, the best place to look for the cause is in the ADFS log file.

To turn on this log file:

  1. In the Active Directory Federation Services console, right-click Federation Service, then click Properties.

  2. Click the Troubleshooting tab, then enable everything on the page.

  3. Click OK, then look for the file that is created in the path listed in the Log files directory.

  4. Look in that file for reasons that the federation is failing.

    For an explanation of some of the common errors, see Common Errors.

Common Errors
[ERROR] SamlViolatesSaml:

Error parsing AuthenticationMethod: Invalid URI: The format of the URI could not be determined.

Cause: This is because the contract has the wrong format for its URI. The URI must start with urn: or http://. Change the contract and try again.

[ERROR] Saml contains an unknown NameIdentifierFormat:

Issuer=https://idp-51.amlab.net:8443/nidp/wsfed/; Format=urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Cause: The name identifier format is set to unspecified, and it needs to be set to E-mail.

[ERROR] Saml contains an unknown Claim name/namespace:

Issuer=https://idp-51.amlab.net:8443/nidp/wsfed/; Namespace=urn:oasis:names:tc:SAML:1.0:assertion; Name=emailaddress

Cause: The emailAddress attribute is not in the correct namespace for WSFed.

CRL Errors

  • 2008-08-01T19:56:55 [WARNING] VerifyCertChain: Cert chain did not verify - error code was 0x80092012

  • 2008-08-01T19:56:55 [ERROR] KeyInfo processing failed because the trusted certificate does not have a a valid certificate chain. Thumbprint = 09667EB26101A98F44034A3EBAAF9A3A09A0F327

  • 2008-08-01T19:56:55 [WARNING] Failing signature verification because the KeyInfo section failed to produce a key.

  • 2008-08-01T19:56:55 [WARNING] SAML token signature was not valid: AssertionID = idZ0KQH0kfjVK8kmKfv6YaVPglRNo

Cause: The CRL check isn't turned off. See Disabling CRL Checking.

[ERROR] EmailClaim.set_Email:

Email 'mPmNXOA8Rv+j16L1iNKn/4HVpfeJ3av1L9c0GQ==' has invalid format

Cause: The drop-down list next to E-mail in the identifier format was not changed from <Not Specified> to a value with a valid e-mail address in it.

Using the ADFS Server as an Identity Provider for an Access Manager Protected Resource

The Active Directory Federation Services server can be configured to provide authentication for a resource protected by Access Manager.

Figure 5-27 Using an ADFS Server for Access Manager Authentication

In this scenario, the following exchanges occur:

  1. The user requests access to a resource protected by an Access Gateway.

  2. The resource sends an authentication request to the NetIQ Identity Server.

  3. The Identity Server is configured to trust an Active Directory Federation Services server and gives the user the option of logging in at the Active Directory Federation Services server.

  4. The user logs into the Active Directory Federation Services server and is provided a token

  5. The token is sent to the Identity Server.

  6. The token satisfies the authentication requirements of the resource, so the user is allowed to access the resource.

The following sections describe how to configure this scenario.

Configuring the Identity Server as a Service Provider

Prerequisites

  • You have set up the Active Directory Federation Services, Active Directory, and SharePoint servers and the client as described in the ADFS guide from Microsoft. See the “Step-by-Step Guide for Active Directory Federation Services”.

  • You have set up the NetIQ Access Manager system with a site configuration that is using SSL in the Identity Server's base URL. See Section 14.0, Enabling SSL Communication.

  • Enable the Liberty Personal Profile.

    In the Administration Console, click Identity Servers > Edit > Liberty > Web Service Provider. Select the Personal Profile, then click Enable > Apply. Update the Identity Server.

Enabling the WS Federation Protocol

Access Manager ships with only SAML 1.1, Liberty, and SAML 2.0 enabled by default. To use the WS Federation protocol, it must be enabled on the Identity Server.

  1. In the Administration Console, click Devices > Identity Servers > Edit.

  2. In the Enabled Protocols section of the General Configuration page, select WS Federation.

  3. Click OK.

  4. Update the Identity Server.

  5. Continue with Creating a WS Federation Identity Provider.

Creating a WS Federation Identity Provider

To have a trust relationship, you need to set up the Adatum site (adfsaccount.adatum.com) as an identity provider for the Identity Server.

Adatum is the default name for the identity provider. If you have used another name, substitute it when following these instructions. To create an identity provider, you need to know the following information about the Adatum site:

Table 5-16 Adatum Values

What You Need to Know

Default Value and Description

Provider ID

Default Value: urn:federation:adatum

The ADFS server provides this value to the service provider in the realm parameter in the assertion. You set this value in the Properties of the Trust Policy on the ADFS server. The label is Federation Service URI.

Sign-on URL

Default Value: https://adfsaccount.adatum.com/adfs/ls/

The service provider uses this value to redirect the user for login. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL.

Logout URL

Default Value: https://adfsresource.treyresearch.net/adfs/ls/

The ADFS server makes no distinction between the login and logout URL. Access Manager has separate URLs for login and logout, but from a NetIQ Identity Server to an ADFS server, they are the same.

Signing Certificate

This is the certificate that the ADFS server uses for signing.

You need to export it from the ADFS server. It can be retrieved from the properties of the Trust Policy on the ADFS Server on the Verification Certificates tab.This certificate is a self-signed certificate that you generated when following the step-by-step guide.

To create an identity provider:

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation.

  2. On the WS Federation page, click New, select Identity Provider, then fill in the following fields:

    Name: Specify a name that identifies the identity provider, such as Adatum.

    Provider ID: Specify the federation service URI of the identity provider, for example urn:federation:adatum.

    Sign-on URL: Specify the URL for logging in, such as https://adfsaccount.adatum.com/adfs/ls/.

    Logout URL: Specify the URL for logging out, such as https://adfsresource.treyresearch.net/adfs/ls/

    Identity Provider: Specify the path to the signing certificate of the ADFS server.

  3. Confirm the certificate, then click Next.

  4. For the authentication card, specify the following values:

    ID: Leave this field blank.

    Text: Specify a description that is available to the user when the user mouses over the card.

    Image: Select an image, such as Customizable, or any other image.

    Show Card: Enable this option so that the card can be presented to the user as a login option.

  5. Click Finish.

  6. Continue with Modifying the User Identification Specification.

Modifying the User Identification Specification

The default settings for user identification are set to do nothing. The user can authenticated but the user is not identified as a local user on the system. This is not the scenario we are configuring. We want the user to be identified on the local system. Additionally, we want to specify which contract on the Access Gateway is satisfied with this identification. If a contract is not specified, the Access Gateway resources must be configured to use the Any Contract option, which is not a typical configuration.

  1. On the WS Federation page, click the name of the Adatum identity provider configuration.

  2. Click User Identification.

  3. For Satisfies contract, select Name/Password – Form.

  4. Select Allow federation.

  5. For the User Identification Method, select Authenticate.

  6. Click OK twice.

  7. Update the Identity Provider.

  8. Continue with Importing the ADFS Signing Certificate into the NIDP-Truststore.

Importing the ADFS Signing Certificate into the NIDP-Truststore

The Identity Server must have the trusted root of the ADFS signing certificate (or the certificate itself) listed in its trust store, as well as specified in the relationship. This is because most ADFS signing certificates have a chain, and the certificate that goes into the metadata is not the same as the trusted root of that certificate. However, because the Active Directory step-by-step guide uses self-signed certificates for signing, it is the same certificate in both the trust store and in the relationship.

To import the ADFS signing certificate’s trusted root (or the certificate itself) into the NIDP-Truststore:

  1. On the Identity Servers page, click Edit > Security > NIDP Trust Store.

  2. Click Add.

  3. Next to the Trusted Root(s) field, click the Select Trusted Root(s) icon.

    This adds the trusted root of the ADFS signing certificate to the Trust Store.

  4. On the Select Trusted Roots page, select the trusted root or certificate that you want to import, then click Add Trusted Roots to Trust Stores.

    If there is no trusted root or certificate in the list, click Import. This enables you to import a trusted root or certificate.

  5. Next to the Trust store(s) field, click the Select Keystore icon.

  6. Select the trust stores where you want to add the trusted root or certificate, then click OK twice.

  7. Update the Identity Server so that changes can take effect.

This ends the basic configuration that must be done to for the Identity Server to trust the ADFS server as an identity provider. However, the ADFS server needs to be configured to act as an identity server and to trust the Identity Server. Continue with Configuring the ADFS Server to Be an Identity Provider.

Configuring the ADFS Server to Be an Identity Provider

The following tasks describe the minimum configuration required for the ADFS server to act as an identity provider for the Access Manager Identity Server.

For additional configuration options, see Additional WS Federation Configuration Options.

Enabling a Claim Type for a Resource Partner

You can enable three types of claims for identity on an ADFS Federation server. They are Common Name, E-mail, and User Principal Name. The ADFS step-by-step guide specifies that you do everything with a User Principal Name, which is an Active Directory convention. Although it could be given an e-mail that looks the same, it is not. This scenario selects to use E-mail instead of Common Name because E-mail is a more common configuration.

  1. In the Administrative Tools, open the Active Directory Federation Services tool.

  2. Navigate to the Organizational Claims by clicking Federation Service > Trust Policy > My Organization.

  3. Ensure that E-mail is in this list.

  4. Navigate to Active Directory by clicking Federation Services > Trust Policy > Account Stores.

  5. Enable the E-mail Organizational Claim:

    1. Right-click this claim, then select Properties.

    2. Click the Enabled box.

    3. Add the LDAP mail attribute by clicking Settings > LDAP attribute and selecting mail.

      This is the LDAP attribute in Active Directory where the user’s e-mail address is stored.

    4. Click OK.

  6. Verify that the user you are going to use for authentication has an E-mail address in the mail attribute.

  7. Continue with Creating a Resource Partner.

Creating a Resource Partner

The WS Federation protocol requires a two-way trust. The identity provider must be configured to trust the service provider, and the service provider must be configured to trust the identity provider. You have already set up the service provider to trust the identity provider (see Creating a WS Federation Identity Provider). This section sets up the trust so that the identity provider (the ADFS server) trusts the service provider (the Identity Server).

  1. In the Active Directory Federation Services console, access the Resource Partners page by clicking Federation Services > Trust Policy > Partner Organizations.

  2. Right-click the Partner Organizations, then click New > Resource Partner.

  3. Supply the following information in the wizard:

    • You do not have a resource partner policy file to import.

    • For the display name, specify the DNS name of the Identity Server.

    • For the Federation Services URI, enter the following:

      https://<DNS_Name>:8443/nidp/wsfed/

      Replace <DNS_Name> with the name of your Identity Server.

      This is the base URL of your Identity Server with the addition of /wsfed/ at the end.

    • For the Federation Services endpoint URL, specify the following:

      https://<DNS_Name>:8443/nidp/wsfed/spassertion_consumer

      Replace <DNS_Name> with the name of your Identity Server.

      This is the base URL of your Identity Server with the addition of /wsfed/spassertion_consumer at the end.

    • Select Federated Web SSO.

      The Identity Server is outside of any forest, so do not select Forest Trust.

    • Select the E-mail claim.

    • Select the Pass all E-mail suffixes through unchanged option.

  4. Enable this resource partner.

  5. Finish the wizard.

  6. To test the configuration, continue with Logging In.

Logging In

  1. In a client browser, enter the base URL of your Identity Server.

  2. From the list of cards, select the Adatum contract.

  3. (Conditional) If you are not joined to the Adatum domain, enter a username and password in the browser pop-up. Use a name and a password that are valid in the Adatum domain.

    If you are using the client that is joined to the Adatum domain, the card uses a Kerberos ticket to authenticate to the ADFS identity provider (resource partner).

  4. When you are directed back to the Identity Server for Federation User Identification, log in to the Identity Server with a username and password that is valid for the Identity Server (the service provider).

  5. Verify that you are authenticated.

  6. Close the browser.

  7. Log in again.

    This time you are granted access without entering credentials at the service provider.

Additional WS Federation Configuration Options

You can enable the sharing of attribute information from the Identity Server to the ADFS server. This involves creating an attribute set and enabling the sending of the attributes at authentication. See Configuring the Attributes Obtained at Authentication.

For other options that can be modified after you have created the trusted identity server configuration, see Modifying a WS Federation Identity Provider.

Managing WS Federation Providers

The WS Federation page allows you to create or edit trusted identity providers and trusted service providers. When you create an identity provider configuration, you are configuring the Identity Server to be a WS Federation resource partner. When you create a service provider configuration, you are configuring the Identity Server to be a WS Federation account partner.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation.

  2. Select one of the following actions:

    New: Launches the Create Trusted Identity Provider Wizard or the Create Trusted Service Provider Wizard, depending on your selection. For more information, see one of the following:

    Delete: Allows you to delete the selected identity or service provider. This action deletes the definition.

    Enable: Enables the selected identity or service provider.

    Disable: Disables the selected identity or service provider. When the provider is disabled, the server does not load the definition. However, the definition is not deleted.

    Modify: Click the name of a provider. For configuration information, see Modifying a WS Federation Identity Provider or Modifying a WS Federation Service Provider.

  3. Click OK, then update the Identity Server.

Creating an Identity Provider for WS Federation

To have a trust relationship, you need to set up the ADFS server as an identity provider for the Identity Server.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation.

  2. On the WS Federation page, click New, select Identity Provider, then fill in the following fields:

    Name: Specify a name that identifies the identity provider, such as Adatum.

    Provider ID: Specify the federation service URI of the identity provider, for example urn:federation:adatum.

    Sign-on URL: Specify the URL for logging in, such as https://adfsaccount.adatum.com/adfs/ls/.

    Logout URL: Specify the URL for logging out, such as https://adfsresource.treyresearch.net/adfs/ls/

    Identity Provider: Specify the path to the signing certificate of the ADFS server.

  3. Confirm the certificate, then click Next.

  4. For the authentication card, specify the following values:

    ID: Leave this field blank.

    Text: Specify a description that is available to the user when the user mouses over the card.

    Image: Select an image, such as Customizable, or any other image.

    Show Card: Enable this option so that the card can be presented to the user as a login option.

  5. Click Finish.

For information about additional configuration steps required to use this identity provider, see Using the ADFS Server as an Identity Provider for an Access Manager Protected Resource.

Creating a Service Provider for WS Federation

To establish a trusted relationship with the ADFS server, you need to set up the ADFS server as service provider. The trusted relationship allows the service provider to trust the Identity Server for user authentication credentials.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation.

  2. Click New > Service Provider, then fill in the following fields:

    Name: Specify a name that identifies the service provider, such as TreyResearch.

    Provider ID: Specify the provider ID of the ADFS server. The default value is urn:federation:treyresearch.

    Sign-on URL: Specify the URL that the user is redirected to after login. The default value is https://adfsresource.treyresearch.net/adfs/ls/.

    Logout URL: (Optional) Specify the URL that the user can use for logging out. The default value is https://adfsresource.treyresearch.net/adfs/ls.

    Service Provider: Specify the path to the signing certificate of the ADFS server.

  3. Click Next, confirm the certificate, then click Finish.

For information about additional configuration steps required to use this service provider, see Using the Identity Server as an Identity Provider for ADFS.

Modifying a WS Federation Identity Provider

This section explains how to modify a WS Federation identity provider after it has been created. Creating an Identity Provider for WS Federation explains the steps required to create an identity provider. You can modify the following configuration details:

Renaming the Trusted Provider

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Provider Name].

  2. In the Name field, specify a new name for the trusted provider.

  3. Click OK twice, then update the Identity Server.

Configuring the Attributes Obtained at Authentication

When the Identity Server creates its request to send to the identity provider, it uses the attributes that you have selected. The request asks the identity provider to provide values for these attributes. You can then use these attributes to create policies, to match user accounts, or if you allow provisioning, to create a user account on the service provider.

To select the attributes:

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Attributes.

  2. (Conditional) To create an attribute set, select New Attribute Set from the Attribute Set drop-down menu.

    An attribute set is a group of attributes that can be exchanged with the trusted provider. For example, you can specify that the local attribute of any attribute in the Liberty profile (such as Informal Name) matches the remote attribute specified at the service provider.

    1. Specify a set name, then click Next.

    2. On the Define Attributes page, click New.

    3. Select a local attribute.

    4. Specify the name of the remote attribute.

    5. For the namespace, specify http://schemas.xmlsoap.org/claims.

    6. Click OK.

    7. To add other attributes to the set, repeat Step 2.b through Step 2.e.

    8. Click Finish.

  3. Select an attribute set.

  4. Select attributes from the Available list, and move them to the left side of the page.

  5. (Conditional) If you created a new attribute set, it must be enabled for STS.

    For more information, see Enabling the Attribute Set.

  6. Click OK, then update the Identity Server.

Modifying the User Identification Method

The user identification method specifies how to identify the user.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > User Identification.

  2. Select the contract that can be used for authentication. Fill in the following field:

    Satisfies contract: Specifies the contract that is satisfied by the assertion received from the identity provider. WS Federation expects the URI name of the contract to look like a URL, so it rejects all default Access Manager contracts. You must create a contract with a URI that conforms to WS Federation requirements.

    For more information about how to create this contract, see Creating a New Authentication Contract.

  3. Specify whether the user can associate (federate) an account at the identity provider (the ADFS server) with an account at Identity Server. Fill in the following field:

    Allow federation: Indicates whether account federation is allowed. Enabling this option assumes that a user account exists at the provider or that a method is provided to create an account that can be associated with the user on subsequent logins. If you do not use this feature, authentication is permitted but is not associated with a particular user account.

  4. Select one of the following methods for user identification:

    • Do nothing: Allows the user to authenticate without creating an association with a user account. This option cannot be used when federation is enabled.

    • Authenticate: Allows the user to authenticate using a local account.

      • Allow ‘Provisioning’: Provides a button that the user can click to create an account when the authentication credentials do not match an existing account.

    • Provision account: Allows a new account to be created for the user when the authenticating credentials do not match an existing user. When federation is enabled, the new account is associated with the user and used with subsequent logins. When federation is not enabled, a new account is created every time the user logs in.

      This option requires that you specify a user provisioning method.

    • Attribute matching: Enables account matching. The service provider can uniquely identify a user in its directory by obtaining specific user attributes sent by the trusted identity provider. This option requires that you specify a user matching method.

      • Prompt for password on successful match: Specifies whether to prompt the user for a password when the user’s name is matched to an account, to ensure that the account matches.

  5. (Conditional) If you selected a method that requires provisioning (Allow ‘Provisioning’ or Provision account), click the Provision settings icon and create a provisioning method.

    For configuration information, see Defining the User Provisioning Method.

  6. (Conditional) If you selected Attribute matching as the identification method, click the Attribute Matching settings icon and create a matching method.

    For configuration information, see Configuring the Attribute Matching Method for Liberty or SAML 2.0.

  7. Click OK twice, then update the Identity Server.

Viewing the WS Identity Provider Metadata

You can view the metadata of the ADFS server, edit it, and view information about the signing certificate.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Metadata.

    The following values need to be configured accurately:

    ID: This is provider ID. The ADFS server provides this value to the service provider in the realm parameter in the assertion. You set this value in the Properties of the Trust Policy on the ADFS server. The label is Federation Service URI. The default value is urn:federation:adatum.

    sloUrl: This is the sign-on URL. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL.

    ssoUrl: This is the logout URL. The default value is https://adfsresource.treyresearch.net/adfs/ls/. The ADFS server makes no distinction between the login URL and the logout URL.

    If the values do not match the ADFS values, you need to edit the metadata.

  2. To edit the metadata, click Edit. For configuration information, see Editing the WS Identity Provider Metadata.

  3. To view information about the signing certificate, click Certificates.

  4. Click OK twice.

Editing the WS Identity Provider Metadata

You can view and edit the metadata of the ADFS server.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Metadata > Edit.

  2. Configure the following fields:

    Provider ID: This is the provider ID. The ADFS server provides this value to the service provider in the realm parameter in the assertion. You set this value in the Properties of the Trust Policy on the ADFS server. The label is Federation Service URI. The default value is urn:federation:adatum.

    Sign-on URL: This is the sloUrl. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL.

    Logout URL: This is the ssoUrl. The default value is https://adfsresource.treyresearch.net/adfs/ls/. The ADFS server makes no distinction between the login URL and the logout URL.

  3. If you need to import a new signing certificate, click the Browse button and follow the prompts.

  4. To view information about the signing certificate, click Certificates.

  5. Click OK twice, then update the Identity Server.

Modifying the Authentication Card

When you create an identity provider, you must also configure an authentication card. After it is created, you can modify it.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Authentication Card.

  2. Modify the values in one or more of the following fields:

    ID: If you have need to reference this card outside of the Administration Console, specify an alphanumeric value here. If you do not assign a value, the Identity Server creates one for its internal use. The internal value is not persistent. Whenever the Identity Server is rebooted, the value can change. A specified value is persistent.

    Text: Specify the text that is displayed on the card. This value, in combination with the image, indicates to the users the provider they are logging into.

    Image: Specify the image to be displayed on the card. Select the image from the drop-down list. To add an image to the list, click <Select local image>.

    Show Card: Determine whether the card is shown to the user, which allows the user to select and use the card for authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.

    Passive Authentication Only: Select this option if you do not want the Identity Server to prompt the user for credentials. If the user has already authenticated and the credentials satisfy the requirements of this contract, the user is passively authenticated. If the user’s credentials do not satisfy the requirements of this contract, the user is denied access.

  3. Click OK twice, then update the Identity Server.

Assertion Validity Window

You can configure the assertion validity time for WS Federation Provider (SP) to accommodate clock skew between the Service Provider and SAML IDP Server.

To set the assertion validity for WSFed configuration, add the following parameters in the IDP web.xml and restart tomcat:

Add the following parameters in the web.xml below the ldapLoadThreshold context param:

  <context-param>           
    <param-name>wsfedAssertionValidity</param-name>
    <param-value>600</param-value>
  </context-param>

The value 600 which is configurable denotes seconds.

To restart Tomcat enter the following command:

Linux: /etc/init.d/novell-idp restart

Windows:

net stop Tomcat7

net start Tomcat7

Modifying a WS Federation Service Provider

This section explains how to modify a WS Federation service provider after it has been created. Creating a Service Provider for WS Federation explains the steps required to create the service provider. You can modify the following configuration details:

Renaming the Service Provider

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Service Provider].

  2. In the Name field, specify a new name for the service provider.

  3. Click OK twice, then update the Identity Server.

Configuring the Attributes Sent with Authentication

When the Identity Server creates its response for the service provider, it uses the attributes listed on the Attributes page. The response needs to contain the attributes that the service provider requires. If you do not own the service provider, you need to contact the administrator of the service provider and negotiate which attributes you need to send in the response. The service provider can then use these attributes to identify the user, to create policies, to match user accounts, or if it allows provisioning, to create a user account on the service provider.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Attributes.

  2. (Conditional) To create an attribute set, select New Attribute Set from the Attribute Set drop-down menu.

    An attribute set is a group of attributes that can be exchanged with the trusted provider. For example, you can specify that the local attribute of any attribute in the Liberty profile (such as Informal Name) matches the remote attribute specified at the service provider.

    1. Specify a set name, then click Next.

    2. On the Define Attributes page, click New.

    3. Select a local attribute.

    4. Specify the name of the remote attribute.

    5. For the namespace, specify http://schemas.xmlsoap.org/claims.

    6. Click OK.

    7. To add other attributes to the set, repeat Step 2.b through Step 2.e.

    8. Click Finish.

  3. Select an attribute set.

  4. Select attributes that you want to send from the Available list, and move them to the left side of the page.

  5. (Conditional) If you created a new attribute set, it must be enabled for STS.

    For more information, see Enabling the Attribute Set.

  6. Click OK, then update the Identity Server.

Modifying the Authentication Response

When the Identity Server sends its response to the service provider, the response can contain an identifier for the user. If you do not own the service provider, you need to contact the administrator of the service provider and negotiate whether the user needs to be identified and how to do the identification. If the service provider is going to use an attribute for user identification, that attribute needs to be in the attributes sent with authentication. See Configuring the Attributes Sent with Authentication.

To select the user identification method to send in the response:

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Authentication Response.

  2. For the format, select one of the following:

    Unspecified: Specifies that the SAML assertion contains an unspecified name identifier.

    E-mail: Specifies that the SAML assertion contains the user’s e-mail address for the name identifier.

    X509: Specifies that the SAML assertion contains an X.509 certificate for the name identifier.

  3. For the value, select an attribute that matches the format. For the Unspecified format, select the attribute that the service provider expects.

    The only values available are from the attribute set that you have created for WS Federation.

  4. To specify that this Identity Server must authenticate the user, disable the Use proxied requests option. When the option is disabled and the Identity Server cannot authenticate the user, the user is denied access.

    When this option is enabled, the Identity Server checks to see if other identity providers can satisfy the request. If one or more can, the user is allowed to select which identity provider performs the authentication. If a proxied identity provider performs the authentication, it sends the response to the Identity Server. The Identity Server then sends the response to the service provider.

  5. Click OK twice, then update the Identity Server.

Viewing the WS Service Provider Metadata

You can view the metadata of the ADFS server, edit it, and view information about the signing certificate.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Metadata.

    The following values need to be configured accurately:

    ID: This is provider ID. This is the value that the ADFS server provides to the Identity Server in the realm parameter of the query string. This value is specified in the Properties of the Trust Policy page on the ADFS server. The parameter label is Federation Service URI. The default value is urn:federation:treyresearch.

    sloUrl: This is the sign-on URL. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL. The default value is https://adfsresource.treyresearch.net/adfs/ls/.

    ssoUrl: This is the logout URL. The default value is https://adfsresource.treyresearch.net/adfs/ls/. The ADFS server makes no distinction between the login URL and the logout URL.

    If the values do not match the ADFS values, you need to edit the metadata.

  2. To edit the metadata, click Edit. For configuration information, see Editing the WS Service Provider Metadata.

  3. To view information about the signing certificate, click Certificates.

  4. Click OK twice.

Editing the WS Service Provider Metadata

You can view the metadata of the ADFS server and edit metadata.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Metadata > Edit.

  2. Configure the following fields:

    Provider ID: This is provider ID. This is the value that the ADFS server provides to the Identity Server in the realm parameter of the query string. This value is specified in the Properties of the Trust Policy page on the ADFS server. The parameter label is Federation Service URI. The default value is urn:federation:treyresearch.

    Sign-on URL: This is the sloUrl. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL. The default value is https://adfsresource.treyresearch.net/adfs/ls/.

    Logout URL: This is the ssoUrl. The default value is https://adfsresource.treyresearch.net/adfs/ls/. The ADFS server makes no distinction between the login URL and the logout URL.

  3. If you need to import a new signing certificate, click Browse and follow the prompts.

  4. To view information about the signing certificate, click Certificates.

  5. Click OK twice, then update the Identity Server.

Configuring STS Attribute Sets

Use the Attribute Set page to select the attribute set or sets that contain attributes the STS can provide to a relying party. An attribute set must be created before you can select it.

When creating an attribute set for the STS, you need to know which protocol you are going to use for the attribute set and select the attributes and namespace appropriate for the protocol.

  1. In the Administrations Console, click Devices > Identity Servers > Edit > WS Federation > STS Attribute Sets.

  2. To select a set, move the set from the Available attribute sets list to the Attribute sets list.

    WS Federation: There is no default attribute set for WS Federation. For information about how to create the set, see Configuring the Attributes Obtained at Authentication and Configuring the Attributes Sent with Authentication.

  3. Click OK, then update the Identity Server if you have changed the configuration.

Configuring STS Authentication Methods

Use the Authentication Methods page to select the methods that can be used for authentication at the STS. The methods determine the credentials the user must supply for authentication and the user store that is used to verify the credentials. The WS Federation protocol does not use methods for authentication.

  1. In the Administrations Console, click Devices > Identity Servers > Edit > WS Federation > STS Authentication Methods.

  2. To enable a method, move the method from the Available methods list to the Methods list.

    All the methods that you have defined for the Identity Server appear in the Available methods list, but the only default method that works is the Secure Name/Password-Form method. It has been extended so that it knows how to extract name and password information from a managed card that is not backed by a personal card. You can use the Secure Name/Password-Form class to create additional methods for specific user stores.

    You can also create a custom method, if required. For information, see NetIQ Access Manager Developer Tools and Examples.

  3. Click OK, then update the Identity Server if you have changed the configuration.

Configuring STS Authentication Request

Use the Authentication Request page to select the format for the name identifier that is returned in the SAML assertion. The selected attribute sets determine the values that are available for the formats. If you select a format but do not specify a value, a unique value is generated.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS Federation > STS Authentication Request.

  2. Select one of the following:

    None: Indicates that the SAML assertion does not contain a name identifier.

    Unspecified: Specifies that the SAML assertion contains an unspecified name identifier. For the value, select the attribute that the relying party and the identity provider have agreed to use.

    E-mail: Specifies that the SAML assertion contains the user’s e-mail address for the name identifier. For the value, select an e-mail attribute.

    X509: Specifies that the SAML assertion contains an X.509 certificate for the name identifier. For the value, select an X.509 attribute.

  3. Click OK, then update the Identity Server if you have changed the configuration.

5.2.9 Configuring WS-Trust Security Token Service

This section describes WS-Trust Security Token Service (WS-Trust STS) and how to configure it. Topics include:

Overview

Web services are software applications that interact over network by using the Hyper Text Transfer Protocol (HTTP). World Wide Web Consortium (W3C) describes Web services as a standard means of interoperating between software applications running on a variety of platforms and frameworks. A Web service provides a fine-grained service to its client.

Web services use network for communication and data exchange spanning from protected network (intranet) to unprotected network (internet). This demands for security requirements such as client authentication, access control, data integrity, and confidentiality.

You can secure Web services and protect your information against authentication attacks and unauthorized access by using security tokens. A security token contains a set of claims made by a client that includes details such as a user name, password, identity, key, and certificate.

NetIQ Access Manager addresses the need for a secure token mechanism through WS-Trust STS that is based on the WS-Trust protocol. WS-Trust is built on top of the WS-Security specification. It enables Web applications to construct trusted SOAP message exchanges.

WS-Trust STS provides secure communication and integration between services. It issues and validates security tokens to establish trust relationships between a Web service client and a Web service provider. If the requestor (Web service client) does not have the necessary token to provide required claims to a service, it contacts WS-Trust STS and requests the needed tokens with proper claims. WS-Trust STS may in turn require its own set of claims for authenticating and authorizing the request for security tokens.

How WS-Trust STS Works

WS-Trust STS allows secure identity propagation and token exchange between Web services. It provides a standard framework for requesting and returning security tokens by using Request Security Token (RST) and Request Security Token Response (RSTR) messages. RST provides the means for requesting a security token from WS-Trust STS. RSTR contains the requested token, claims, and other related information.

The Web service client provides its credentials to WS-Trust STS and gets a SAML token from WS-Trust STS. A trust is established between the Web service provider and WS-Trust STS. The Web service client presents the token from WS-Trust STS to the Web service provider. The Web service provider validates if the token has been issued from WS-Trust STS and grants access to the required service.

The following diagram illustrates an example of how WS-Trust STS facilitates a secure communication between a Web service client and a Web service provider through security tokens:

WS-Trust STS is designed to interoperate with many different Web Service environments and supports SOAP and WS-Trust specifications.

Web services must implement the protocol defined in the WS-Trust 1.3 or 1.4 specification by making assertions based on evidence that it trusts, to whoever trusts it, or to specific recipients. For more information about WS-Trust specification, see WS-Trust 1.3 Specification and WS-Trust 1.4 Specification.

The following table lists supported SOAP and WS-Trust versions and corresponding namespaces:

Specification

Version

Namespace

Soap

1.1

http://schemas.xmlsoap.org/soap/envelope/

 

1.2

http://www.w3.org/2003/05/soap-envelope

WS-Trust

1.3

http://docs.oasis-open.org/ws-sx/ws-trust/200512/

1.4

http://docs.oasis-open.org/ws-sx/ws-trust/200802

NOTE:

  • WS-Trust STS supports SAML tokens in addition to usernametokens.

    WS-Trust STS can issue both SAML 1.1 and SAML 2.0 based tokens.

  • WS-Trust STS supports issuing, validating and renewing tokens. This release does not support canceling tokens.

  • Web service clients and Web service providers should be in the same domain. This release does not support multiple domains.

  • By default, the SAML tokens are line wrapped for all the protocols. To disable line wrapping, add the following line in the /opt/novell/nam/idp/conf/tomcat7.conf file: JAVA_OPTS="${JAVA_OPTS} -Dorg.apache.xml.security.ignoreLineBreaks= true. Restart Identity Server.

Benefits

WS-Trust STS offers the following benefits:

  • Enables the secure exchange of SOAP messages among Web services.

  • Facilitates identity delegation (through ActAs) and impersonation (through OnBehalfOf) where an authenticated user is granted access to downstream Web services.

  • Reduces complexity for the Web service consumer as the Web service consumer does not need token specific knowledge.

Scenarios

This section describes the basic scenarios supported by WS-Trust STS.

Scenario 1: Web Service Client Communicating with Token Protected Web Service Provider

In this scenario, a Web service client situated outside the enterprise tries to access a Web service provider hosted inside the enterprise.

This process consists of requesting a token by means of the request-response message pairs of a Request Security Token (RST) and a Request Security Token Response (RSTR). The tokens are included in SOAP messages.

The following diagram illustrates this scenario:

  1. A Web service client, which is outside the enterprise, sends its credentials to WS-Trust STS and request for the security token through RST.

  2. WS-Trust STS verifies the client’s credentials and then issues a security token (SAML token) through RSTR.

    The Web service client caches the security token and then uses it in multiple requests to the Web service provider.

  3. The Web service client presents the token to the Web service provider.

  4. The Web service provider validates the token and sends the response to the Web service client.

Scenario 2: Web Single Sign-On and STS

In this scenario, a Web service client that resides as part of a Web application within an enterprise tries to access services from other Web service providers of the same enterprise. A user named Alice accesses to the Web application through a browser and needs single sign-on access to other applications.

  1. A Web application sends a single sign-on authentication request to WS-Trust STS on behalf of Alice.

    The Web application is residing within the enterprise.

  2. The Web application passes the credentials corresponding to the single sign-on session to the Web service client.

  3. The Web service client requests for security token by using the passed on credentials.

  4. WS-Trust STS verifies the credentials. After checking the credentials, it verifies if the Web service provider for which the token has been requested for is a trusted service provider. Then it issues a security token consumable by the service provider.

  5. The Web service client residing within the Web application presents the token to the Web service provider. The Web service client caches the security token and then uses it in multiple requests to the Web service provider.

  6. The Web service provider validates the token and sends the response to the Web service client residing within the Web application.

The tokens are included in SOAP messages.

Scenario 3: Identity Delegation and Impersonation

In this scenario, a Web service provider requests services from other Web service providers.

The following use-case explains this scenario:

There are two Web service providers called Service1 and Service2 providing some fine-grained service. Both Service1 and Service2 require authentication and trust WS-Trust STS. A Web service client tries to access Service1 and requests for the service. To fulfill the request, Service1 needs to access the service of Service2. Service1 can request a token from WS-Trust STS to access Service2. This exchange of information happens through security tokens embedded in SOAP messages.

This chaining of service request can be any number of nodes based on the implementation.

Requests for tokens can be made in two ways:

  • By using the ActAs element (Identity Delegation): The ActAs element is used for delegated requests. Delegated scenarios require composite delegation, where the final recipient of the issued token can see the entire delegation chain. ActAs is commonly used in multi-tiered systems to authenticate and pass information about identities between the tiers without having to pass this information at the application or business logic layer.

  • By using the OnBehalfOf element (Impersonation): The OnBehalfOf element is used for proxy requests. OnBehalfOf is used when the identity of only the original client is important. The final recipient of the issued token can only see claims about the original client. The information about intermediaries is not preserved.

The following diagram illustrates the workflow:

The following workflow explains the ActAs scenario:

  1. The Web service client sends a RST to WS-Trust STS for its authentication.

  2. WS-Trust STS returns a SAML token to the client in the RSTR. Let us refer to this SAML token as token1. The subject of this SAML token is client.

  3. The client forwards the token1 with its SOAP request to Service1.

  4. Then Service1 sends a RST to WS-Trust STS again authenticating itself to the STS. This time the RST contains the token1 inside the ActAs element.

  5. WS-Trust STS issues a SAML token (referred to as token2). The subject of this token is Service1. It contains an attribute called ActAs with the value of client.

  6. Service1 sends token2 to Service2. By processing token2, Service2 understands that the original requester is client and Service1 is acting as the original requester.

  7. Service2 sends the response to Service1.

  8. Service1 forwards the response to the client.

The following workflow explains the OnBehalfOf scenario:

  1. The Web service client sends a RST to WS-Trust STS for its authentication.

  2. WS-Trust STS returns a SAML token to the client in the RSTR. Let us refer to this SAML token as token1. The subject of this SAML token is client.

  3. The client forwards the token1 with its SOAP request to Service1.

  4. Then Service1 sends a RST to WS-Trust STS again authenticating itself to the STS. This time the RST contains the token1 inside the OnBehalfOf element.

  5. WS-Trust STS issues a SAML token (referred to as token2). The subject of this token is client.

  6. Service1 sends token2 to Service2. Service2 understands that the original requester is client but cannot see the details of Service1.

  7. Service2 sends the response to Service1.

  8. Service1 forwards the response to the client.

IMPORTANT:Starting from Access Manager 4.0 SP1 release, the default binding supported is SOAP 1.2. If you want to use SOAP 1.1 instead, perform the following steps on all instances of the Identity Server:

  1. Traverse to the /opt/novell/nam/idp/webapps/nidp/WEB-INF folder and edit the sun-jaxws.xml file.

  2. Remove all instances of bindings from the endpoints in the sun-jaxws.xml file and save the changes. A binding is represented by the following line in this file:

    binding="http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/"

  3. Restart the Identity Server using the /etc/init.d/novell-idp restart command.

Renewing a Token

The renew token operation helps in renewing a token issued by WS-Trust Security Token Service(STS). Only a token that is issued by an Identity Server that is part of the same cluster can be renewed. Tokens issued by a different Identity Server in a different cluster or by a third-party STS cannot be renewed.

Each token generated by the STS is valid for the duration specified using the Token Lifetime setting. A token can be renewed only before lapse of the expiry period. For example: if the Token Lifetime has been specified as 180 seconds, token renew operation will succeed only till the 179th second.

Workflow:

  1. The Web service client sends a RST to WS-Trust STS for its authentication and WS-Trust STS returns a SAML token to the client in the RSTR

  2. Web Service Provider uses the SAML token from STS and requests access to resources hosted on the Web Service provider.

  3. The Web Service Provider validates the SAML token and provides access to the resources.

  4. When the token is nearing expiry, the Web service client sends a RST to WS-Trust STS to renew the token previously issued. The STS renews the validity of the token and sends a renewed token to the Web Service client for any further requests.

  5. Web Service client uses the renewed SAML token from STS and requests access to resources hosted on the Web Service provider.

Authentication by Using SAML Tokens

WS-Trust STS accepts SAML tokens issued by a third-party STS for authentication. The tokens can be in SAML 1.1 or SAML 2.0.

Workflow:

  1. The Web service client sends a RST to third-party STS. The third-party STS returns a SAML token to the client in the RSTR.

  2. The Web Service client uses SAML token issued by the third-party STS and requests WS-Trust STS to grant access to resources hosted on the Web Service Provider.

  3. WS-Trust STS authenticates the client using the third-party SAML token and issues a new SAML token.

  4. The Web Service client uses this new SAML token to get access to resources hosted on the Web Service Provider.

  5. The Web Service Provider validates the SAML token with WS-Trust STS.

  6. The Web Service client can access the resources on the Web Service Provider if the SAML token is valid.

Configuring WS-Trust STS

Before a Web service can invoke operations on STS, you must enable WS-Trust and configure it in Access Manager. This section discusses the following topics:

Enabling WS-Trust

Access Manager ships with only SAML 1.1, Liberty, and SAML 2.0 enabled by default. To use the WS-Trust protocol, you must enable it on the Identity Server.

To enable WS-Trust, perform the following steps:

  1. In the Administration Console, click Devices > Identity Servers > Edit.

  2. In the Enabled Protocols section, select WS-Trust.

  3. Click OK.

  4. Update the Identity Server.

Configuring Access Manager for WS-Trust STS

To configure WS-Trust STS, perform the following steps:

  1. In the Administration Console, click Devices > Identity Servers > Edit.

  2. Select WS-Trust > STS Configuration.

  3. Specify the following details:

    Token Lifetime: Specify the duration in seconds for which the token is valid. The default value is 360 seconds.

    Token Issuer: Specify the name of the issuer of the authentication token.

    Authentication Methods: Select methods that can be used for authentication at STS for WS-Trust.

    Select and move methods from Available Authentication Methods to Selected Authentication Methods.

    Tokens: Select the type of tokens that can be issued for authentication at STS for WS-Trust. SAML 1.1 and SAML 2.0 tokens are supported. If you select both token types, the token type configured in the service provider is returned.

  4. Click Apply.

Viewing STS Service Details

EndPoint URL is the SOAP endpoint of STS. The Web service client and Web service provider must be configured to these endpoints.

In the Administration Console under Devices > Identity Servers > Edit > WS-Trust > EndPoint Summary, you can view the following STS EndPoint details:

Service Name: The name of the STS service endpoint that is configured in the Web service client.

Port Name: The port that STS implements. This is configured in the Web service client.

MEX EndPoint URI: The MetadataExchange endpoint of STS.

WSDL of STS Username authentication: WSDL location for username authentication. This file is used by applications that use the token service with username authentication.

WSDL of STS SAML authentication: WSDL location for SAML. This file is used by applications that use the token service with SAML authentication.

Configuring Service Providers

You require to configure Web service providers to accept tokens issued by an STS. The Web service provider uses an IssuedToken policy for the same. The IssuedToken policy is wrapped in WSDL. For a sample policy, see A Sample WS-Policy for Web Service Providers.

Configuring a service provider includes adding a service provider domain and then adding a service provider in a configured domain. Access Manager also allows you to modify and delete configured service provider domains and service providers.

Adding a Domain and Assigning WS-Trust Operations

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS-Trust > Service Provider Domain.

  2. Click New > General to create a general domain. Selecting New > Office 365 creates an Office 365 domain that can be configured for active authentication. For details on creating an Office 365 domain, see Configuring an Office 365 Domain By Using WS-Trust Protocol

  3. Specify the following details:

    Name: Specify a name for the domain.

    WS-Trust Operations: Select operations in Available operations that WS-Trust STS performs for tokens and move these to Selected operations.

    The available operations are Issue, Validate, OnBehalfOf, ActAs and Renew.

    If you select OnBehalfOf and Act As the Available operations, additional configuration is required. For more information, see Adding Policy for ActAs and OnBehalfOf

  4. Click Finish. Continue with creation of a trusted Service Provider. For more information, see Adding Web Service Providers

Adding Web Service Providers

This section discusses how to add service providers for WS-Trust STS. Adding a service provider includes adding service provider EndPoint URL, configuring trust certificates, selecting token types, and customizing attributes.

Perform the following steps:

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS-Trust > Service Provider Domain.

  2. Select the domain under which you want to configure a service provider.

  3. Click Service Provider > New.

  4. Specify the following details:

    Name: Specify a name for the service provider.

    Endpoint: Specify the SOAP endpoint location at the service provider to which SOAP messages are sent.

    Token Type: Select the type of token that the service provider will accept or validate.

    Encrypt Proof Token Using: Import a certificate from the file system or paste content of the certificate here. This certificate should be configured in the Web service provider and is used for creating the subject confirmation in the SAML token.

  5. Click Finish.

  6. Select the Service Provider to define the Attributes and Authentication Response. For more information, see Modifying Service Providers

Enabling Delegation and Impersonation

By default, ActAs and OnBehalfOf requests are disabled in the Access Manager Identity Server. To enable delegation and impersonation, you must enable ActAs and OnBehalfOf by performing the following steps:

  1. Go to WS-Trust > Service Provider Domain.

  2. Click the service provider domain name for which you want to enable ActAs and OnBehalfOf operations.

  3. Under WS Trust Operations, select ActAs and OnBehalfOf in Available operations and move to Selected operations.

  4. Click OK.

These operations are restricted to a set of privileged user accounts defined in the policy. You need to configure the allowed user accounts, who can perform ActAs and OnBehalfOf operations, in the nidconfig.properties file of each Identity Server installation. For more information, see Adding Policy for ActAs and OnBehalfOf

Configuring ActAs to Lookup Multiple User Stores

For ActAs, the username on behalf of whom a client requests for a token must be present in the user store (eDirectory). The default implementation checks for this user only in the default user store. If you want to search the user in a different user store, perform the following steps:

  1. In the Administration Console, click Devices > Identity Server > Edit > Local > Classes.

  2. Click New and specify the following details:

    Display name: Specify Find_By_Username

    Java class: Select Other

    Java class path: Specify com.novell.nidp.authentication.local.UserNameAuthenticationClass

  3. Click Next > Finish.

  4. Go to Local > Methods.

  5. Click New and select the Find_By_Username class.

    For more information about how to configure an authentication method, see Section 5.1.3, Configuring Authentication Methods.

  6. Go to WS-Trust > STS Configuration. Move this authentication method in the Selected Authentication Methods from Available Authentication Methods.

Adding Policy for ActAs and OnBehalfOf

You must add an policy to allow ActAs and OnBehalfOf operations. The default policy looks for a configuration of allowed user names from the nidpconfig.properties file. Allowed usernames are the user accounts that the intermediate Web service provider uses to authenticate with STS when sending a request with ActAs or OnBehalfOf elements.For ActAs and OnBehalfOf, you must specify multiple username values separated with comma. If no value is specified, ActAs and OnBehalfOf are denied.

The nidpconfig.properties file is located in the following location:

Linux: /opt/novell/nids/lib/webapp/WEB-INF/classes.

Windows: C:\Program Files (x86)\Novell\Tomcat\webapps\nidp\WEB-INF\classes

Enable the following attribute by removing the pound (#) symbol from it for allowing ActAs:

WSTRUST_AUTHORIZATION_ALLOWED_ACTAS_VALUES=alice,admin

Enable the following name-value pair by removing the pound (#) symbol from it for allowing OnBehalfOf:

WSTRUST_AUTHORIZATION_ALLOWED_ONBEHALF_VALUES=bob,admin

To simplify parameters, you can define only the following parameter:

WSTRUST_AUTHORIZATION_ALLOWED_VALUES=alice,admin

These users can perform both Actas and onBehalfOf operations.

After editing the file, restart the Identity Server by running the following command:

Linux: /etc/init.d/novell-idp restart

Windows: net stop Tomcat7

net start Tomcat7

After upgrading Access manager, the configuration is set to default values. You must reconfigure the details after each upgrade.

Managing Service Provider Domains

The WS-Trust page allows you to create, modify, and delete service provider domains. This page lists all configured service provider domains.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS-Trust > Service Provider Domains.

    The list of all configured service provider domains is displayed.

  2. Select one of the following actions:

    • New: Select New > General to create a general domain. Selecting New > Office 365 creates a domain that can be configured for single sign-on to Office 365 services. For more on creating Office 365 domain, see Adding a Domain and Assigning WS-Trust Operations.

    • Delete: Deletes the selected service provider domain.

  3. Click OK, then update the Identity Server.

  4. Select the Service Provider domain to modify the following details:

    • Name: Modify the name of the service provider domain.

    • WS Trust Operations: Modify the list of selected WS-Trust operations.

  5. Click OK.

Managing Service Providers

Access Manager allows you to you to create, modify, and delete trusted service providers. The Service Providers page lists all configured service provider.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS-Trust> Service Provider Domains> [name of the service provider domain] > Service Providers.

    The list of all configured service provider for the selected domain is displayed.

  2. Select one of the following actions:

    • New: Launches the Create a Service Provider page. For more information, see Adding Web Service Providers.

    • Delete: Deletes the selected service providers.

  3. Click OK.

Modifying Service Providers

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS-Trust> Service Provider Domains> [name of the service provider domain] > Service Providers.

    The list of all configured service provider for the selected domain is displayed.

  2. Click the name of the service provider you want to edit.

    Configuration > Trust

    You can modify the following details:

    Configuration > Attributes

    • Select the Attribute Set and move attributes from the Available list to the Send with Authentication pane. This indicates the attributes that you want sent in an assertion to the service provider.

    Configuration > Authentication Response

    • Specify a value for the name identifier.

      • The persistent and transient formats are generated automatically. For the others, you can select an attribute. The available attributes depend upon the attributes that you have selected to send with authentication (see Configuring the Attributes Obtained at Authentication). If you do not select a value for the E-mail, Kerberos, X509, or Unspecified format, a unique value is automatically generated.

        IMPORTANT:In Access Manager 4.0 SP1, the SAML tokens with Name Identifier value other than username do not support ActAs, OnBehalfOf and SAML authentication operations.

  3. Click Apply.

A Sample WS-Policy for Web Service Providers

You should modify WSDL of a Web service provider to include IssuedTokenPolicy that points to Access Manager WS-Trust STS. To modify WSDL, you require to add a WS-Policy with IssuedTokenElement. The following is a sample configuration:

<wsp:Policy wsu:Id="<policy_name>">
        <wsp:ExactlyOne>
            <wsp:All>
                <wsaws:UsingAddressing xmlns:wsaws="http://www.w3.org/2006/05/addressing/wsdl" wsp:Optional="false"/>
                <sc:KeyStore wspp:visibility="private" alias="xws-security-server"/>
                <sp:SymmetricBinding>
                    <wsp:Policy>
                        <sp:ProtectionToken>
                            <wsp:Policy>
                                <sp:IssuedToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                                    <sp:RequestSecurityTokenTemplate>
                                        <t:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</t:TokenType>
                                        <t:KeyType>http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</t:KeyType>
                                        <t:KeySize>256</t:KeySize>
                                    </sp:RequestSecurityTokenTemplate>
                                    <wsp:Policy>
                                        <sp:RequireInternalReference/>
                                    </wsp:Policy>
                                    <sp:Issuer>
                                        <wsaws:Address>https://namtest.com:8443/nidp/wstrust/sts</wsaws:Address>
                                        <wsaws:Metadata>
                                            <wsx:Metadata>
                                                <wsx:MetadataSection>
                                                    <wsx:MetadataReference>
                                                        <wsaws:Address>https://namtest.com:8443/nidp/wstrust/sts/mex</wsaws:Address>
                                                    </wsx:MetadataReference>
                                                </wsx:MetadataSection>
                                            </wsx:Metadata>
                                        </wsaws:Metadata>
                                    </sp:Issuer>
                                </sp:IssuedToken>
                            </wsp:Policy>
                        </sp:ProtectionToken>
                        <sp:Layout>
                            <wsp:Policy>
                                <sp:Lax/>
                            </wsp:Policy>
                        </sp:Layout>
                        <sp:IncludeTimestamp/>
                        <sp:OnlySignEntireHeadersAndBody/>
                        <sp:AlgorithmSuite>
                            <wsp:Policy>
                                <sp:Basic128/>
                            </wsp:Policy>
                        </sp:AlgorithmSuite>
                    </wsp:Policy>
                </sp:SymmetricBinding>
                <sp:Wss11>
                    <wsp:Policy>
                        <sp:MustSupportRefIssuerSerial/>
                        <sp:MustSupportRefThumbprint/>
                        <sp:MustSupportRefEncryptedKey/>
                    </wsp:Policy>
                </sp:Wss11>
                <sp:Trust10>
                    <wsp:Policy>
                        <sp:MustSupportIssuedTokens/>
                        <sp:RequireClientEntropy/>
                        <sp:RequireServerEntropy/>
                    </wsp:Policy>
                </sp:Trust10>
            </wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>

Configuring Web Service Clients

Access Manager WS-Trust STS can be accessed from various Web service clients. The following sections provide example configurations and sample code snippets for CXF-based and Metro-based Web service clients:

Configuring Apache CXF-based Web Service Clients

You can configure CXF-based Web service clients either programmatically or through XML configuration files. Below is a sample XML configuration. Add the following features to cxf.xml under the top-level beans section:

<cxf:bus>
    <cxf:features>
      <cxf:logging />
      <wsa:addressing />
    </cxf:features>
  </cxf:bus>

Define the STS client with its properties as follows:

<jaxws:client name="{<your webservice target namespace>}WebServicePort"
    createdFromAPI="true">
    <jaxws:properties>
<entry key="ws-security.sts.client">
        <bean class="org.apache.cxf.ws.security.trust.STSClient">
          <constructor-arg ref="cxf" />
          <property name="wsdlLocation"
            value="https://<your idp base url>nidp/wstrust/sts?wsdl" />
          <property name="serviceName" value="{http://www.netiq.com/nam-4-0/wstrust}SecurityTokenService" />
          <property name="endpointName" value="{http://www.netiq.com/nam-4-0/wstrust}STS_Port" />
    
          <property name="wspNamespace" value="http://schemas.xmlsoap.org/ws/2004/09/policy" />
          <property name="properties">
            <map>
              <entry key="ws-security.username" value="<username to connect to idp>" />
              <entry key="ws-security.password" value="<password>" />
              <entry key="ws-security.encryption.properties" value="clientKeystore.properties" />
              <entry key="ws-security.encryption.username" value="mystskey" />
              <entry key="soap.force.doclit.bare" value="true" />
              <entry key="soap.no.validate.parts" value="true" />
            </map>
          </property>
        </bean>
      </entry>
</jaxws:clien>

You can configure ws-security.callback-handler to provide username and password programmatically. You can also configure global sts-client in cxf.xml that can be used across multiple Web services.

For more information about configuring Apache CXF-based Web service clients, see Apache CXF.

Configuring Metro-based Web Service Clients

You can configure Metro-based clients through NetBeans (an integrated development environment).

  1. Create a Web service client project in NetBeans.

  2. Right click the project and click Create Web Service Client to create a STS client. Point the WSDL to http://<name of the identity provider server>:<port>/nidp/wstrust/sts?wsdl.

  3. Configure the username and password to access WS-Trust STS.

    The user configured needs to get authenticated into Access Manager password-based authentication classes. You can also configure the Callback-based configuration in NetBeans to provide username and passwords dynamically.

  4. When you create a Web service client for your Web service, which is configured for STS-issued tokens, you need to specify the endpoint URL of WS-Trust STS in the Web service client properties. You can specify this in NetBeans by right clicking Web Service References> Web Service and selecting Secure Token Service.

For more information about configuring Metro-based Web service clients, see To Specify an STS on the Service Side and To Specify an STS on the Client Side in Configuring A Secure Token Service (STS).

Renew Token - Sample Request and Response

Renew Token - Sample Request

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <soap:Header>
      <Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Renew</Action>
      <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9cfedcee-2ebf-47e0-a24a-45281d785136</MessageID>
      <To xmlns="http://www.w3.org/2005/08/addressing">https://namsb.blr.novell.com:443/nidp/wstrust/sts</To>
      <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
         <Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
      </ReplyTo>
      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
         <wsu:Timestamp wsu:Id="TS-1">
            <wsu:Created>2014-02-10T23:36:42Z</wsu:Created>
            <wsu:Expires>2014-02-10T24:36:42Z</wsu:Expires>
         </wsu:Timestamp>
         <wsse:UsernameToken wsu:Id="UsernameToken-2">
            <wsse:Username>admin</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">novell</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soap:Header>
   <soap:Body>
      <wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Renew</wst:RequestType>
         <wst:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</wst:TokenType>
         <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:KeyType>
         <wst:Entropy>
            <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce">2O0dAaqhrBJqbouiQTf7D2pXtXRo36Wi/yswGeoq7iQ=</wst:BinarySecret>
         </wst:Entropy>
         <wst:RenewTarget>
            <saml2:Assertion ID="nstsa657b5f4-9bf0-45b7-9875-07eeb6d65196" IssueInstant="2014-05-26T10:33:50.564Z" Version="2.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns10="http://www.w3.org/2000/09/xmldsig#" xmlns:ns13="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ns3="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" xmlns:ns5="http://docs.oasis-open.org/ws-sx/ws-trust/200512/" xmlns:ns9="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" xmlns:sc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">
               <saml2:Issuer>https://namsb.blr.novell.com/nidp/wstrust/sts</saml2:Issuer>
               <ds:Signature>
                  <ds:SignedInfo>
                     <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                     <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                     <ds:Reference URI="#nstsa657b5f4-9bf0-45b7-9875-07eeb6d65196">
                        <ds:Transforms>
                           <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                           <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                        </ds:Transforms>
                        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                        <ds:DigestValue>Z3S4qxz2wRv0k5np2R6ENkIF9pk=</ds:DigestValue>
                     </ds:Reference>
                  </ds:SignedInfo>
                  <ds:SignatureValue>ZxeqeuD7NXfNRPiaYY3v2Nfo9vTx+ceASiAFBDzOfaWGczHBT0eYU+AQM99vdX1GCBCdWqO9qQR8
2WP71mzREC6ndg+8g/zJ6UH+Jzsf05hIxCAu7d7fg5qP5/BP++x8vUlpUQ32D8daxx+GIwuZjlOs
8KhdbgLReYSWyX6PV0UbjbnAtDFaBTTJ5lpEqHdK7FGUiISXg679o16BTJSs/V2bBOrX7cZGRGte
PMBGz19qX0rzoeNpLJFpJi23+/wAYaqzz0kyRGeyA0De0ugsqw2XRvUPciaYhbqqOraFUfmpyspC
o7ClzwsvnO1h1gVX/lDBwfLokrBeijsG3FN3Hg==</ds:SignatureValue>
                  <ds:KeyInfo>
                     <ds:X509Data>
                        <ds:X509Certificate>MIIFBDCCA+ygAwIBAgIkAhwR/6b9CQnrHMhxuBSYqOCbHugRb+e4U/9jWi9kAgIWCzKcMA0GCSqG
SIb3DQEBBQUAMDExGjAYBgNVBAsTEU9yZ2FuaXphdGlvbmFsIENBMRMwEQYDVQQKFApuYW1zYl90
cmVlMB4XDTE0MDUyMTE4NTQwMVoXDTI0MDUyMTE4NTQwMVowHzEdMBsGA1UEAxMUbmFtc2IuYmxy
Lm5vdmVsbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRTsdCFBM3ImpIyRAj
OdFFEYbC/ykQUEZFwGp62BAUxoLIOpmDZyxpbqIh+l462GFByuCvkLOhnelOGV6Ii/cTAbaHko7h
T7cfUC3N4kmhnc3IXWgjodRIXMlaUSYDYd79guyVjG0brOWJMxJxvm1eo3p8bFzPLnpkEdJ7c8HM
BRqckecaGT8nbpm1KGZFAStrRRTryu2aG670FP3+MHWZmydqLlvrK1NCfe+7DlpOUwA13sSgMslf
6UCI4E50gn6pQ26rctGKrBsFfrX76t6ESZuaqFlWS+YA11cWS3irtihT0p2GsoxcJzq+IvHosHY+
pvrt4gcJiZJN6P3e6yrrAgMBAAGjggIUMIICEDAdBgNVHQ4EFgQUpSkUiviZFQ7yIDLb9sJT+mZH
kngwHwYDVR0jBBgwFoAUfFLP7EF6tU2u2qquPNTvLDdV7e8wggHMBgtghkgBhvg3AQkEAQSCAbsw
ggG3BAIBAAEB/xMdTm92ZWxsIFNlY3VyaXR5IEF0dHJpYnV0ZSh0bSkWQ2h0dHA6Ly9kZXZlbG9w
ZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJpYnV0ZXMvY2VydGF0dHJzX3YxMC5odG0wggFI
oBoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaEaAQEAMAgwBgIBAQIBADAIMAYCAQECAQACAQCi
BgIBFwEB/6OCAQSgWAIBAgICAP8CAQADDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADAYMBACAQAC
CH//////////AQEAAgQG8N9IMBgwEAIBAAIIf/////////8BAQACBAbw30ihWAIBAgICAP8CAQAD
DQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQR/6b9MBgwEAIB
AAIIf/////////8BAQACBBH/pv2iTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAA
AAAAMBIwEAIBAAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUF
AAOCAQEAbA0AdHm5pV6cEwSyOoB3aJfaLegMYPlAuTNK9ajhez9PIHPGSQzNxTRbj3eV9P+ueP7j
i8AFVR3Ej4eA7S1i5kPGuSXhwM6VhSIsCn+x+HbpnFdWJdu5EvErjTIbbjRU/4wTRCqKe7loFqKs
rH+BGNuUJw16l2PM+wJ+sajX7ktzP8rk8CF+cTOe8ggFcEuJ4igl1MMkVbul1RTggRmpcILNFk57
QdmySozjVok1OVQOzIGcAggPBSZeCumNNP8mQIAmvnwWG0cTvDIkMkCV1AzCC0WK0dWM53JZD/aa
tHay9w8QWoUU5cJo8B+uSm2vN+53PdtMKWOXhJcXtXpKKg==</ds:X509Certificate>
                     </ds:X509Data>
                  </ds:KeyInfo>
               </ds:Signature>
               <saml2:Subject>
                  <saml2:NameID NameQualifier="">admin</saml2:NameID>
                  <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
               </saml2:Subject>
               <saml2:Conditions NotBefore="2014-05-26T10:33:50.564Z" NotOnOrAfter="2014-05-26T10:35:50.564Z">
                  <saml2:AudienceRestriction>
                     <saml2:Audience>http://164.99.184.228:8080/doubleit/services/doubleit</saml2:Audience>
                  </saml2:AudienceRestriction>
               </saml2:Conditions>
               <saml2:Advice/>
               <saml2:AuthnStatement AuthnInstant="2014-05-26T10:33:50.564Z">
                  <saml2:AuthnContext>
                     <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:1.0:am:password</saml2:AuthnContextClassRef>
                  </saml2:AuthnContext>
               </saml2:AuthnStatement>
               <saml2:AttributeStatement>
                  <saml2:Attribute AttributeName="emailaddress" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims" Name="emailaddress" NameFormat="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
                     <saml2:AttributeValue>admin@idp.com</saml2:AttributeValue>
                  </saml2:Attribute>
               </saml2:AttributeStatement>
            </saml2:Assertion>
         </wst:RenewTarget>
      </wst:RequestSecurityToken>
      <ns:RequestSecurityToken xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"/>
   </soap:Body>
</soap:Envelope>

Renew Token - Sample Response

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <S:Header>
      <Action S:mustUnderstand="true" xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/RenewFinal</Action>
      <MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:f41d7aeb-6f67-4df3-9fe4-e160889b7efb</MessageID>
      <RelatesTo xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9cfedcee-2ebf-47e0-a24a-45281d785136</RelatesTo>
      <To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
      <wsse:Security S:mustUnderstand="true">
         <wsu:Timestamp wsu:Id="_1" xmlns:ns15="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:ns14="http://schemas.xmlsoap.org/soap/envelope/">
            <wsu:Created>2014-05-26T10:35:41Z</wsu:Created>
            <wsu:Expires>2014-05-26T10:40:41Z</wsu:Expires>
         </wsu:Timestamp>
      </wsse:Security>
   </S:Header>
   <S:Body>
      <trust:RequestSecurityTokenResponse xmlns:ns10="http://www.w3.org/2000/09/xmldsig#" xmlns:ns13="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ns3="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd" xmlns:ns5="http://docs.oasis-open.org/ws-sx/ws-trust/200512/" xmlns:ns9="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" xmlns:sc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
         <trust:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</trust:TokenType>
         <trust:RequestedSecurityToken>
            <saml2:Assertion ID="nstsa657b5f4-9bf0-45b7-9875-07eeb6d65196" IssueInstant="2014-05-26T10:35:41.072Z" Version="2.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
               <saml2:Issuer>https://namsb.blr.novell.com/nidp/wstrust/sts</saml2:Issuer>
               <ds:Signature>
                  <ds:SignedInfo>
                     <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                     <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                     <ds:Reference URI="#nstsa657b5f4-9bf0-45b7-9875-07eeb6d65196">
                        <ds:Transforms>
                           <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                           <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                        </ds:Transforms>
                        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                        <ds:DigestValue>bX5LSfro0HkupLsMkU/V+x39P+g=</ds:DigestValue>
                     </ds:Reference>
                  </ds:SignedInfo>
                  <ds:SignatureValue>QLRRXQ4TzTgM9mVa5UF1p7YRqRvLP/h3pyP0KVzZXcbCfDmtT4bO14lqfhNoXL+Ym2iu2V1MIC5I
TRSt6D/y6pfs4/nChMrOuk5spMZYLBee+0PdlGYhfLGzyh/AONZGsoVrHf1/LItMeTp4MVmk/hTp
8yTWb0r79Ssz5TEbwJ/NkqFXxa9XffheaTySOfNXQYu3tL1rdp7Zaq5BR7mye00huo6gBTshHTXM
fGPYMu/Sy0kapqTBWHUbwt8FzysBEgELZdquhuvt1NOfHqkWAbyp5vExjjrYxl06Z7Fu3LnDSq+m
hI9S+VLs1bBR2XgNofhw/bFVBboYkzZDT6Ipmg==</ds:SignatureValue>
                  <ds:KeyInfo>
                     <ds:X509Data>
                        <ds:X509Certificate>MIIFBDCCA+ygAwIBAgIkAhwR/6b9CQnrHMhxuBSYqOCbHugRb+e4U/9jWi9kAgIWCzKcMA0GCSqG
SIb3DQEBBQUAMDExGjAYBgNVBAsTEU9yZ2FuaXphdGlvbmFsIENBMRMwEQYDVQQKFApuYW1zYl90
cmVlMB4XDTE0MDUyMTE4NTQwMVoXDTI0MDUyMTE4NTQwMVowHzEdMBsGA1UEAxMUbmFtc2IuYmxy
Lm5vdmVsbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRTsdCFBM3ImpIyRAj
OdFFEYbC/ykQUEZFwGp62BAUxoLIOpmDZyxpbqIh+l462GFByuCvkLOhnelOGV6Ii/cTAbaHko7h
T7cfUC3N4kmhnc3IXWgjodRIXMlaUSYDYd79guyVjG0brOWJMxJxvm1eo3p8bFzPLnpkEdJ7c8HM
BRqckecaGT8nbpm1KGZFAStrRRTryu2aG670FP3+MHWZmydqLlvrK1NCfe+7DlpOUwA13sSgMslf
6UCI4E50gn6pQ26rctGKrBsFfrX76t6ESZuaqFlWS+YA11cWS3irtihT0p2GsoxcJzq+IvHosHY+
pvrt4gcJiZJN6P3e6yrrAgMBAAGjggIUMIICEDAdBgNVHQ4EFgQUpSkUiviZFQ7yIDLb9sJT+mZH
kngwHwYDVR0jBBgwFoAUfFLP7EF6tU2u2qquPNTvLDdV7e8wggHMBgtghkgBhvg3AQkEAQSCAbsw
ggG3BAIBAAEB/xMdTm92ZWxsIFNlY3VyaXR5IEF0dHJpYnV0ZSh0bSkWQ2h0dHA6Ly9kZXZlbG9w
ZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJpYnV0ZXMvY2VydGF0dHJzX3YxMC5odG0wggFI
oBoBAQAwCDAGAgEBAgFGMAgwBgIBAQIBCgIBaaEaAQEAMAgwBgIBAQIBADAIMAYCAQECAQACAQCi
BgIBFwEB/6OCAQSgWAIBAgICAP8CAQADDQCAAAAAAAAAAAAAAAADCQCAAAAAAAAAADAYMBACAQAC
CH//////////AQEAAgQG8N9IMBgwEAIBAAIIf/////////8BAQACBAbw30ihWAIBAgICAP8CAQAD
DQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAYMBACAQACCH//////////AQEAAgQR/6b9MBgwEAIB
AAIIf/////////8BAQACBBH/pv2iTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAA
AAAAMBIwEAIBAAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUF
AAOCAQEAbA0AdHm5pV6cEwSyOoB3aJfaLegMYPlAuTNK9ajhez9PIHPGSQzNxTRbj3eV9P+ueP7j
i8AFVR3Ej4eA7S1i5kPGuSXhwM6VhSIsCn+x+HbpnFdWJdu5EvErjTIbbjRU/4wTRCqKe7loFqKs
rH+BGNuUJw16l2PM+wJ+sajX7ktzP8rk8CF+cTOe8ggFcEuJ4igl1MMkVbul1RTggRmpcILNFk57
QdmySozjVok1OVQOzIGcAggPBSZeCumNNP8mQIAmvnwWG0cTvDIkMkCV1AzCC0WK0dWM53JZD/aa
tHay9w8QWoUU5cJo8B+uSm2vN+53PdtMKWOXhJcXtXpKKg==</ds:X509Certificate>
                     </ds:X509Data>
                  </ds:KeyInfo>
               </ds:Signature>
               <saml2:Subject>
                  <saml2:NameID NameQualifier="">admin</saml2:NameID>
                  <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
               </saml2:Subject>
               <saml2:Conditions NotBefore="2014-05-26T10:35:41.072Z" NotOnOrAfter="2014-05-26T10:37:41.072Z">
                  <saml2:AudienceRestriction>
                     <saml2:Audience>http://164.99.184.228:8080/doubleit/services/doubleit</saml2:Audience>
                  </saml2:AudienceRestriction>
               </saml2:Conditions>
               <saml2:Advice/>
               <saml2:AuthnStatement AuthnInstant="2014-05-26T10:33:50.564Z">
                  <saml2:AuthnContext>
                     <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:1.0:am:password</saml2:AuthnContextClassRef>
                  </saml2:AuthnContext>
               </saml2:AuthnStatement>
               <saml2:AttributeStatement>
                  <saml2:Attribute AttributeName="emailaddress" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims" Name="emailaddress" NameFormat="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
                     <saml2:AttributeValue xmlns:soap="http://www.w3.org/2003/05/soap-envelope">admin@idp.com</saml2:AttributeValue>
                  </saml2:Attribute>
               </saml2:AttributeStatement>
            </saml2:Assertion>
         </trust:RequestedSecurityToken>
         <trust:Lifetime>
            <wsu:Created>2014-05-26T10:35:41.071Z</wsu:Created>
            <wsu:Expires>2014-05-26T10:37:41.071Z</wsu:Expires>
         </trust:Lifetime>
      </trust:RequestSecurityTokenResponse>
   </S:Body>
</S:Envelope>

5.2.10 Configuring OAuth and OpenID Connect

OAuth 2.0 is an open protocol to allow secure authorization. It enables users to allow third-party client to access users’ private resources. Users do not need to share their credentials. The third-party clients can be web applications, mobile phones, handheld devices, and desktop applications. OAuth provides a method to issue Access tokens to third-party client applications with the user's approval. The third-party client application can then use the Access token to access protected resources hosted by the resource server.

OAuth allows users to control the access to web resources by scope, action, and time.

Access Manager uses OpenID Connect along with OAuth. OpenID Connect implements a single sign-on protocol on top of the OAuth authorization process. It allows client applications to verify the identity of a user based on the authentication performed by the Identity Server (authorization server). It also allows client applications to obtain a user’s basic profile information.

See Section D.0, OAuth versus Other Protocols for differences among OAuth and other single sign-on protocols.

How OAuth Helps

OAuth addresses the following security concerns:

  • To provide access to protected resources, users share their credentials in clear-text with third-party applications. Potential security breaches that can result from the ability of third-party applications to store a user's credentials for future use.

  • Security issues associated with password authentication.

  • The inability of resource owners to restrict a client application's access to protected resources for a specified duration or to limit the client application's access to a subset of resources.

  • The inability of resource owners to revoke a client application's access to a specific client application.

OAuth Terminology

The following list includes frequently used terms in an OAuth flow:

How OAuth Works

You can configure OAuth with Access Manager in one of two ways based on the following requirements:

  • If the web applications validate the Access token before allowing a client application accesses to resources.

  • If the Access Gateway validates the Access token on behalf of web applications.

Why Use OpenID Connect

OAuth allows users to authorize client applications to access users' protected resources through an Access token. The Access token does not contain any information about a user's identity. Hence, a client application does not know who the user is. A client application also does not know if the authorization server has issued the access token to it or to any other relying party.

OpenID Connect builds on OAuth and provides solutions for OAuth’s limitations. It issues an ID token that contains signed assertions about the user. Client applications can verify the ID token and obtain additional details about the user. The ID token also contains information about the issuing authority, the intended client application, time of the token created, and the token expiration time.

OpenID Connect Claims

A client application can obtain information about a user and authentication events through claims. A claim contains information about a user such as phone number, first name, and last name.

OAuth Scenarios

This section describes the following basic scenarios supported by OAuth:

RESTful Applications Security

OAuth provides a way to secure REST APIs. For example, an enterprise acme.com exposes REST APIs that provide various functions. Using OAuth, acme.com can provide secure authorization control on APIs to ensure that the right people have access to these APIs. In addition, they can also enable applications to call APIs on behalf of a user. acme.com can also revoke access to an API even if an application uses it.

See Section C.0, SOAP versus REST API to learn the differences between SOAP and REST API.

Accessing Resources without Using the Resource Owner’s Credentials

In a typical web authentication model, a client application uses the resource owner’s credentials to access the resource owner’s information that is hosted on a server. OAuth allows a client application to access resources that are controlled by the resource owner and provides a method to obtain permission from the resource owners to access their resources. The resource owners provide this permission in the form of a token and a matching shared-secret. The resource owner does not need to share credentials with the client application. Tokens are issued with a restricted scope and limited life.

For example, a user named Alice has installed a gaming application that runs in her browser and uses OAuth for accessing a social site at www.example.com. The gaming application updates scores in a database at www.example.com. The gaming application is registered with the social site and has an identifier. Alice has registered with the social site for identification and authentication. To upload Alice's scores, the gaming application accesses the score database when Alice authorizes it. When Alice accesses the page from the redirect URI in the game application, the authorization serversends the client ID, password, and authentication code received in the redirect request parameters to www.example.com, which in turn returns an Access token to the game application. The gaming application sends the token to www.example.com to access Alice’s resources. www.example verifies the token and grants the gaming application access to Alice’s account for updating the scores.

NOTE:This example is derived from the OAuth RFC document.

Web Server Authentication

To access the user data of other sites, third-party applications seek user’s credentials (user names and passwords). Sharing passwords may result in a security breach. OAuth enables third-party applications to access a user’s information without using the users’ passwords. OAuth also provides a way to grant limited access. For example, a user (resource owner) can allow a printing service (client application) to access private photos stored at a photo sharing service (server), without sharing credentials with the printing service. Instead, the user authenticates directly with the photo sharing service that issues the printing service delegation-specific credentials.

For example, a user named Alice accesses an application running on a web server at www.printphotos.example and instructs it to print her photographs that are stored on a server at www.storephotos.example. The application at www.printphotos.example receives Alice's authorization consent for accessing her photographs without learning her authentication credentials of www.storephotos.example.

The following diagram illustrates the workflow of the web server authentication:

NOTE:This example is derived from the OAuth RFC document.

Mobile Authentication

Applications on a mobile device request for authentication and the web server redirects you to the authorization server (Identity Server) to authenticate and authorize the server to access your data. When you approve, the web server receives an Access token as part of the redirect URL. After the authorization server grants the token, the application can access the protected data with the Access token. Less confidential applications, such as mobile clients or thick clients use this authentication.

Legacy Web Applications Security

OAuth enables client applications including thick clients, mobile, and OAuth enabled browser-based applications to access resources available on legacy web applications. In this scenario, the Access Gateway validates the token on behalf of web applications. You do not need to modify web applications to understand the OAuth flow.

OAuth Implementation Flow

The following diagrams depict the implementation flow of OAuth in Access Manager:

NOTE:Access Manager uses variable length Access tokens and authorization codes. The client applications and web servers should not assume any fixed size of tokens and codes and should allocate necessary memory to handle the token. Token size depends on the size of scope names. Some servers may have size limitations on query string and HTTP headers. Ensure that an application uses only necessary scopes to avoid any issue.

OAuth Implementation without using the Access Gateway

  1. Develop a resource server (web application or REST service). (Application Developer)

  2. Identify scopes and permissions for this resource server. (Application Developer or Administrator)

  3. Add the resource server in Access Manager. See Adding a Resource Server. (Application Developer or Administrator)

  4. Define the identified scopes and permissions for the resource server in Access Manager. See Defining Scopes and Claims for a Resource Server. (Application Developer or Administrator)

  5. Develop a client application. (Application Developer)

  6. Register the client application in Access Manager. You can register a client by using the Administration Console (Administrator), Identity Server (Application Developer or Administrator), or REST API (Application Developer or Administrator). See Registering OAuth Client Applications and Registering a Client Application by Using REST API.

  7. Identity Server assigns a unique client ID and client secret to this client application.

  8. Configure the client ID and secret in the application. (Application Developer or Administrator)

  9. Deploy the resource server. (Application Developer)

  10. Deploy the client application. (Application Developer)

For information about basic scenarios in which you can implement this configuration, see OAuth Scenarios.

For more information about how to enable and configure OAuth in Access Manager for this implementation flow, see Managing OAuth and OpenID Connect.

OAuth Implementation using the Access Gateway

  1. Determine the web application or REST service for which you want to implement this configuration.

  2. Create a reverse proxy in the Access Gateway and enable OAuth in the Access Gateway for this reverse proxy. See Enabling OAuth in the Access Gateway.

  3. Configure an authorization policy based on OAuth Scopes. See Configuring an Authorization Policy based on OAuth Scopes.

  4. Configure an Identity Injection policy to inject user name and password. See Configuring an Identity Injection Policy for OAuth Claims.

  5. Configure optional Identity Injection policies to inject other user claims, if required. You can define the additional roles in the same policy also that you configured for injecting user name and password. See Configuring an Identity Injection Policy for OAuth Claims.

  6. Apply the changes.

For information about the scenario in which you can implement this configuration, see Legacy Web Applications Security.

For information about how to configure OAuth in Access Manager for this implementation flow, see Configuring the Access Gateway for OAuth.

OAuth Authorization Grant

Authorization grant is an intermediate credential that represents the resource owner authorization. To request an Access token, the client application obtains authorization from the resource owner. The resource owner communicates the authorization in the form of an authorization grant that a client application uses to request the Access token. OAuth defines four grant types: authorization code, implicit, resource owner credentials, and client credentials. It also provides an extension mechanism for defining additional grant types. This section discusses the authorization flow for the following grants:

Authorization Code Grant (Web Server)

Client applications hosted on a secure server use Authorization Code Grant. Client applications use this grant to obtain both Access tokens and Refresh tokens. This grant ensures that both types of tokens remain with the client web application (the server side) and the authorization server does not send these to the browser. Only the authorization code is visible to the browser.

The client application redirects the resource owner to the authorization server through the web browser. The resource owner authenticates at the authorization server. The authorization server obtains resource owner’s consent and then redirects the web browser with the authorization code to the client application.

This flow is suitable for client applications who can interact with the resource owner’s user-agent and can receive incoming requests from the authorization server.

Implicit Grant

This flow is suitable for client applications residing in the user's device. A client application can implement this flow in a browser using a scripting language such as JavaScript or Flash, from a mobile device, or from a desktop application. After a user grants the requested authorization, the authorization server returns an Access token to the application. An intermediate authorization code is not required. As the authorization server sends the Access token to the web browser, this flow offers less security than the authorization code.

Resource Owner Credential Grant

This flow is suitable for client applications who have a trust relationship with resource owners.In this flow, the client application sends user's credentials along with its own credentials to the authorization server (Identity Server). The Identity Server provides an Access token and an Refresh token to the client application. The user does not need to log in to approve the request.

Client Credential Grant

The Client Credential Grant is useful for applications that access their own resources from the resource server. This grant type only requires the client application’s credentials. Resource owner's credentials are not required.

OpenID Connect Authentication Flows

This section describes the flow of OpenID Connect authentication by using the Authorization Code flow and Implicit flow.

Authentication by Using the Authorization Code Flow

In this authentication process, the Token endpoint returns all tokens.The Authorization Code Flow returns an authorization code to the client application. The client application exchanges it for an ID token and an Access token. The authorization server can also authenticate the client application before exchanging the authorization code for an Access token. This process does not expose tokens to the User Agent.

Process Flow:

  1. The client application prepares an authentication request containing the desired request parameters and sends the request to the authorization server.

  2. The authorization server authenticates the user.

  3. The authorization server obtains the user consent for the request.

  4. The authorization server sends the user consent to the client application with an authorization code.

  5. The client application requests a response by using the authorization code at the Token endpoint.

  6. The client application receives a response that contains an ID token and Access token in the response body.

  7. The client application validates the ID token and retrieves the user's subject identifier.

Authentication by Using the Implicit Flow

In this authentication process, the authorization endpoint returns all tokens. The endpoint returns the Access token and ID token directly to the client application that may result in revealing the tokens to the user and applications that have access to the User Agent.

Process Flow:

  1. The client application generates an authentication request containing the desired request parameters and sends the request to the authorization server.

  2. The authorization server authenticates the user.

  3. The authorization server obtains the user consent.

  4. The authorization server sends the user to the client application with an ID token and, if requested, an Access token.

  5. The client application validates the ID token and retrieves the user's Subject Identifier.

Managing OAuth and OpenID Connect

NOTE:NTS will support the Access Manager setup and any app issues where the API request is sent to the right Access Manager endpoint. Any other code changes needed to integrate with Access Manager are outside the scope of traditional NTS support and need to go through the namsdk@netiq.com channel.

The following is the sequence of the OAuth and OpenID Connect configuration:

  1. Enable the OAuth protocol in the Administration Console

  2. Define the global settings

  3. Configure a resource server

  4. Configure scopes and claims for a resource server

  5. Register client applications

NOTE:Use Internet Explorer 10 or later, Firefox, or Chrome for configuring OAuth 2.0.

This section discusses the following topics:

Extending a User Store for OAuth 2.0 Authorization Grant Information

Access Manager OAuth 2.0 implementation stores the information about a client application, which a user authorizes to access attributes and resources. This information is unique per user. So, you need to store as part of a User Object in the user store. If you already have a free attribute, you can use it in Authorization Grant LDAP Attribute in while defining Global Settings.

If a free attribute is not available, then extend the User Object schema to add a new single-valued stream attribute with a name. Access Manager will store an XML object in this attribute for each user authorization.

The following example describes how to extend the schema of a User Object in eDirectory:

  1. Click to Roles and Tasks > Schema > Create Attribute.

  2. Specify Attribute Name as nidsOAuthGrant.

  3. Click Next.

  4. Select Stream under Syntax.

  5. Click Next.

  6. Select Single Valued.

  7. Click Next > Finish.

  8. Go to Roles and Tasks > Schema > Add Attribute.

  9. Select Person under Available Classes.

  10. Click OK.

  11. Move nidsOAuthGrant from Available optional attributes to Optional attributes.

  12. Click OK.

Enabling OAuth and OpenID Connect

Access Manager ships with only SAML 1.1, Liberty, and SAML 2.0 enabled by default. To use OAuth, you must enable it in the Identity Server. Otherwise, the configuration will not work.

To enable OAuth and OpenID Connect, perform the following steps:

  1. In the Administration Console, click Devices > Identity Servers > Edit.

  2. In the Enabled Protocols section, select OAuth & OpenID Connect.

  3. Click OK.

  4. Update the Identity Server.

Defining Global Settings

The Global Settings page enables you to specify the default OAuth and OpenID Connect settings for the authorization server such as issuer URL, token types, grants, and so on.

  1. In the Administration Console, click Devices > Identity Server > Edit > OAuth & OpenID Connect > Global Settings.

  2. You can configure and view the following details on this page:

    Field

    Description

    Issuer

    Specify the name of the authorization server. This name is part of the ID token.

    Authorization Grant LDAP Attribute

    Specify a valid LDAP attribute. The attribute specified must exist in the user store.

    A scope uses this attribute to store user consent. Whenever a user grants authorization to an application, this attribute is updated. Ensure that no other application uses this attribute.

    For more information, see Extending a User Store for OAuth 2.0 Authorization Grant Information.

    Grant Type(s)

    Select the types of grants that the authorization server will support. Based on the grant type you select, the system selects corresponding token type by default.

    For more information about grant types, see OAuth Authorization Grant.

    Token Type(s)

    Select the types of tokens that the authorization server will support.

    • ID Token: A security token that contains claims about the authentication of an end user by an authorization server to the relying party.

    • Access Token: Includes the specific scopes and durations of granted access.

    • Refresh Token: Used to obtain a new access token when an Access token becomes invalid or expires.

    Authorization Code Timeout

    Specify the duration in minute after how long the authorization code becomes invalid.

    Access Token and ID Token Timeout

    Specify the duration in minute after how long the Access token and ID token become invalid.

    Refresh Token Timeout

    Specify the duration in minute after how long the Refresh token becomes invalid.

    Supports Signing

    Select this option if you want the authorization server to sign the ID token

    If you selected Supports Signing, select a signing certificate.

    Signing Certificate

    Select a certificate to sign ID tokens.

  3. Click OK.

Configuring a Resource Server

Access Manager allows you to define settings for each resource server. A resource server validates and accepts tokens sent by client applications, and then grants access to resources.

Setting up a resource server includes adding a resource server, defining scopes, and defining claims associated with each scope. Scopes and claims decide what resources client applications can access and what actions they can perform on the resources.

Access Manager also allows you to modify and delete configured resource servers. Configuring a resource server consists of the following actions:

Adding a Resource Server

Perform the following steps:

  1. In the Administration Console, click Devices > Identity Server > Edit > OAuth & OpenID Connect > Resource Server.

  2. Click New.

  3. Specify a name for the resource server.

  4. Click OK.

    Continue with Defining Scopes and Claims for a Resource Server.

Defining Scopes and Claims for a Resource Server

A scope is a set of permissible actions that a client application can perform on the accessed resources. You can define scopes and then set up claims or permissions for each scope. When a user grants client applications access to protected resources, they can perform actions based on permissions defined in the scope.

A scope can be of the following two types:

  • Resource permissions: The resource server can fetch these scopes/permissions specific to requirements. For example, for the edit_photo scope, the resource server recognizes and grants edit rights for the photo.

  • User Claims: Access Manager acts as a special resource server managing access to users' claims. A client application can request these claims.

For example, you can define a scope named email and define permissions associated with this scope such as read only. A client application who will access the email can only read the content.

Perform the following steps to define scopes and permissions:

  1. In the Administration Console, click Devices > Identity Server > Edit > OAuth & OpenID Connect > Resource Server.

  2. Select the resource server name for which you want to define a new scope.

  3. Click New.

  4. Specify the following details:

    Field

    Description

    Name

    Specify a name for the scope.

    Description

    Specify a description for the scope. The consent page shows this description.

    Require user permission

    Select this option if this scope requires the user’s permission before providing access to the protected resources.

    Contains user's claims

    Select this option to include user’s claims in this scope.

    Allow modification in consent

    Select this option to allow modification in consent. When selected, the resource owner can choose not to share this scope with the client application.

  5. Click Next.

  6. Based on whether you have selected Require user permission, you require to perform any one of the following actions:

    • Select an attribute set: If you have selected the Require user permission option, the Identity Server will fetch the required information from the user endpoint. You must specify the LDAP attributes. You can select an attribute set from the list or create a new attribute set. For more information about how to create an attribute set, see Section 3.5.1, Configuring Attribute Sets.

    • Create Claims/Permissions: If you have not selected Require user permission, create claims for the scope.

    • Click New, specify a name for the claim, and click OK.

  7. Click Finish.

Modifying Scopes of a Resource Server

You can modify the scopes of a registered resource server. Access Manager allows you to delete a resource server or delete the scope of a resource server.

To modify scopes of a resource server, perform the following steps:

  1. In the Administration Console, click Devices > Identity Server > Edit > OAuth & OpenID Connect > Resource Server. This page lists all registered resource servers.

  2. Click the resource server > scope you want to modify.

  3. On the Edit Scope page, modify the details as required. For more information about the fields on this page, see Defining Scopes and Claims for a Resource Server.

  4. Click OK.

Modifying Claims and Attributes

You can modify or delete a defined claim. You can also update the attributes associated with a scope. If you have selected Require user permission while creating the scope, the Identity Server fetches the required information from the user endpoint. In this case, you can change the associated LDAP attributes.

If you have not selected Require user permission, the scope contains claims instead of LDAP attributes. You can change the name of the claim. For more information about the fields on this page, see Defining Scopes and Claims for a Resource Server.

Managing OAuth Client Applications

A client application that sends API requests to the authorization server must be registered with the authorization server. As part of the registration, specify the client name, redirections (URIs), and any other provider-specific data required by the API. You can register a client application in the Administration Console or in the Identity Server.

Prerequisites for managing client applications include:

  • Administration Console: The user must have the NAM_OAUTH2_ADMIN role defined in the OAuth policy.

  • Identity Server: The user must have the NAM_OAUTH2_DEVELOPER role defined in the OAuth policy.

An application developer must log into the Identity Server for registering a client application.

The My Applications tab lists all the applications that you added. You can view details, modify, and delete applications.

Registering OAuth Client Applications

Perform the following steps to register a client application:

  1. In the Administration Console, click Devices > Identity Server > Edit > OAuth & OpenID Connect > Client Applications > Register New Clients.

  2. Specify the following details:

    Field

    Description

    Client Name

    Specify the name of the client application.

    Client Type

    Select whether this is a web-based or a desktop client application.

    For web-based applications specify the client type in this format: https://client.example.org/callback

    For native/desktop applications, specify the client type in any one of the following formats:

    https://www.namnetiq.in/

    or

    x-com.netiq.sample://www.namnetiq.in/

    Redirect URIs

    Specify the URIs that the Identity Server uses to send the authorization code and implicit requests.

    Grants Required

    Select the grant types required for this client application. Available grant types include:

    • Authorization Code (default)

    • Implicit

    • Resource Owner Credentials

    • Client Credentials

    Token Types

    Select the token type that the authorization server will return to this client application. The following are available tokens:

    • Code

    • ID Token

    • Refresh Token

    • Access Token

  3. Click Consent Screen Configuration.

    Specify the following details:

    Field

    Description

    Client Logo URL

    Specify the URL of the logo that you want to include in the consent page.

    Privacy Policy URL

    Specify the URL of the privacy policy you want to include in the consent page. You can define your own privacy policy.

    Terms of Service URL

    Specify the URL of the terms of service.

    Contacts

    Specify email addresses of people related to this client application.

  4. Click Advanced OpenID Connect. This is an optional step. Specify the following details:

    Field

    Description

    JSON Web Key Set URI

    Specify the URI of the JSON file containing the json web keys.

    ID Token Signed Response Algorithm

    Specify the ID Token Signed Response Algorithm.

    ID Token Encrypted Response Algorithm

    Specify the algorithm used to encrypt the key.

    ID Token Encrypted Response Enc

    Specify the algorithm used to encrypt the content.

  5. Click Register Client.

    The Identity Server assigns a client ID and a client secret. To see this ID and secret, go to the list of registered client applications on the Client Application page and click the view icon for this client application.

Modifying Registered Client Applications

To modify a registered client application, perform the following steps:

  1. In the Administration Console, click Devices > Identity Server > Edit > OAuth & OpenID Connect > Client Applications. The page lists all registered client applications along with the following details:

    Field

    Description

    Client Application

    Name of the registered application

    Application Type

    Type of the application: Web or Native/Desktop

    Actions

    List of icons associated with actions that you can perform on an application. You can perform the following actions:

    • View details of a registered client application

    • Delete a registered client application

    • Modify details of a registered client application.

  2. Click the edit icon under Actions. The Client Configuration page opens. Modify the details as required. For more information about fields, see Registering OAuth Client Applications.

  3. Click Modify Client.

Configuring the Access Gateway for OAuth

You can configure the Access Gateway to validate OAuth tokens on behalf of the resource server. If the token is not valid then the Access Gateway returns the unauthorized 401 error to the client application.

Configuring the Access Gateway for OAuth consists of the following three steps:

  1. Enabling OAuth in the Access Gateway

  2. Configuring an Authorization Policy based on OAuth Scopes

  3. Configuring an Identity Injection Policy for OAuth Claims or Configuring an Identity Injection Policy for User Passwords

Enabling OAuth in the Access Gateway

If you want the Access Gateway to validate a token before granting access to a protected resource, you must enable OAuth for that protected resource.

Perform the following steps to enable OAuth in the Access Gateway:

  1. In the Administration Console, click Devices > Access Gateway > Edit > [Reverse Proxy name] > [Proxy Service name].

  2. Select the Protected Resources tab.

  3. Click the protected resource for which you want to enable OAuth.

  4. Select Validate OAuth Token.

  5. Click OK.

Configuring an Authorization Policy based on OAuth Scopes

You must configure an authorization policy and then assign it to the protected resource. Access Gateway makes decisions based on the rules defined in the authorization policy after validating the OAuth tokens.

Resources protected by OAuth tokens do not execute any authentication procedure. Hence, evaluation of policies associated with OAuth protected resources cannot fetch any user attributes outside the OAuth scope. All the user attributes needed for the protected resource must be part of the OAuth scope. Ensure that the proxy services protected by OAuth are not associated with any policies that refer to authentication contract, profiles, LDAP attribute, LDAP OU, roles, or RISK score. Any policy, which requests for data other than the scope of OAuth token fails.

Perform the following steps to configure an Authorization policy for scopes:

  1. In the Administration Console, click Devices > Access Gateway > Edit > [Reverse Proxy name] > [Proxy Service name].

  2. Select the Protected Resources tab.

  3. Click the protected resource for which you want to configure an Authorization policy.

  4. Select the Authorization tab.

  5. Click Manage Policies > New.

  6. Specify a name for the policy and select Access Gateway: Authorization for the policy type.

  7. Click OK.

  8. Specify the following details:

    Field

    Action

    Description

    (Optional) Describe the purpose of this rule.

    Priority

    Specify the order in which a rule is applied in the policy, when the policy has multiple rules. The highest priority is 1 and the lowest priority is 10.

    NOTE:If two rules have the same priority, a Deny rule is applied before a Permit rule.

    Conditions

    Click New and then select OAuth Scopes.

    For Value, select the scope from the list.

    Actions

    Select one of the following:

    • Permit: Allows the user to access the resource.

    • Deny: Select one of the following deny actions:

      • Display Default Deny Page: Displays a generic message, indicating that the user has insufficient rights to access the resource.

      • Deny Message: Allows you to provide a customized message that you want to display to users after denying their access attempts.

      • Redirect to URL: Allows you to specify a URL to redirect users after denying access. For example: http://www.example.com

    • Redirect: Specify the URL to which you want the users to redirect when they meet the conditions of this policy.

    • Re-authenticate with Contract: Allows you to specify an authentication contract used to authenticate the user.

  9. Click OK > OK.

  10. Select the policy you created and click Apply Changes > Close.

    The Authorization page of the protected resource opens.

  11. Select the Authorization policy and click Enable > OK.

Configuring an Identity Injection Policy for OAuth Claims

You must configure an Identity Injection policy if you want to send the claims details to the resource server. Claims can include user attributes or permissions.

Perform the following steps to configure an Identity Injection policy for scopes:

  1. In the Administration Console, click Devices > Access Gateway > Edit > [Reverse Proxy name] > [Proxy Service name].

  2. Select the Protected Resources tab.

  3. Click the protected resource for which you want to configure an Identity Injection policy.

  4. Select the Identity Injection tab.

  5. Click Manage Policies > New.

  6. Specify a name for the policy, and then select Access Gateway: Identity Injection for the type of policy.

  7. Click OK.

  8. Specify the following details:

    Field

    Action

    Description

    Specify the purpose of this policy.

    Priority

    Specify the sequence in which you want to apply the rule in the policy, if the policy has multiple rules. The highest priority is 1 and the lowest priority is 10.

    Action

    Click New, then select one of the following:

    • Inject into Authentication Header: Inserts the user name and password into the header. Select OAuth Claims under user name and then select a claim.

    • Inject into Custom Header: Inserts custom names into the custom header. Select OAuth Claims under Value and then select a claim.

    • Inject into Custom Header with Tags: Inserts custom tags with name/value content into the custom header. Select OAuth Claims under Tag Value and then select a claim.

    • Inject into Query String: Inserts a query string into the URL for the page. Select OAuth Claims under Tag Value and then select a claim.

    • Inject Kerberos Ticket: Inserts authentication values from the Kerberos ticket into the custom header. Select OAuth Claims under Value and then select a claim.

  9. Click OK > OK.

  10. Select the policy you created and click Apply Changes > Close.

  11. The Identity Injection page of the protected resource opens.

  12. Select the Identity Injection policy and click Enable > OK.

Configuring an Identity Injection Policy for User Passwords

Ensure that you have enabled the Allow admin to retrieve passwords option under Universal Password Retrieval in the eDirectory user store for all users, so that the policy can retrieve the password from the user store. Without this configuration, the identity injection policy for user password will not work.

For more information about how to enable the password retrieval in eDirectory, see Universal Password Configuration Options in the NetIQ Password Management Administration Guide.

NOTE:The password retrieval works only with eDirectory.

Perform the following steps:

  1. In the Administration Console, click Devices > Access Gateway > Edit > [Reverse Proxy name] > [Proxy Service name].

  2. Select the Protected Resources tab.

  3. Click the protected resource for which you want to configure an Identity Injection policy.

  4. Select the Identity Injection tab.

  5. Click Manage Policies > New.

  6. Specify a name for the policy and select Access Gateway: Identity Injection for the policy type.

  7. Click OK.

  8. Configure the policy with the following details:

    • Action: Select Inject into Authentication Header.

    • User name: Select OAuth Claims > Access Token: User

    • Password: Select OAuth Claims > Password

  9. Click OK > OK.

  10. Select the policy you created and click Apply Changes > Close.

    The Identity Injection page of the protected resource opens.

  11. Select the Identity Injection policy and click Enable > OK.

Viewing Endpoint Details

In the Administration Console under Devices > Identity Servers > Edit > OAuth & OpenID Connect > EndPoint Summary, you can view the following endpoints:

  • Authorization EndPoint: Enables client applications to interact with the resource owner and obtain an authorization grant. It is located on an authorization server.

  • Registration EndPoint: Enables registering client applications on the authorization server. It is located on the authorization server.

  • Token EndPoint: Enables client applications to obtain an Access token by providing its authorization grant or Refresh token. It is located on an authorization server.

  • UserInfo EndPoint: Provides information about the user associated with the Access token in the standard OpenID Connect format.

  • OpenID Metadata EndPoint: Provides information about OpenID provider metadata.

NOTE:As per OAuth specifications, endpoints should not accept any non-HTTPS request. However, Access Manager supports non-HTTPS requests also. This is required to enable OAuth in scenarios when Access Manager is deployed behind a third-party SSL accelerator.

OAuth and OpenID Connect Audit Events

Access Manager provides the following OAuth audit events:

  • OAuth & OpenID Token Issued

  • OAuth & OpenID Token Issue Failed

  • OAuth Consent Provided

  • OAuth Consent Revoked

  • OAuth Client Applications

  • OAuth & OpenID Token Validation Success

  • OAuth & OpenID Token Validation Failed

For details about how to configure Access Manager to send these events to a Novell Auditing Server, see Section 15.2, Enabling Identity Server Audit Events.

Enabling Logging for OAuth and OpenID Connect

To enable logging for OAuth and OpenID Connect events, perform the following steps:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Logging.

  2. Select Enabled under File Logging.

  3. In the Component File Logger Levels section, specify any one of the following options for OAuth and OpenID Connect:

    • Off: Turns off component file logging

    • Severe: Logs serious failures that can stop system processing

    • Warning: Logs potential failures that have minimal impact on execution.

    • Info: Logs informational events.

    • Verbose: Logs static configuration information

      The system logs any configuration errors under one of the primary three levels: Severe, Warning, and Info.

    • Debug: Logs events for all of the preceding levels (Severe, Warning, Info, and Verbose)

  4. Click OK.

Managing Clients Applications by Using REST API

You can programmatically register, view, modify, and delete a client application in Access Manager.

Before performing any of these actions, you must have your role defined as NAM_OAUTH2_DEVELOPER or NAM_OAUTH2_ADMIN in the OAuth policy.

You can register a user in any of the following two ways:

  • Using username and password

  • Using Access token: To register a client application by using an Access token, you must have your role defined as NAM_OAUTH2_DEVELOPER in the OAuth policy.

    Use the Resource Owner flow to get an Access token. The endpoint for Resource Owner flow is

    https://<Identity Server URL: Port Number>/nidp/oauth/nam/token. This endpoint requires the followings parameters to provide an Access token:

    Parameter

    Value

    grant_type

    password

    username

    Application developer’s user name

    password

    Application developer’s password

    scope

    • urn:netiq.com:nam:scope:oauth:registration:full (This scope allows you to register, view, modify, and delete client applications.)

    • urn:netiq.com:nam:scope:oauth:registration:read (This scope provides read-only access)

    token endpoint

    Identity Server URL: Port Number>/ nidp/oauth/nam/token

This section discusses the following topics:

Registering a Client Application by Using REST API

To register a client application, the HTTP method value should be POST.

The Identity Server uses the following endpoint for registering a client application:

https://<Identity Server URL: Port Number>/nidp/oauth/nam/clients

The endpoint requires the following parameters:

Table 5-17 OAuth Parameters for Client Registration

Parameter

Value

Required/Optional

client_id

Name of the client application.

Required

application_type

web or native

Optional

response_types

Redirection URI values used by the client application.

Required

grant_types

The following are the supported grant types:

  • authorization_code

  • implicit

  • refresh_token

  • resource_owner_credentials

  • client_credentials

If you do not specify a grant type, the default grant type is used. The default value is authorization_code.

Optional

response_types

The following are the supported response type:

  • code

  • id_token

  • access_token

Optional

logo_uri

Specify the URL of the logo that you want to include in the consent page.

Example: https://client.example.org/logo.png

Optional

policy_uri

URL of the Relying Party Client’s privacy policy.

Example: https://client.example.org/privacypolicy

Optional

tos_uri

URL of the Relying Party's terms of service

Example: https://client.example.org/terms

Optional

contacts

Email addresses of people related to this client application.

Optional

jwks_uri

Specify the URI of the JSON file containing the json web keys. This key set contains signing keys that the relying party uses to validate signatures from the OpenID provider.

Example: https://client.example.org/my_public_keys.jwks

Optional

id_token_signed_response_alg

Specify the ID Token Signed Response Algorithm. This algorithm is required for signing the ID token issued to the client.

Optional

id_token_encrypted_response_alg

Specify the algorithm used to encrypt the key.

Optional

id_token_encrypted_response_enc

Specify the algorithm used to encrypt the content.

Optional

Modifying a Client Application by Using REST API

Perform the following steps:

  1. Retrieve the client details from the https://<Identity Server URL: Port Number>/nidp/oauth/nam/clients/<client ID> endpoint. In the request for retrieving client details, use GET as the HTTP method value.

  2. Send the update request. In the update request, use POST as the HTTP method value.

    The Identity Server uses the following endpoint for modifying a registered client application:

    https://<Identity Server URL: Port Number>/nidp/oauth/nam/clients/

    For the list of parameters this endpoint requires for a client application modification, see Table 5-17.

NOTE:For updating a client application, you must send the complete xml with all parameters during the update request. If you do not include a parameter in the update xml, the server will not initialize this parameter. For example, if you want to update the response_types parameter, send the updated value for this parameter and existing values for other parameters in the request.

Viewing a Client Application by Using REST API

To view a client application, use GET as the HTTP method value.

You can view a registered client application by using the following two endpoints:

  • https://<Identity Server URL: Port Number>/nidp/oauth/nam/clients/: To view all clients applications registered by a developer

  • https://<Identity Server URL: Port Number>/nidp/oauth/nam/clients/<client ID>: To view a specific client application registered by a developer

Deleting a Client Application by Using REST API

To delete a client application, the HTTP method value should be DELETE.

The Identity Server uses the following endpoint for deleting a registered client application:

https://<Identity Server URL: Port Number>/nidp/oauth/nam/clients/<client ID>

Managing OAuth 2.0 Resource Server and Scope by Using REST API

You can programmatically register, view, modify, and delete a resource server and scopes in Access Manager.

Registering a Resource Server by Using REST API

To register a resource server by using REST API, you must have your role defined as NAM_OAUTH2_ADMIN in the OAuth policy. Send an HTTPS POST request with the appropriate URI parameters to resource server endpoint URI. The request includes the following information:Scope: urn:netiq.com:nam:scope:oauth:registration:full

Resource Server Endpoint: https://<Identity Server URL: Port Number>/nidp/oauth/nam/resourceservers

HTTP Method: POST

URI Parameter: Include the following parameter:

Parameter

Required

Description

name

yes

Name of the resource server

Deleting a Resource Server by Using REST API

To delete a resource server by using REST API, you must have your role defined as NAM_OAUTH2_ADMIN in the OAuth policy. The delete request includes the following details:

Scope: urn:netiq.com:nam:scope:oauth:registration:full

HTTP Method: DELETE

Resource Server Endpoint: https://<Identity Server URL: Port Number>/nidp/oauth/nam/resourceservers/<resourceServerName>

Viewing Registered Resource Servers

To view all registered resource servers by using REST API, you must have your role defined as NAM_OAUTH2_ADMIN or NAM_OAUTH2_DEVELOPER in the OAuth policy. The request includes the following details:

Scope: urn:netiq.com:nam:scope:oauth:registration:full

HTTP Method: GET

Resource Server Endpoint: https://<Identity Server URL: Port Number>/nidp/oauth/nam/resourceservers

Creating a Scope by Using REST API

To create a scope by using REST API, you must have your role defined as NAM_OAUTH2_ADMIN in the OAuth policy. The request includes the following details:

Scope: urn:netiq.com:nam:scope:oauth:registration:full

Resource Server Endpoint: https://<Identity Server URL: Port Number>/nidp/oauth/nam/resourceservers/<resourceServerName>/scopes

HTTP Method: POST

Request URI Parameters:

Parameter

Required

Description

scope

Yes

Name of the scope

scope_description

Yes

Description of the scope. The consent page displays this description while obtaining authorization from the user.

claims

Either claims or attribute_set is required.

List of claims

attribute_set

Attribute name and attribute dn.

Sample: { "name" : "jpeg_photo", "dn" : "cn=jpeg_photo,o=novell"}

userPermissionRequired

No

Boolean value. Default value is true.

adminApprovalRequired

Yes

Boolean value. Default value is true, set it to false always.

isGroupOfUserAttributes

No

Boolean value. Default value is false.

allowModifyInConsent

No

Boolean value. Default value is false.

Modifying a Scope by Using REST API

To modify a scope by using REST API, you must have your role defined as NAM_OAUTH2_ADMIN in the OAuth policy. The request includes the following details:

Scope: urn:netiq.com:nam:scope:oauth:registration:full

Resource Server Endpoint: https://<Identity Server URL: Port Number>/nidp/oauth/nam/resourceservers/<resourceServerName>/scopes/<scopename>

HTTP Method: POST

Send only those parameters which you want to modify.

Deleting a Scope by Using REST API

To delete a scope by using REST API, you must have your role defined as NAM_OAUTH2_ADMIN in the OAuth policy. The request includes the following details:

Scope: urn:netiq.com:nam:scope:oauth:registration:full

Resource Server Endpoint: https://<Identity Server URL: Port Number>/nidp/oauth/nam/resourceservers/<resourceServerName>/scopes/<scopename>

HTTP Method: DELETE

Viewing Configured Scopes by Using REST API

You can view details of all scopes together or a specific scope. To view a scope by using REST API, you must have your role defined as NAM_OAUTH2_DEVELOPER or NAM_OAUTH2_ADMIN in the OAuth policy.

Viewing Details of a Specific Scope

The request includes the following details:

Scope: urn:netiq.com:nam:scope:oauth:registration:full

Resource Server Endpoint: https://<Identity Server URL: Port Number>/nidp/oauth/nam/resourceservers/<resourceServerName>/scopes/<scopename>

HTTP Method: GET

Viewing Details of All Configured Scopes

The request includes the following details:

Scope Required: urn:netiq.com:nam:scope:oauth:registration:full

Resource Server Endpoint: https://<Identity Server URL: Port Number>/nidp/oauth/nam/resourceservers/<resourceServerName>/scopes

HTTP Method: GET

End User Operations

End users can perform the following actions:

User Authorization

When end users access a client application, they are required to give consent for the application to access their email, basic profile, and any other information. An administrator configures a list of allowed scopes. The Consent page shows only these scopes. For example, if an administrator configures email and basic profile, a user can see only these two scopes in the consent pageFigure 5-30.

Figure 5-30 Consent Page

Select the scope that you want the application to access and click Accept.

NOTE:Email is a mandatory scope configured by the administrator and all client applications can access this scope by default. You cannot deselect this scope on the consent page.

The client application should remember the scopes a user has provided earlier in the consent. For the next request, the client application should ask for the scopes that the user did not provide in the earlier request. For example, if a client application asks for five scopes and the user provides only three scopes, the client application should remember user's choice and should not ask for the five scopes again unless it is an absolute requirement.

Revoking Authorizations

You can view all authorized client applications with their scopes and claims under the Authorized Applications tab. An end user can revoke the consent given earlier to client applications by using the Revoke Consent page.

Log into the Identity Server and go to Applications > Authorized Applications. You can view details of client applications and revoke the client applications’ access if required.

Configuring the Demo OAuth Application

This application demonstrates how to protect an OAuth enabled application by using Access Manager. This application contains a RESTful web service and a client application that uses this RESTful web service.

The RESTful web service allows you to perform TODO tasks for a hypothetical application. This web service exposes an API to add, modify, and delete tasks on behalf of a user. The client application provides a web interface that uses REST APIs to manage these tasks. The REST service protects REST APIs with OAuth Access tokens issued by a trusted Access Manager OAuth provider.

This demo configuration provides a way to test OpenID connect endpoints such as metadata, userinfo, and tokeninfo endpoints.

Configuring the demo OAuth application includes the following steps:

Prerequisite

Ensure that you meet the following prerequisites before running the demo application:

Editing Host Entries

If your client and server machines are not in the DNS system, you need to edit the host entries.

Adding Access Manager’s Host Entries

If the domain name is not configured for Access Manager, you need to add a host entry to your desktop system.

Perform the following steps:

  1. In Access Manager Administration Console, go to Devices > Identity Server > cluster name > Base URL.

  2. Add this Base URL value to the host files.

    On Windows: %WINDOWS%\System32\etc\drivers\hosts

    On Linux: /etc/hosts

  3. Open the host file and add the host entries.

    For example, 10.0.0.0 namtest.mycompany.com

Adding the Demo Application’s Host Entries

If you access the demo application by using a web browser, you must access it through a DNS name. This is the IP address where your application is hosted. For example, if you run the demo application on local host (127.0.0.1.), then the host entry is:

For example, 127.0.0.1 mydemoclient.mycompany.com

Access Manager Configuration Checklist

Ensure that you have performed the following actions before running the demo application:

  • Install the Access Manager Administration Console. See Installing Access Manager in the NetIQ Access Manager 4.1 Installation and Upgrade Guide.

  • Install the Access Manager Identity Server and import it into the Administration Console. See Installing Access Manager in the NetIQ Access Manager 4.1 Installation and Upgrade Guide.

  • Create an Identity Server cluster configuration and add the imported Identity Server to that cluster. See Section 3.4, Identity Servers Cluster.

  • Enable OAuth & OpenID Connect in Administration Console > Devices > Identity Server > cluster > General.

  • Extend the user store to host a new attribute on User Object named nidsOAuthGrant. Scopes use this attribute to store the authorization grants provided by a user. If you use the embedded user store of the Administration Console for authenticating users at the Identity Server, then perform the following steps mentioned in Extending a User Store for OAuth 2.0 Authorization Grant Information.

    NOTE:User Store under Identity Server > cluster name > Local should have the IP address of the Administration Console.

  • Create a new certificate with key size 2048 and SHA algorithm set to SHA256. In the Administration Console, go to Security > Certificates > New and specify the name as oauth2048. You will need this certificate while accessing OpenID Connect endpoints. In Access Manager, OpenID Connect uses certificate configured in Identity Server > cluster > OAuth2 & OpenID Connect > Global Settings. OpenID Connect uses the reverse proxy certificate in Access Manager Appliance.

  • Perform the following actions under Identity Server > cluster > OAuth2 & OpenID Connect > Global Settings:

    • Set Authorization Grant LDAP Attribute to nidsOAuthGrant or the name you specified when you extended the user store.

    • Select all Grant Types and Token Types.

    • Click Support Signing and choose the certificate you have created for this demo configuration.

    • Specify the certificate's algorithm.

Registering the Demo RESTful Service in the Administration Console

The demo application contains a simple RESTful web service. This RESTful web service exposes a REST API to add, modify, and delete tasks. A client application can post a request to create, modify, or delete a task by using a REST API. OAuth 2.0 protects this communication. Therefore, each request must contain an OAuth 2.0 Access token with necessary scope list_todo, create_todo, delete_todo to list tasks, add tasks, and delete tasks respectively. Define these scopes in the Administration Console. Later, the client application can request any of these scopes.

To create the scopes, perform the following steps:

  1. In the Access Manager Administration Console, click Devices > Identity Server > Edit > OAuth & OpenID Connect > Resource Server > New.

  2. Specify Todo Service and click OK.

  3. Click newly created services (Todo Service) > Scopes.

  4. Click New and specify the following details:

    • Name: create_todo

    • Description: Create Task Items

    • Require user permission: Select this option

  5. Repeat step 4 and add the following scopes:

    • Name: list_todo, Description: Access your task list

    • Name: delete_todo, Description: Delete your task list

    In this step, you can select Allow modification in consent.

  6. Click OK > OK > Update All.

Registering the Demo Client Application

The client application needs to communicate with the Identity Server through the OAuth 2.0 protocol. As per this protocol’s specification, the Identity Server must uniquely identify each client application. You must register client application in the Identity Manager.

To register a client application in the Identity Server, the user must have the NAM_OAUTH2_DEVELOPER role defined in the OAuth policy. Hence, an administrator needs to create the role in the Administration Console and assign it to the user.

Creating an OAuth 2.0 Developer Role for Registering a Client Application in the Identity Server

Perform the following steps:

  1. In the Administration Console, click Devices > Identity Servers > cluster > General > Roles.

  2. Click Manage Policies > New. Specify the following details:

    • Name: oauth_developers

    • Type: Identity Server: Roles

  3. Click OK.

  4. Specify the following details under Condition Group:

    • New: LDAP Attribute: LDAP Attribute: cn

    • Comparison: String: Equals

    • Value: Data Entry Field: admin or provide your own condition here.

  5. Specify the following detail under Actions:

    • Activate Role: NAM_OAUTH2_DEVELOPER

  6. Click OK > OK > Apply Changes.

  7. Select the oauth_developers and click Close.

  8. Select the oauth_developers policy again and click Enable > OK > Update All.

Registering a Client Application in the Identity Server

Perform the following steps:

  1. Determine the Identity Server’s base URL. Go to Administration Console > Identity Server > cluster > General > Base URL.

  2. Launch this base URL (https://<base_url>/nidp/) in a web browser.

  3. Log into as an administrator.

  4. Go to Applications > My Applications > Register New Clients > Client Configuration.

  5. Specify the following details:

    • Client Name: NetIQ Demo Application

    • Client Type: Web

    • Redirect Uri: Specify the following URLs with the host name you specified in Editing Host Entries (mydemoclient.mycompany.com) and the last one with host name of Access Manager installation (namtest.mycompany.com).

      Add each URL in a separate text box.

      https://mydemoclient.mycompany.com:9443/_oauth-callback

      https://mydemoclient.mycompany.com:9443/_oauth-callback2

      https://mydemoclient.mycompany.com:9443/ag/callback

      https://mydemoclient.mycompany.com:9443/callback

      https://mydemoclient.mycompany.com:9443/oidc/_oauth-callback

      https://mydemoclient.mycompany.com:9443/oidc/_oauth-callback2

      https://namtest.mycompany.com/nidp/netiq/nam/oauth/nam-oauth-callback.html

  6. Select all grants required and token types options.

  7. Click Register Client.

  8. Click NetIQ Demo Application (newly registered client application) and note the values of Client ID and Client Secret.

  9. Log out of the Identity Server.

Running REST Services

Now, the demo application is ready to run.

  1. Launch the resource server (Task Service).

  2. Open a command editor. (Windows: cmd, Linux: any terminal)

  3. Verify that the JAVA class path is set correctly:

    Windows: set PATH=c:\Program Files\Jdk\bin;%PATH%

    Linux: export PATH=/usr/lib64/jvm/jdk1.8/bin:$PATH

    Replace the path of JDK wherever it is installed.

  4. Locate the downloaded demo application file.

  5. Extract todo-service-0.1-SNAPSHOT.zip.

  6. Go to todo-service-0.1-SNAPSHOT

  7. Open the Identity Server Base URL (https://namtest.mycompany.com/nidp/bin/todo-service -Dhttp.port=9001)

    Replace the host name with the Identity Server URL. This will run the todo REST service in the port 9001.

Running the Client Application

Perform the following steps:

  1. Launch a command editor. (Windows: cmd, Linux: any terminal)

  2. Ensure that the Java path is correct. Verify this by running java. If not, set the path to JAVA_HOME’s bin:

    Windows: set PATH=c:\Program Files\Jdk\bin;%PATH%

    Linux: export PATH=/usr/lib64/jvm/jdk1.8/bin:$PATH

    Replace with the path of JDK wherever it is installed.

  3. Locate the downloaded demo application file.

  4. Extract todo-webapp-0.1-SNAPSHOT.zip.

  5. Go to todo-webapp-0.1-SNAPSHOT.

  6. Open this Administration Console URL= https://namtest.mycompany.com:8443/nps IDP_BASE_URL=https://namtest.mycompany.com/nidp OAUTH2_CLIENT_ID=uJaQKe5QIC2RZLx5d53lA6sc1-PMOXI_psOrUABLzVQSktHBGoVLF9bXOJElCJ3yft17CbwJmgMHuaz604i55Q OAUTH2_CLIENT_SECRET=ZcX_SxxwmcTezB9nloCxQzHRFo4Yci-2wmbDmyZNMN0CSkhm6UtraPFPFNzB88iEyA5MqluiDq8vomqGUq8RNQ TODO_SERVICE_PORT=9001 TODO_SERVICE_HOST=localhost ./bin/todo-webapp -Dhttp.port=9000 -Dhttps.port=9443

    This will run the client web application in the port 9443.

Accessing the Client Application through a Web Browser

You can access the application in a browser by using this URL: https://mydemoclient.mycompany.com:9443/.

5.2.11 Configuring Authentication Through Federation for Specific Providers

Setting Up Google Applications

Google Applications are pre-configured to establish federation with external service providers.

  1. In the Administration Console, click Devices > Identity Servers > Edit > [Protocol].

    For the protocol, click SAML 2.0.

  2. Click New > Service Provider.

    NOTE:By default, the Provider Type > General is selected.

  3. Select Google Application from the Provider Type drop-down list.

    By default, the Metadata Text source is selected and the Text field is pre-filled with the metadata XML. You should edit the Location in the metadata text and replace YOURDOMAIN with the domain name configured in Google Applications.

  4. In the Name option, specify a name by which you want to refer to the provider and click Next.

  5. Review the metadata certificates and click Finish. For Google Applications, the certificates page displayed is empty because the metadata does not contain information about the certificates. The system displays the trusted provider on the protocol page. For example, if you have specified the Name as GoogleApps, the page displays the trusted service provider when you click Finish.

    Figure 5-31 Trusted Service Provider for Google Application/Office 365/Sales Force

    Trusted provider list

  6. Click OK, then update the Identity Server.

    The wizard allows you to configure the required options and relies upon the default settings for the other federation options. For information about how to configure the default settings and how to configure the other available options, see Section Section 3.9.4, Modifying a Trusted Provider.

You can configure Access Manager to provide the single sign-on services to Google applications by using Security Assertion Markup Language (SAML) 2.0. For more information, see Integrating Google Apps and Novell Access Manager using SAML 2.0.

Setting Up Office 365 Services

Office 365 is pre-configured to establish federation with external service providers. For more information, see Setting Up Google Applications. In Step 3, select Office 365. The system displays the trusted provider on the protocol page. For example, if you have specified the Name as Office365, the screen displays the trusted service provider Office365 as in Figure 5-31, when you click Finish.

Access Manager is compatible with Microsoft Office 365 and provides single sign-on access to Office 365 services.

For more information, see Section 5.2.12, Configuring Single Sign-On for Office 365 Services.

Integrating Salesforce With Access Manager By Using SAML 2.0

Salesforce.com is pre-configured to establish federation with external service providers.

Integrating Salesforce With Access Manager By Using SAML 2.0 for Identity Provider Initiated Login

To integrate Salesforce for idpsend, follow the procedure in Setting Up Google Applications. In Step 3, select Salesforce. The system displays the trusted provider on the protocol page. For example, if you have specified the Name as SalesForce, the screen displays the trusted service provider as in Figure 5-31, when you click Finish.

Access Manager allows your users to use their existing LDAP credentials for single sign-on access to salesforce.com as well as any Web applications protected by Access Manager.

For information using SAML 2.0 for Identity Provider initiated login, follow the procedure below.

  1. Create domain in Salesforce.

    To enable IDP-initiated login in Salesforce.com, you must enable and configure the My Domain option in Salesforce.com. Defining your own domain provides the basis for an IDP-initiated URL.

    1. Login as administrator. Go to Administration Setup > Domain Management > My Domain.

    2. Specify the subdomain name and check the availability.

    3. Agree to the terms and conditions and click Register Domain.

  2. If you have already configured your identity provider for Salesforce.com using the wizard, you must update configuration in the identity provider according to the new domain. Perform the following steps.

    1. Download the metadata from Salesforce site for your domain. See Step 3. Send and import this metadata into your Identity Server Salesforce configuration. For reimporting metadata in Access Manager Identity Server, see Viewing and Reimporting a Trusted Provider’s Metadata.

    2. Change the Intersite Transfer URL to point to the new domain URL

  3. Perform Step 4 and Step 5.

  4. Update the Identity Server.

Integrating Salesforce With Access Manager By Using SAML 2.0 for Service Provider Initiated Login

Service provider configuration options offer you more flexibility and control for example, simultaneously federating with more than one Identity Server. Salesforce.com also supports SP-initiated login along with IDP-initiated login. SP-initiated login lets the user use a simple and intuitive URL to access the target application.

Follow the procedure given below to integrate Salesforce with Access Manager by using SAML 2.0 for service provider initiated login. Assume that the user has a Salesforce account.

  1. Create domain in Salesforce.

    To enable SP-initiated login in Salesforce.com, you must enable and configure the My Domain option in Salesforce.com. Defining your own domain provides the basis for an SP-initiated URL.

    1. Login as administrator. Go to Administration Setup > Domain Management > My Domain.

    2. Specify the subdomain name and check the availability.

    3. Agree to the terms and conditions and click Register Domain.

      If you have already configured your identity provider for Salesforce.com using wizard, you must update configuration in the identity provider according to the new domain. Perform the following steps.

    NOTE:Configure SSO configuration. Follow the procedure below to enable SAML support in Salesforce.

    1. Go to your Salesforce account and login.

    2. From the left panel, select Security Control > Single sign setting > Saml Single Sign-on Setting > New and fill the form.

    3. To enable SAML select Security Control > Single sign setting > Saml Single Sign-on Setting > Federated Single Sign-On Using SAML > Edit > Enable Saml.

  2. Change the Intersite Transfer URL to point to the new domain URL.

  3. Import Salesforce metadata in Access Manager.

    As with any other SAML federation you must configure both your Access Manager Identity Server and Salesforce.com Service Provider (SP) to establish a trust. You now have an option to download your metadata from Salesforce.com. To download your specific metadata go to your Salesforce.com instance.

    1. Login as administrator. Go to Administration Setup > Security Controls > Single Sign-On Settings.

    2. Select Name which you have configured above and Download Metadata.

    3. Reimport this metadata into your service provider configuration in Access Manager assuming that you have created Salesforce using the wizard.

    The metadata file you download will include a certificate. For Access Manager to trust or use this certificate, the trusted root certificate chain that minted the certificate must exist in the Access Manager certificate trust stores.

  4. Import certificate in Access Manager, for example, Salesforce.com.

    1. Open the downloaded metadata .xml file with a file editor and search for the certificate in the X509Certificate element (between <ds:X509Certificate> and </ds:X509Certificate>).

    2. Copy the information into its own file and give it a .cer file extension. Windows will recognize this as a certificate.

    3. Double click and open the file.

    4. Click Certification Path to see the chain of authority for the certificate.

      You will need the trusted root certificate for every CA in the chain that you see listed.

    5. In the example above, select the VeriSign Class 3 International Server CA – G3 and click View Certificate.

    6. Click Details.

  5. You can now export the CA trusted root certificate.

    1. Click Copy to File…. This will launch the Windows Certificate Export Wizard.

    2. Select .DER encoded when prompted. Give the file a name and save.

    3. Repeat this process for every CA in the certificate path chain.

    4. Use the Access Manager Administration Console to import the resulting CA trusted root certificates into your Access Manager keystores.

After importing, add these certificates into the Identity Server Keystore. For more information, see Section 11.0, Managing Certificates and Keystores.

Ensure to add Root certificate of Salesforce into your OCSP trust store else, OCSP validation fails and the Identity Server displays an error.

Integrating Shibboleth Identity Provider With Access Manager

You can establish a single sign-on exchange between Access Manager SAML 2 service provider and a Shibboleth SAML 2 identity provider.

For more information, see Integrating Access Manager with Shibboleth’s Identity Provider Server.

5.2.12 Configuring Single Sign-On for Office 365 Services

NetIQ Access Manager provides single sign-on access to Office 365 services such as Exchange Server, Sharepoint Online and Lync without using ADFS (Active Directory Federation Services). You can use your existing enterprise credentials to access any of the Office 365 services without having to remember multiple passwords or sign in multiple times to access different services. You can sign in once with an existing password and Access Manager grants you access to all services.

This single sign-on access is achieved by implementing Passive or Active authentication by using WS-Federation, WS-Trust, and SAML 2.0 protocols.

A trust model is set up for Access Manager and Office 365 to communicate with each other. Access Manager, configured as an identity provider, allows Office 365 to trust it for authentication. Office 365 configured as a service provider, consumes authentication assertions from Access Manager.

Passive and Active Authentication

In a Passive authentication scenario, the user signs in through a Web form displayed by the identity provider and the user is requested to log in. In Active authentication scenario, the user is authenticated using thick clients. As the thick client does not support redirection, Office 365 gets the credentials and validates the authentication with Access Manager by communicating directly with it.

Passive authentication is supported by using the WS-Federation protocol and supports sign-in to Office 365 using the Web interface. The clients includes the Office 365 portal, SharePoint Online, Outlook Web Access, and the Office Web Apps. You can achieve passive authentication using either SAML 2.0 or WS-Federation protocol.

Active authentication is supported by using the WS-Trust protocol and supports sign-in to Office 365 using Office client applications. The clients includes Outlook, Lync, Word, Excel, PowerPoint, and OneNote. If you are using Microsoft Exchange, you can use SAML 2.0 but for active authentication, WS-Trust is the recommended protocol.

Configuring Active and Passive Authentication By Using WS-Trust and WS-Federation Protocols

Using the wizard, when you configure an Office 365 domain with WS-Trust protocol it creates the following two domains:

  • A domain preconfigured for active authentication using WS-Trust protocol

  • A domain preconfigured for passive authentication using WS-Federation protocol.

If your business needs demand using a domain based on SAML 2.0 protocol, you can configure a domain manually using the steps in Configuring an Office 365 Domain That Supports Passive Federation Using SAML 2.0 Protocol

The following sections cover the details about how to configure a domain by using WS-Trust and WS-Federation protocols:

Prerequisite

Use the following steps to verify that WS-Trust and WS-Federation protocols are enabled in Access Manager:

  1. In the Administration Console, click Devices > Identity Servers > Edit.

  2. In the Enabled Protocols section, ensure that WS-Trust and WS-Federation protocols are selected.

Configuring an Office 365 Domain By Using WS-Trust Protocol

When you configure a new Office 365 domain by using the WS-Trust protocol, it creates a domain preconfigured for Active authentication and also creates a WS-Federation Service Provider that is preconfigured for Passive authentication.

  1. In the Administration Console, click Devices > Identity Servers > Edit > WS-Trust > Service Provider Domain.

  2. Click New > Office 365 Domain and specify a name to identify the domain. This domain is by default configured with ImmutableID and Attribute Set information and a Service Provider with the same name as the Office 365 domain is automatically created.

    An authentication method Name/Password - Form-WebService is created and this is selected for WS-Trust. This method ensures that an email address/password is accepted for authentication.

    Click the domain name to make further modifications.

    For more details, see link Modifying Service Providers

  3. Click the WS-Federation tab and verify that a new Service Provider with the same name as the Office 365 domain is created. This Service Provider is preconfigured with Attribute Set information and Authentication Response for the Passive authentication.

Configuring an Office 365 Domain to Federate with Access Manager

Prerequisite

Ensure that the following requirements are met before configuring an Office 365 domain:

  • The Identity Server must be accessible from outside the firewall so that the Office 365 domain can communicate with the Identity Server.

  • Sign up for an Office 365 account. For information about signing up, see Sign in to Office 365.

  • To single-sign on to any of the Office 365 applications, ensure that you download it from the Office 365 portal.

  • Create a federated domain in Office 365 and prove ownership of it. This ensures that you add your company domain into the Office 365 domain. For more information, see Adding and Verifying a Domain for Office 365.

  • Ensure that the Windows 7 or Windows 8 workstations do not have the Active Directory Federation Service 2.0 snap-in installed.

  • Ensure that the SSL certificate is issued by a well-known external certification authority (CA).

  • If you are using Microsoft Lync and/or Microsoft Outlook thick clients with WS-Trust, replace the default self-signed SSL server certificate included with Access Manager with one that is signed by a public Certificate Authority (CA). This enables Office 365 to establish a trusted SSL session with Access Manager. For more information see, Managing Trusted Roots and Trust Stores.

    NOTE:If you are using Microsoft Lync, ensure that you enable federation. For more information, see Lync External Access.

  • Install Microsoft Live Sign-in Module to help manage and establish a remote session with the Office 365 account that is created to manage the Office 365 domain. To download, go to Microsoft Downloads Center.

  • Install Microsoft Azure Active Directory Module. To download, go to Manage Azure AD using Windows PowerShell.

Enabling Federation Settings in Office 365 Domain

Run the following commands in Powershell by modifying the commands with your domain name as per your setup. The domain name in the example is namtest.com.

  1. From the Start Menu launch Windows Azure Active Directory Module for Windows PowerShell.

  2. Run $cred=Get-Credential. Enter your cloud service administrator account credentials.

  3. Run Connect-MsolService –Credential $cred

    For example, if the name of the domain is namtest.com and the Base URL of the Identity Server is https://namtest.com/nidp/, execute the following commands at the Powershell prompt:

    NOTE:In this example, the Base URL the port is not specified as it uses the default port 443. If you are using a different port, specify the port with the Base URL.

    For example: https://namtest.com/nidp/

    1. $dom = "namtest.com"

    2. $url = "https://namtest.com/nidp/wsfed/ep"

    3. $ecpUrl = "https://namtest.com/nidp/wstrust/sts/active12"

    4. $uri = "https://namtest.com/nidp/wsfed/"

    5. $logouturl = "https://namtest.com/nidp/jsp/o365wsfedlogout.jsp"

    6. $mex = "https://namtest.com/nidp/wstrust/sts/mex"

    7. $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("name and path of the certificate")

      NOTE:

      • If the certificate used has a .crt extension ensure that you convert it to a .cer extension file.

      • While executing this command, ensure that you specify the path to the certificate within the double quotes. For example: “C:\local\netiq-off365-sign.cer”

    8. $certData = [system.convert]::tobase64string($cert.rawdata)

  4. Use the following cmdlet to update the settings of the single sign-on domain.

    Set-MsolDomainAuthentication -FederationBrandName $dom -Authentication Federated -PassiveLogOnUri $url -SigningCertificate $certData -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -MetadataExchangeUri $mex

Verifying Single Sign-On Access

Prerequisite:

  • You need at least one user in Office 365 to verify that single sign-on is set up. If you have an existing user, ensure that the Immutable ID matches the GUID of the Access Manager user.

    For instance if your user store is eDirectory and you want to retrieve the GUID of an existing Access Manager user, execute the following command on the eDirectory server terminal:

    ldapsearch -D cn=<context> -w <password> -b <search base> cn=<fqdn of the administrator> GUID | grep GUID

    Create an Office 365 user with this GUID as the Immutable ID using the following command in Powershell:

    new-msolUser -userprincipalName "user1@domain name" -immutableID "GUID of user1" - lastname "lastname of user 1" -firstname user1 -DisplayName "user1 users" -BlockCredential $false -"LicenseAssignment testdomain:ENTERPRISEPACK" -usageLocation "two letter country code[example: US,IN,DE,BE,GB etc]" -Password "password of the user" - LicenseAssignment validlicense.

Procedure to verify:

To verify that single sign-on is set up correctly, perform the following procedure in a server that is not added to the domain.

  1. Go to Microsoft Online Services

  2. Log in with your corporate credentials. (For example : user1@namnetiq.in)

    If single sign-on is enabled, the password field is dimmed. You will instead see the following message: You are now required to sign in at <your company>.

  3. Select the Sign in at your company link.

    If you are able to sign in without errors, single sign-on is set up successfully.

Configuring Federation with Office 365 Services for Multiple Domains

You can now federate multiple parent domains with a single Access Manager cluster. This means that if the enterprise has users belonging to multiple domains, a single Access manager cluster can handle the single sign-on requests for all the users for Office 365 services.

For example: Let us assume you have users spread across two domains: user1@namtest.com and user2@namnetiq.in. When user1@namtest.com and user2@namnetiq.in access Office 365 services, the Access Manager identity provider automatically forms the response with the Issuer URI and sends it to corresponding domains configured in the Office 365 service.

Creating Multiple Domains and Establishing Federation with Access Manager

  1. Ensure that you meet the prerequisites for creating a domain. For more information, see Prerequisite.

  2. Create a new Office 365 domain and verify it. For more information see Adding and Verifying a Domain for Office 365.

    NOTE:Office 365 does not support creating a child domain if federation configuration for parent domain is already established using powershell. So ensure that you add all child domains from the Office 365 admin center before establishing federation for the parent domain.

    For more information about establishing federation when there are multiple domains and a child domain, see Configuring Federation for Multiple Domains that Include Child Domains.

  3. According to the example used in section Enabling Federation Settings in Office 365 Domain, we have an existing domain named namtest.com.

    To create a new domain named namnetiq.in, run the following commands in Powershell by modifying the commands with your domain name as per your setup.

    1. Run $cred=Get-Credential. Enter your cloud service administrator account credentials.

    2. Run Connect-MsolService –Credential $cred

      For example, if the name of the domain is namnetiq.in and the Base URL of the Identity Server is https://namnetiq.in/nidp/, execute the following commands at the Powershell prompt:

      NOTE:

      • In the following example, port is not mentioned as it uses 443. However, if you are using port 8443, specify the port with the Base URL as follows:

        For example: https://namnetiq.in:8443/nidp/

      • When you add additional domains to Office 365 using Powershell commands, the variables $certdata, $url, $ecpurl, $logouturl,and $mex should contain the details provided for the existing domain. If you configure a new domain, change the values of $dom and the $uri

      1. $dom = "namnetiq.in"

      2. $url = "https://namtest/nidp/wsfed/ep"

      3. $ecpUrl = "https://namtest.com/nidp/wstrust/sts/active12"

      4. $uri = "https://namnetiq.in/nidp/wsfed/"

      5. $logouturl = "https://namtest.com/nidp/jsp/o365wsfedlogout.jsp"

      6. $mex = "https://namtest.com/nidp/wstrust/sts/mex"

      7. $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("name and path of the certificate")

        NOTE:

        • If the certificate used has a .crt extension ensure that you convert it to a .cer extension file.

        • While executing this command, ensure that you specify the path to the certificate within the double quotes. For example: “C:\local\netiq-off365-sign.cer”

      8. $certData = [system.convert]::tobase64string($cert.rawdata)

    3. Use the following cmdlet to update the settings of the single sign-on domain.

      Set-MsolDomainAuthentication -FederationBrandName $dom -Authentication Federated -PassiveLogOnUri $url -SigningCertificate $certData -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -MetadataExchangeUri $mex

      To configure any more domains, follow the same steps. Ensure that the Issuer URI includes the UPN of the domain. For example. If you are configuring a domain named support.in, the Issuer URI will be https://support.in/nidp/wsfed/

  4. Go to /opt/novell/nids/lib/webapp/ WEB-INF/classes/nidpconfig.properties file. On Windows, the location is C:\Program Files(x86)\Novell\Tomcat\webapps\nidp\WEB-INF\classes.

    Ensure that the following property is uncommented:

    STS_OFFICE365_MULTI_DOMAIN_SUPPORT_AUTO = true

    This property enables users to access Office 365 services using the Issuer URI specific to the domain they belong to.

Configuring Federation for Multiple Domains that Include Child Domains

Consider a scenario where you already have users as part of namtest.com and namnetiq.in. You now have to create a child domain support.namnetiq.in under namnetiq.in. In this case no federation settings are available in Office 365 for the child domain. The federation setting for the parent domain is used. So, it is important that the Issuer URI is not automatically changed to the User Principal Name of the user. The Issuer URI must be set to the parent domain Issuer URI. For the child domain support.namnetiq.in, the Issuer URI will be https://namnetiq.in/nidp/wsfed/

  1. Go to /opt/novell/nids/lib/webapp/ WEB-INF/classes/nidpconfig.properties file. On Windows, the location is C:\Program Files(x86)\Novell\Tomcat\webapps\nidp\WEB-INF\classes.

    Ensure that the following property is commented:

    STS_OFFICE365_MULTI_DOMAIN_SUPPORT_AUTO = true

    This ensures that the Issuer URI is formed based on the UPN of the parent domain.

  2. Add a new line with the following parameter:

    STS_CHANGE_ISSUER = urn:federation:MicrosoftOnline:support.namnetiq.in -> https://namnetiq.in/nidp/wsfed/

    The format is SPentityID:UPNDomain -> new IssuerID.

    With this option, the Issuer URI is read from nidpconfig.properties file In case of multiple child domains, each parent domain and child domain should be added in seperate lines. For example if namnetiq.in is the parent domain and support.namnetiq.in and engineering.namnetiq.in are the child domains, specify the following entries:

    STS_CHANGE_ISSUER = urn:federation:MicrosoftOnline:namnetiq.in ->

    https://namnetiq.in/nidp/wsfed/

    STS_CHANGE_ISSUER = urn:federation:MicrosoftOnline:support.namnetiq.in -> https://namnetiq.in/nidp/wsfed/

    STS_CHANGE_ISSUER = urn:federation:MicrosoftOnline:engineering.namnetiq.in -> https://namnetiq.com/nidp/wsfed/

Configuring an Office 365 Domain That Supports Passive Federation Using SAML 2.0 Protocol

Prerequisite

Ensure that SAML 2.0 is enabled in Access Manager.

  1. In the Administration Console, click Devices> Identity Servers > Edit.

  2. In the Enabled Protocols section, verify whether SAML 2.0 is selected.

Configuring an Office 365 Domain to Federate with Access Manager

Prerequisite

Ensure that the following requirements are met before configuring an Office 365 domain:

  • Sign up for an Office 365 account. For information about signing up, see Sign in to Office 365.

  • To single-sign on to any of the Office 365 applications, ensure that you download it from the Office 365 portal.

  • Create a federated domain in Office 365 and prove ownership of it. By doing this you add your company domain into the Office 365 domain. For more information, see Adding and Verifying a Domain for Office 365.

  • Ensure that the Windows 7 or Windows 8 workstations do not have the Active Directory Federation Service 2.0 snap-in installed.

  • Ensure that the SSL certificate is issued by a well-known external certification authority (CA).

  • If you are using Microsoft Lync and/or Microsoft Outlook thick clients with WS-Trust, replace the default self-signed SSL server certificate included with Access Manager with one that is signed by a public Certificate Authority (CA). This enables Office 365 to establish a trusted SSL session with Access Manager. For more information see, Managing Trusted Roots and Trust Stores.

  • Install Microsoft Live Sign-in Module to help manage and establish a remote session with the Office 365 account that is created to manage the Office 365 domain. To download, go to Microsoft Downloads Center.

  • Install Microsoft Azure Active Directory Module. To download, go to Manage Azure AD using Windows PowerShell.

Setting Up Office 365 Services

Office 365 is preconfigured to establish federation with an external service providers.

Perform the following steps to create a trusted service provider:

  1. In the Administration Console, click Devices> Identity Servers > Edit.

  2. Click SAML 2.0 > New >Service Provider.

  3. Select Provider Type as Office 365. Ensure that Source is selected as the Metadata Text.

  4. Specify a name for the Office 365 domain. The XML metadata is automatically populated in the Text field. Click Next.

  5. Confirm the certificates and click Finish to save the changes.

Establishing Trust Between an Identity Provider and a Service Provider

You can configure Office 365 domains federations by using the Microsoft Online Services Module. You can use the Microsoft Online Services Module to run a series of cmdlets in the Windows PowerShell command-line interface to add or convert domains for single sign-on.

Each Active Directory domain that you want to federate by using Access Manager must either be added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. Adding or converting a domain sets up a trust between Access Manager and Office 365.

Adding a Domain:

To add a domain to Office 365, perform the following steps:

  1. Log in to Office 365 as an administrator.

  2. On the Administrator page, click Management > Domains > Add a domain.

  3. Specify the domain name that you want to add.

  4. Click Next.

  5. Verify the domain name.

    For more information about how to verify a domain, see Verify your domain and change name servers.

  6. Select appropriate services.

  7. Configure the DNS records on the domain registrar for other services.

    NOTE:Do not configure the new domain to the primary domain. Using the Set­MsolDomainAuthentication command to set the domain as a federated domain results in an error if the domain is the default domain.

For more information, see Add a domain to Office 365.

Converting a standard domain to a federated domain: To convert a standard domain to a federated domain, perform the following steps:

  1. Open the Microsoft Online Services Module from the Start menu.

  2. Run $cred=Get-Credential. Enter your cloud service administrator account credentials.

  3. Run Connect-MsolService –Credential $cred.

    This cmdlet connects you to the cloud service. Creating a context that connects you to the cloud service is required before running any of the additional cmdlets installed by the tool.

    For example, if the name of the domain you are converting to a single sign-on domain is namtest.com, and the base URL of the Identity Server is https://namtest.com:8443/nidp, execute the following commands at the Powershell prompt:

    1. $dom = "namtest.com"

    2. $url = "https://namtest.com:8443/nidp/saml2/sso"

    3. $ecpUrl = "https://namtest.com:8443/nidp/saml2/soap"

    4. $uri = "https://namtest.com:8443/nidp/saml2/metadata"

    5. $logouturl = "/nidp/jsp/o365Logout.jsp"

    6. $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("name and path of the certificate")

      NOTE:While executing this command, ensure that you specify the path to the certificate within the double quotes. For example: “C:\local\netiq-off365-sign.cer”

    7. $certData = [system.convert]::tobase64string($cert.rawdata)

  4. Use the following cmdlet to update the settings of the single sign-on domain:

    Set-MsolDomainAuthentication -FederationBrandName $dom -Authentication Federated -PassiveLogOnUri $url -SigningCertificate $certData -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -PreferredAuthenticationProtocol SAMLP

    NOTE:Ensure that there are no spaces after the hyphen if you are copy pasting the command.

Configuring Desktop Email Client to Access Office 365 Emails

You can configure your desktop email client to access Office 365 emails. The email clients must use a basic authentication and a supported exchange access method such as IMAP, POP, Active Sync, and MAPI.

The following are the list of email clients supported for this configuration:

  • Microsoft Outlook 2007

  • Microsoft Outlook 2010

  • Thunderbird 8 and 9

  • The iPhone (various iOS versions)

  • Windows Phone 7

NOTE:You can download the email clients from the download section of Office 365.

These steps are explained with an example where the federated domain name is namtest.com and the base URL is https://namtest.com:8443/nidp. Replace the domain name and base URL based on your system configuration.

  1. Open the Microsoft Online Services Module.

  2. Run the following command:

    $cred=Get-Credential

    Specify your cloud service administrator account credentials.

  3. Run the following command:

    Connect-MsolService –Credential $cred

    This cmdlet connects you to the cloud service.

  4. Execute the following command to check the existing domain federation settings:

    Get-MsolDomainFederationSettings -DomainName namtest.com

    Substitute namtest.com with your domain name before executing this command.

    In the output, look for the ActiveLogOnUri parameter.

    For the Identity Server base URL https://namtest.com:8443/nidp, the value of the ActiveLogOnUri should be https://namtest.com:8443/nidp/saml2/soap. The ActiveLogOnUri is dependent on the base URL of the Identity Server.

    If the value of ActiveLogOnUri in the command output is https://namtest.com:8443/nidp/saml2/soap, go to Step 5 without modifying the configuration.

    (Conditional) If the ActiveLogOnUri is not https://namtest.com:8443/nidp/saml2/soap, execute the following command. Substitute namtest.com and port 8443 with your domain name and port number respectively before executing the following command. 

    Set-MsolDomainFederationSettings -DomainName namtest.com -ActiveLogOnUri "https://namtest.com:8443/nidp/saml2/soap" -preferredauthenticationprotocol SAMLP

  5. Create a new email account in your email client and enter your Office 365 email ID.

    NOTE:Configure Outlook related DNS settings before using email clients. You can configure these settings after adding the domain on the Office 365 port page.

  6. The system prompts for specifying the basic authentication. Specify Access Manager credentials.

    The email account is created after successful authentication.

    NOTE:While logging in to the new email account, enter Access Manager credentials.

Verifying Single Sign-On Access

You need at least one user in Office 365 to verify that single sign-on is set up. If you have an existing user, ensure that the Immutable ID matches with the GUID of the Access Manager user.

Prerequisite:

  • You need at least one user in Office 365 to verify that single sign-on is set up. If you have an existing user, ensure that the Immutable ID matches the GUID of the Access Manager user.

    For instance, if your user store is eDirectory and you want to retrieve the GUID of an existing Access Manager user, execute the following command on the eDirectory server terminal:

    ldapsearch -D cn=<context> -w <password> -b <search base> cn=<name of the user> GUID | grep GUID

    Create an Office 365 user with this GUID as the Immutable ID using the following command in Powershell:

    new-msolUser -userprincipalName "user1@domain name" -immutableID "GUID of user1" - lastname "lastname of user 1" -firstname user1 -DisplayName "user1 users" -BlockCredential $false -"LicenseAssignment testdomain:ENTERPRISEPACK" -usageLocation "two letter country code[example: US,IN,DE,BE,GB etc]" -Password "password of the user".

If you want to use any other attribute as the ImmutableID of the Office 365 user, configure and then add a property name/value pair.

  1. In the Administration Console, go to Identity Server and select an Identity Server.

  2. Select SAML 2.0 and then select the service provider you created.

  3. Select Options and click New.

  4. Add a property name/value pair as follows:

    Property Name: SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME

    Property Value: title

The title you specify in the Property Value should be base64 encoded and stored in the user store. This value should be used as ImmutableID while creating a user in Office 365.

Verifying Single Sign-on:

To verify that single sign-on is set up correctly, perform the following procedure in a server that is not added to the domain:

  1. Go to Microsoft Online Services.

  2. Log in with your corporate credentials. (For example : user1@namtest.com)

    If single sign-on is enabled, the password field is dimmed. You will instead see the following message: You are now required to sign in at <your company>.

  3. Select the Sign in at your company link.

    If you are able to sign in without errors, single sign-on is set up successfully.

Troubleshooting Scenarios

WS-Trust and WS-Federation Scenarios

Issue in Setting Up a Domain for Federation

If you try to set a primary domain for federation by running the Set­MsolDomainAuthentication command, it throws the following error:

Set­MsolDomainAuthentication: You cannot remove this domain as the default domain without replacing it with another default domain. Use the Set­MsolDomain cmdlet to set another domain as the default domain before you delete this domain.

To fix this issue, change the default domain by performing the following steps:

  1. In the Office 365 portal, click Organization Name on the Admin page.

  2. Click Edit.

  3. Select a new default domain.

Set-MsolDomainAuthentication : You cannot remove this domain as the default domain without replacing it with another default domain

If you get this error it indicates that you attempted to delete the default domain without replacing it with another domain.

Use the Set-MsolDomain cmdlet to set another domain as the default domain before you delete this domain.

After upgrading iOS Apps to the Latest Version, Single Sign-On to Office 365 Services Fail

To establish single sign-on from iOS apps to Office 365 services, perform the following steps:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Local > Contract.

  2. Specify a name to identity the contract.

  3. Specify the URI as http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password.

  4. Select Name/Password - Form - WebService method.

SAML 2.0 Scenarios

SSO to MicroSoft Services Fails

SSO fails at Microsoft with this error: 

Your organization could not sign you in to this service

Perform the following steps to fix this issue:

  • Verify that the attributes are configured properly.

    You can also use the SAML tracer plug-in Firefox to review the SAML assertion sent to Office365.

  • Verify that federation settings are using the Get­MsolDomainFederationSettings ­ DomainName <YOUR DOMAIN> command.

Issue in Setting Up a Domain for Federation

If you try setting up a primary domain for federation by running the Set­MsolDomainAuthentication command, it throws the following error:

Set­MsolDomainAuthentication: You cannot remove this domain as the default domain without replacing it with another default domain. Use the Set­MsolDomain cmdlet to set another domain as the default domain before you delete this domain.

To fix this issue, change the default domain by performing the following steps:

  1. In the Office 365 portal, click Organization Name on the Admin page.

  2. Click Edit.

  3. Select a new default domain.

Office 365 Domain Scenarios

Issues with the Directory Synchronization Tool

  • If the installation of the Directory Synchronization tool fails, check the Event Viewer. Installation may fail if the Microsoft Online Service Sign­In Assistant is already installed on the system.

  • If you require to uninstall the Directory Synchronization tool, log off and then login.

  • If the Directory Synchronization tool is slow, increase RAM of the server.

Active Profile Authentication Fails for Microsoft Exchange Clients

If the active profile authentication fails for Microsoft Exchange (Outlook) clients, verify that the necessary DNS records have been added to your DNS. For more information, see Create DNS records at any DNS hosting provider for Office 365.

Microsoft Online Services Sign-In Assistant Installation Fails If Microsoft Office Professional Plus Is Installed

Manually install Microsoft Online Services Sign-In Assistant, if its installation fails after installing Microsoft Office Professional Plus with this message: 

"The Microsoft Online Services Sign In Assistant has experience an error. The error must be resolved before your subscription for this product can be verified. To retry subscription verification, first resolve error message 800704DD or try to manually install the Microsoft Online Services Sign In Assistant...."

You can download the installer from MicroSoft Download Center.

After installation is complete, relaunch the service to verify your Office 365 license. For more information, see Reactivate subscription license by using Osaui.exe.

Single Sign-On to Office 365 Domain Fails

If single sign-on fails, ensure that the ImmutableID and the User Principal Name (UPN) matches the Office 365 user. To get Office 365 user details, log in to using Powershell and execute the following command:

Get-MsolUser -UserPrincipalName user1@namtest.com | fl *

No License to Use Office 365 Services

If you receive an error stating that the user does not have license to use Office365, Log in to Office 365 as an administrator and assign required service licenses to the user.

After Initial Successful Authentication, Unending Loop While Logging into Lync Using Wrong Username and Password

After successfully authenticating to Office 365 client, if you attempt to login to the Lync client using an incorrect username and password, Lync client uses the details from the previous successful session and tries to get a token from Access Manager. This results in an unending loop.

To resolve this issue, in the Lync client user interface, select the Delete my sign-in info option and log in once again.

Sample Tokens

Sample SAML Token

This section contains a sample XML for WS-Trust request and response.

Request:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_3ae4edbc-7ab5-48c7-a08e-b8d6e395e02c" IssueInstant="2012-09-09T08:41:35Z" Version="2.0" AssertionConsumerServiceIndex="0" ><saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

Response:

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Consent="urn:oasis:names:tc:SAML:2.0:consent:obtained"

Destination="https://login.microsoftonline.com/login.srf" ID="idRuMHBvlVGqYUsw2Es-SbA5UeO8w" InResponseTo="_3ae4edbc-7ab5-48c7-a08e-b8d6e395e02c"

IssueInstant="2012-09-09T08:41:51Z" Version="2.0"><saml:Issuer>https://www.netiqtst.com/nidp/saml2/metadata</saml:Issuer><samlp:Status><samlp:StatusCode

Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><saml:Assertion ID="idF5JceWGWYwS3bOkmJS2wJuNqitU" IssueInstant="2012-09-09T08:41:51Z"

Version="2.0"><saml:Issuer>https://www.netiqtst.com/nidp/saml2/metadata</saml:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><CanonicalizationMethod xmlns="http://www.w3.org/2000/09/xmldsig#"

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference

URI="#idF5JceWGWYwS3bOkmJS2wJuNqitU"><ds:Transforms><ds:Transform

Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">ZocFiEUYcda0cKGRNcZYZqvmnlM=</DigestValue></ds:Reference></ds:SignedInfo><SignatureValue xmlns="http://www.w3.org/2000/09/xmldsig#">

DLk4Uv/4VlwwKVz7XdDQOdUv8ltcryLv2U3K7q57AE70wk/NNsa4kP8Xdta36Y47Oj+XTV+a+q0yYsMNIezySxaxMqo01Fm+6PfMH7HtTVj7fQ3n+VwANqbIs3G7eaaV1pHdUs79/dBujS8baNmlZEBR2gGVMWCHOa1fTOSZO8yPt9ume0PsYXpo2RdaoGkJCZUnVIiIWg6UtI0zEKbY6mP3JhrUJ7OVHdbzyNBzhfTv0m71nz0JKpy+i8MeDUIu1OiqTTIZ+c2SPceYhQcj8umrdE4JCGEBYNIE52Pa1bRYgmLdroAKn56vLDjq04VnYVRGhqP/McZwYZrx+7E7qQ==</SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIFBzCCA++gAwIBAgIRAKdqzGh19tecryvMuy+QhgAwDQYJKoZIhvcNAQEFBQAwcjELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGDAWBgNVBAMTD0Vzc2VudGlhbFNTTCBDQTAeFw0xMjA5MDcwMDAwMDBaFw0xMjEyMDYyMzU5NTlaMFExITAfBgNVBAsTGERvbWFpbiBDb250cm9sIFZhbGlkYXRlZDERMA8GA1UECxMIRnJlZSBTU0wxGTAXBgNVBAMTEHd3dy5uZXRpcXRzdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX6k7wnFUoyPtqSj06xyQMHQtoxASBtHGASaOMxfZJrHQ4wbJUqMEtrxYcz4JxFrLzE8qvlY5r7cwxx/yvsiFwHq2HdRY6KU6I2u0eRF/tRwf3rl222/Xl7wRbgdL43zd0yypjub9FKXlCxkaKucA1P+EVGTd7H8dFjMuf0iKZYvBFg9tcJWBGpFOw5iwe/rjK6gQSXf13+Tpb6915lsusJfPMe3t04wA4XuyLlcJ/Jrxrj9xrEtwkmUcudTvEZRvJFnz3NYXcW0J86a0JZSEiHlVHrIY/44fVEQFjkrfr2u5RKGBJzl35xb2x5mkUSzzy4CSL5p0fCsVOve7LKx/fAgMBAAGjggG3MIIBszAfBgNVHSMEGDAWgBTay+qtWwhdzP/8JlTOSeVVxjj0+DAdBgNVHQ4EFgQUEj/Cc5rqiBWiSzo9B8iJPdJnCpYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwNAYDVR0lBC0wKwYIKwYBBQUHAwEGCCsGAQUFBwMCBgorBgEEAYI3CgMDBglghkgBhvhCBAEwRQYDVR0gBD4wPDA6BgsrBgEEAbIxAQICBzArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8uY29tL0NQUzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9Fc3NlbnRpYWxTU0xDQS5jcmwwbgYIKwYBBQUHAQEEYjBgMDgGCCsGAQUFBzAChixodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9Fc3NlbnRpYWxTU0xDQV8yLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCkGA1UdEQQiMCCCEHd3dy5uZXRpcXRzdC5jb22CDG5ldGlxdHN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAJoS/fE0gBMWvzQBsRRuSMBHMNbgDXP1fVPwJZnkfIHbb/wXwYK7AqA5efOe1AlqzQD94kJ+W6JZm4ripePJk7QLnK2imqJb0E7LdmWQ3D05WQNsZKUklfR+9elP6xBN5ycXqtiEItScmhE7H2gynz4/ejLXZv8XsBkfsYnT0wWUmyTsqYPLmVk7ELfPiPGZsQcvpmSO9eoTQ8zabkQGjquzMNgGtXOMQBQgNO/7IMghgmSR0NduPguZoL31Ox84yKdf6Hl5cvbnH2W4c0n8vTkgCwUkB8ONY1Tge6TFPwzS98PzV08nxKSJW1hckasLQAYcw++bC7Blz+Nc7YyrNPw==

</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"

NameQualifier="https://namtest.com:8443/nidp/saml2/metadata"

SPNameQualifier="urn:federation:MicrosoftOnline">bzM2NkBuZXRpcXRzdC5jb20=</saml:NameID><saml:SubjectConfirmation

Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData

InResponseTo="_3ae4edbc-7ab5-48c7-a08e-b8d6e395e02c" NotOnOrAfter="2012-09-09T09:41:51Z"

Recipient="https://login.microsoftonline.com/login.srf"/></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotBefore="2012-09-09T05:55:12Z"

NotOnOrAfter="2012-09-09T11:28:30Z"><saml:AudienceRestriction><saml:Audience>...

SessionIndex="idF5JceWGWYwS3bOkmJS2wJuNqitU"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password...

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

<saml:AttributeValue xsi:type="xs:string">o3662@netiqtst.com</saml:AttributeValue></saml:Attribute>

<saml:Attribute xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="ImmutableID"...

</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response>

Sample WS-Trust Token

<saml:Assertion AssertionID="nsts150b8594-0aff-424f-8113-46045d943171" IssueInstant="2014-05-09T07:00:18.019Z" Issuer="https://namnetiq.in/nidp/wsfed/" MajorVersion="1" MinorVersion="1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <saml:Conditions NotBefore="2014-05-09T07:00:18.019Z" NotOnOrAfter="2014-05-09T07:06:18.019Z">
      <saml:AudienceRestrictionCondition>
         <saml:Audience>
          urn:federation:MicrosoftOnline
         </saml:Audience>
      </saml:AudienceRestrictionCondition>
   </saml:Conditions>
   <saml:Advice/>
   <saml:AuthenticationStatement AuthenticationInstant="2014-05-09T07:00:18.019Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
      <saml:Subject>
         <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="urn:federation:MicrosoftOnline">
          TLP1nEzIc0EEtEyz9ZxMyA==
         </saml:NameIdentifier>
         <saml:SubjectConfirmation>
            <saml:ConfirmationMethod>
             urn:oasis:names:tc:SAML:1.0:cm:bearer
            </saml:ConfirmationMethod>
         </saml:SubjectConfirmation>
      </saml:Subject>
   </saml:AuthenticationStatement>
   <saml:AttributeStatement>
      <saml:Subject>
         <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="urn:federation:MicrosoftOnline">
          TLP1nEzIc0EEtEyz9ZxMyA==
         </saml:NameIdentifier>
         <saml:SubjectConfirmation>
            <saml:ConfirmationMethod>
             urn:oasis:names:tc:SAML:1.0:cm:bearer
            </saml:ConfirmationMethod>
         </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Attribute AttributeName="UPN" AttributeNamespace="http://schemas.xmlsoap.org/claims">
         <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema">
          namtest@namnetiq.in
         </saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute AttributeName="ImmutableID" AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05">
         <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema">
          TLP1nEzIc0EEtEyz9ZxMyA==
         </saml:AttributeValue>
      </saml:Attribute>
   </saml:AttributeStatement>
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
         <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
         <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
         <ds:Reference URI="#nsts150b8594-0aff-424f-8113-46045d943171">
            <ds:Transforms>
               <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
               <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>
             0Zvo3DbV0Qq7m9q7ER4Hol24bmA=
            </ds:DigestValue>
         </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>
       SqWAA39fYb3VJPBebZ6bsiUh0C+8ElbgDv2yG6xq3WLYUX/DoQ6RLfsb/1mVmMQBcGqhUxhcDRAT
k6JA3djHbZCrZh7qblc8uBr+nm1SzpS/BO7todTLu+g835WGSKdpnpSoTjhO285MjsoomnrL+A4S
33F5Ld5OVOTPoar1wpBPFOgm7k9SnzjU0h7yIpP7YlzX1uF2sPvNeDRhkNEIsWwSPUY9mw04An9V
AsC1Cb1Q7+vEtCxggJ4A6nxk8G9bvPRisk7H5fTihf0THNEzu5s6KnyGHCc6k2/jWHHF4Appg/aJ
Ze1yQR9MKagNe60sAU2U83GM8WUst+o3+PvI3A==
      </ds:SignatureValue>
      <ds:KeyInfo>
         <ds:X509Data>
            <ds:X509Certificate>
             MIIFSTCCBDGgAwIBAgIGb+MI39nZMA0GCSqGSIb3DQEBCwUAMIHGMQswCQYDVQQGEwJVUzEQMA4G
A1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTElMCMGA1UEChMcU3RhcmZpZWxkIFRl
Y2hub2xvZ2llcywgSW5jLjEzMDEGA1UECxMqaHR0cDovL2NlcnRzLnN0YXJmaWVsZHRlY2guY29t
L3JlcG9zaXRvcnkvMTQwMgYDVQQDEytTdGFyZmllbGQgU2VjdXJlIENlcnRpZmljYXRlIEF1dGhv
cml0eSAtIEcyMB4XDTE0MDUwNjA5MDYwNVoXDTE1MDIyNjEyMDQwNFowOTEhMB8GA1UECxMYRG9t
YWluIENvbnRyb2wgVmFsaWRhdGVkMRQwEgYDVQQDEwtuYW1uZXRpcS5pbjCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMzjEinlOiwzMpKBQO+H2sb+HifrmVi7JDzhRfOKJakG+nXsgVx2
QRToN0UbvoeqlDtaTZSKrFb0mc/E3aEkgSU67DAzWvtm3nUSboJc4QVWQlJmXIP989K2H1DastwE
Srg6iw0MMUuz9ZadP3BQjV4VVB9qX81D32lD4Ti1gJYUDg5tpaUnftddiR+rZQROea3ABC0+oeZa
7w+jVFUOAP+uG2iJ4zksIO+F3wIXDNZMYQwFlTvnCTO6/4cRW1XoGxh0BbZGdYn0qHzAOu9okT2B
gnz+aTaMGSIPpPr+PXjB31XqeAhBRoXgrddWIt1DawyrJETPOrzfMhd1i+QSXHcCAwEAAaOCAccw
ggHDMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB
/wQEAwIFoDA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLnN0YXJmaWVsZHRlY2guY29tL3Nm
aWcyczEtOC5jcmwwWQYDVR0gBFIwUDBOBgtghkgBhv1uAQcXATA/MD0GCCsGAQUFBwIBFjFodHRw
Oi8vY2VydGlmaWNhdGVzLnN0YXJmaWVsZHRlY2guY29tL3JlcG9zaXRvcnkvMIGCBggrBgEFBQcB
AQR2MHQwKgYIKwYBBQUHMAGGHmh0dHA6Ly9vY3NwLnN0YXJmaWVsZHRlY2guY29tLzBGBggrBgEF
BQcwAoY6aHR0cDovL2NlcnRpZmljYXRlcy5zdGFyZmllbGR0ZWNoLmNvbS9yZXBvc2l0b3J5L3Nm
aWcyLmNydDAfBgNVHSMEGDAWgBQlRYFoUCY4PTstLL7Natm2PbNmYzAnBgNVHREEIDAeggtuYW1u
ZXRpcS5pboIPd3d3Lm5hbW5ldGlxLmluMB0GA1UdDgQWBBQANClvlYFFU3cAkvFQz/TxuttEUTAN
BgkqhkiG9w0BAQsFAAOCAQEAySHcxqGpgrm9HSiSIFzDOdC9BraZdjh+fIUBeKRUBmSjSByPJIHj
OGuBnY8FtuPY8/e1KhzwhZcuUhY3zwVQzbWStWLraySJyO1SzRRJC4onLbx42ARdKbRgxA/JDsmY
aTnyYq+ZOLm6XUtDweFEDkklAy2sO8gru54ogJ0iD/JyX/dgZEH/v9lGjdNFUDwG4dLz++a2Ol/U
UfqJye7Rb5UgNkewcG9KjydiTgP7Mv6m8/JjzOl31ejIVVqwz30fo+agirrIWWG2Ogtk0JUFrY73
coKTzspPszxMGN2FJpRSymtO+cqVlEuAK6/SCr2mhBvxg4GJuXuzSLp2kSrIfA==
            </ds:X509Certificate>
         </ds:X509Data>
      </ds:KeyInfo>
   </ds:Signature>
</saml:Assertion>

Sample WS-Federation Token

<wst:RequestedSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
      <saml:Assertion AssertionID="idjTptEEQd5CuKy-0M-MBCY9lDHVQ" IssueInstant="2014-05-09T06:44:07Z" Issuer="https://namnetiq.in/nidp/wsfed/" MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
         <saml:Conditions NotBefore="2014-05-09T06:29:07Z" NotOnOrAfter="2014-05-09T06:59:07Z">
            <saml:AudienceRestrictionCondition>
               <saml:Audience>
                urn:federation:MicrosoftOnline
               </saml:Audience>
            </saml:AudienceRestrictionCondition>
         </saml:Conditions>
         <saml:AuthenticationStatement AuthenticationInstant="2014-05-09T06:44:07Z" AuthenticationMethod="name/password/uri">
            <saml:Subject>
               <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
                TLP1nEzIc0EEtEyz9ZxMyA==
               </saml:NameIdentifier>
               <saml:SubjectConfirmation>
                  <saml:ConfirmationMethod>
                   urn:oasis:names:tc:SAML:1.0:cm:bearer
                  </saml:ConfirmationMethod>
               </saml:SubjectConfirmation>
            </saml:Subject>
         </saml:AuthenticationStatement>
         <saml:AttributeStatement>
            <saml:Subject>
               <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
                TLP1nEzIc0EEtEyz9ZxMyA==
               </saml:NameIdentifier>
               <saml:SubjectConfirmation>
                  <saml:ConfirmationMethod>
                   urn:oasis:names:tc:SAML:1.0:cm:bearer
                  </saml:ConfirmationMethod>
               </saml:SubjectConfirmation>
            </saml:Subject>
            <saml:Attribute AttributeName="UPN" AttributeNamespace="http://schemas.xmlsoap.org/claims">
               <saml:AttributeValue>
                XX
               </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute AttributeName="ImmutableID" AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05">
               <saml:AttributeValue>
                XX
               </saml:AttributeValue>
            </saml:Attribute>
         </saml:AttributeStatement>
         <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
               <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns="http://www.w3.org/2000/09/xmldsig#"/>
               <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
               <ds:Reference URI="#idjTptEEQd5CuKy-0M-MBCY9lDHVQ" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                  <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                     <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
                     <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
                  </ds:Transforms>
                  <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
                  <DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">
                   vOVgMA5UmoGFqXL4ENvYPsH/aP0=
                  </DigestValue>
               </ds:Reference>
            </ds:SignedInfo>
            <SignatureValue xmlns="http://www.w3.org/2000/09/xmldsig#">
             
hwPIdSGG+M29sih+5MiWEf862d5K/zSST3XVn1kIwWN3HaLi/yAnGiOUf6nzNJxE99pudElUdy3R
Kc5z8iQAu3gekVG1Nk4n2mDKZVet1kKEcgHGsfdwGxCkz5bpsPsaMB+pJyvFqu/RlRXIqsZtVrxv
7PwOIwUPxJQesNhJrdoJNsKxr65ckj2EeL5scCrDh9mYvtMCh/Qa0C3ALXUm+hBfj21hqw1Qp58I
m68DFTwh35pDkm4AXVxSRCm/9FKuoPGSXeU+O016Gv/FISLiEma+48dN0awlJvxzPI/cUayyJU2N
3EZp7LpZLfErushLBQQ9YmDNmevpCQoN4cZtuA==

            </SignatureValue>
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
               <ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                  <ds:X509Certificate xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                   
MIIFSTCCBDGgAwIBAgIGb+MI39nZMA0GCSqGSIb3DQEBCwUAMIHGMQswCQYDVQQGEwJVUzEQMA4G
A1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTElMCMGA1UEChMcU3RhcmZpZWxkIFRl
Y2hub2xvZ2llcywgSW5jLjEzMDEGA1UECxMqaHR0cDovL2NlcnRzLnN0YXJmaWVsZHRlY2guY29t
L3JlcG9zaXRvcnkvMTQwMgYDVQQDEytTdGFyZmllbGQgU2VjdXJlIENlcnRpZmljYXRlIEF1dGhv
cml0eSAtIEcyMB4XDTE0MDUwNjA5MDYwNVoXDTE1MDIyNjEyMDQwNFowOTEhMB8GA1UECxMYRG9t
YWluIENvbnRyb2wgVmFsaWRhdGVkMRQwEgYDVQQDEwtuYW1uZXRpcS5pbjCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMzjEinlOiwzMpKBQO+H2sb+HifrmVi7JDzhRfOKJakG+nXsgVx2
QRToN0UbvoeqlDtaTZSKrFb0mc/E3aEkgSU67DAzWvtm3nUSboJc4QVWQlJmXIP989K2H1DastwE
Srg6iw0MMUuz9ZadP3BQjV4VVB9qX81D32lD4Ti1gJYUDg5tpaUnftddiR+rZQROea3ABC0+oeZa
7w+jVFUOAP+uG2iJ4zksIO+F3wIXDNZMYQwFlTvnCTO6/4cRW1XoGxh0BbZGdYn0qHzAOu9okT2B
gnz+aTaMGSIPpPr+PXjB31XqeAhBRoXgrddWIt1DawyrJETPOrzfMhd1i+QSXHcCAwEAAaOCAccw
ggHDMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB
/wQEAwIFoDA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLnN0YXJmaWVsZHRlY2guY29tL3Nm
aWcyczEtOC5jcmwwWQYDVR0gBFIwUDBOBgtghkgBhv1uAQcXATA/MD0GCCsGAQUFBwIBFjFodHRw
Oi8vY2VydGlmaWNhdGVzLnN0YXJmaWVsZHRlY2guY29tL3JlcG9zaXRvcnkvMIGCBggrBgEFBQcB
AQR2MHQwKgYIKwYBBQUHMAGGHmh0dHA6Ly9vY3NwLnN0YXJmaWVsZHRlY2guY29tLzBGBggrBgEF
BQcwAoY6aHR0cDovL2NlcnRpZmljYXRlcy5zdGFyZmllbGR0ZWNoLmNvbS9yZXBvc2l0b3J5L3Nm
aWcyLmNydDAfBgNVHSMEGDAWgBQlRYFoUCY4PTstLL7Natm2PbNmYzAnBgNVHREEIDAeggtuYW1u
ZXRpcS5pboIPd3d3Lm5hbW5ldGlxLmluMB0GA1UdDgQWBBQANClvlYFFU3cAkvFQz/TxuttEUTAN
BgkqhkiG9w0BAQsFAAOCAQEAySHcxqGpgrm9HSiSIFzDOdC9BraZdjh+fIUBeKRUBmSjSByPJIHj
OGuBnY8FtuPY8/e1KhzwhZcuUhY3zwVQzbWStWLraySJyO1SzRRJC4onLbx42ARdKbRgxA/JDsmY
aTnyYq+ZOLm6XUtDweFEDkklAy2sO8gru54ogJ0iD/JyX/dgZEH/v9lGjdNFUDwG4dLz++a2Ol/U
UfqJye7Rb5UgNkewcG9KjydiTgP7Mv6m8/JjzOl31ejIVVqwz30fo+agirrIWWG2Ogtk0JUFrY73
coKTzspPszxMGN2FJpRSymtO+cqVlEuAK6/SCr2mhBvxg4GJuXuzSLp2kSrIfA==

                  </ds:X509Certificate>
               </ds:X509Data>
            </ds:KeyInfo>
         </ds:Signature>
      </saml:Assertion>
   </wst:RequestedSecurityToken>