3.9 Configuring Trusted Providers for Single Sign-On

3.9.1 Understanding the Trust Model

Setting up trust involves system administrators agreeing on how to establish a secure method for providing and consuming authentication assertions between their Identity Servers. An Identity Server is always installed as an identity provider, which is used to provide authentication to trusted service providers and ESPs. It can also be configured to be a service provider and trust the authentication of an identity provider.

Identity Providers and Consumers

An Identity Server can be configured as an identity provider, which allows other service providers to trust it for authentication. It can also be configured as a service provider, which enables the Identity Server to consume authentication assertions from trusted identity providers. Figure 3-19 depicts two Identity Servers. The Identity Server at the top of the figure is configured as an identity provider for SAML 1.1, SAML 2.0, and Liberty authentication. The Identity Server in the middle of the figure is configured as a service provider, consuming the authentication credentials of the top Identity Server. This second Identity Server is also configured as an identity provider, providing authentication for the Embedded Service Provider of the Access Gateway.

Figure 3-19 Identity Server Trust

As an administrator, you determine whether your server is to be used as the identity provider or service provider in the trust relationship. You and the trusted partner agree to exchange identity provider metadata, and then you create references to the trusted partner’s identity provider or service provider in your Identity Server configuration. You can obtain metadata via a URL or an XML document, then enter it in the system when you create the reference.

Embedded Service Providers

In addition to setting up trust with internal or external service providers, you can reference ESPs in your enterprise. An ESP uses the Liberty protocol and does not require metadata entry, because this exchange happens automatically. The ESP comes with Access Manager and is embedded in the Access Gateways. The ESP facilitates authentication between the Identity Server and the resource protected by the device, as shown in as shown in Figure 3-20.

Figure 3-20 Embedded Service Provider

Configuration Overview

The following high-level tasks describe the process required to set up the trust model between an identity provider and a service provider. Although these tasks assume that both providers are Identity Servers provided with Access Manager, similar tasks must be performed when one of the providers is a third-party application.

  1. Administrators at each company install and configure the Identity Server.

    See Creating a Cluster Configuration. (You must already be familiar with the Installing the Identity Servers in the NetIQ Access Manager 4.2 Installation and Upgrade Guide)

  2. Administrators at each company must import the trusted root certificate of the other Identity Server into the NIDP trust store.

    Click Devices > Identity Servers > Servers > Edit > Security > NIDP Trust Store, then auto import the certificate. Use the SSL port (8443) even if you haven’t set up the base URL of the Identity Server to use HTTPS.

  3. Administrators must exchange Identity Server metadata with the trusted partner.

    Metadata is generated by the Identity Server and can be obtained via a URL or an XML document, then entered in the system when you create the reference. This step is not applicable if you are referencing an ESP. When you reference an ESP, the system lists the installed ESPs for you to choose, and no metadata entry is required.

  4. Create the reference to the trusted identity provider and the service provider.

    This procedure associates the metadata with the new provider. See Creating a Trusted Service Provider.

  5. Configure user authentication.

    This procedure defines how your Identity Server interacts with the trusted provider during user authentication. Access Manager comes with default basic authentication settings already enabled. See Section 5.2, Configuring Federated Authentication.

    Additional important steps for enabling authentication between trusted providers include:

  6. (Conditional) If you are setting up SAML 1.1 federation, the protocol does not allow the target link after federation to be automatically configured. You must manually configure this setting.

    See Specifying the Intersite Transfer Service URL for the Login URL Option.

NOTE:For a tutorial that explains all the steps for setting up federation between two NetIQ Identity Servers, see Configuring Federation.

3.9.2 Configuring General Provider Settings

The following settings are global. These affect any identity providers or identity consumers (service providers) that the Identity Server has been configured to trust:

Configuring the General Identity Provider Settings

The following settings affect all identity providers that the Identity Server has been configured to trust.

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

  2. To specify identity provider settings, fill in the following fields:

    Show logged out providers: Displays logged-out providers on the identity provider’s logout confirmation page.

    Require Signed Authentication Requests: Specifies that for the Liberty 1.2 and SAML 2.0 protocols, authentication requests from service providers must be signed. When you enable this option for the identity provider, you must also enable the Sign Authentication Requests option under the Identity Consumer heading on this page for the external trusted service provider.

    Use Introductions (Publish Authentications): Enables single sign-on from the service provider to the identity provider. The service provider determines the identity providers that users are already logged into, and then selectively and automatically asks for authentication from one of the identity providers. Introductions are enabled only between service and identity providers that have agreed to a circle of trust, which means that they have agreed upon a common domain name for this purpose.

    After authenticating a user, the identity provider accesses a service at the service domain and writes a cookie to the common part of the service domain, publishing that the authentication has occurred.

    Service Domain (Local and Common): Enables a service provider to access a service at the service domain prior to authenticating a user. This service reads cookies obtained at this domain and discovers if any identity providers have provided authentication to the user. The service provider determines whether any of these identity providers can authenticate a user without credentials. The service domain must resolve to the same IP address as the base URL domain.

    For example, if an agreed-upon common domain is xyz.com, the service provider can specify a service domain of sp.xyz.com, and the identity provider can specify a service domain of idp.xyz.com. For the identity provider, xyz.com is the common value entered, and idp is the local value.

    Port: The port to use for identity provider introductions. Port 8445 for HTTPS is the default and must be opened on your firewall. If you specify a different port, you must edit the Tomcat server.xml file.

    SSL Certificate: Displays the Keystore page that you use to locate and replace the test-provider SSL certificate for this configuration.

    The Identity Server comes with a test-provider certificate that you must replace for your production environment. This certificate is used for identity provider introductions. You can replace the test certificate now or after you have configured the Identity Server. If you create the certificate and replace the test-connector now, you can save some time by restarting Tomcat only once. Tomcat must be restarted whenever you assign an Identity Server to a configuration and whenever you update a certificate key store. See Managing the Keys, Certificates, and Trust Stores.

  3. Click OK, then update the Identity Server.

Configuring a Global White List of Target URLs

URL redirection, which many applications and services require, inherently brings in security risks. While redirecting, the request can be tampered to redirect users to an external, malicious site. To prevent such issues, you can configure a list of permissible domains. Redirection is allowed only to these configured domains.

  1. Under Redirection White List, click New.

  2. Specify Domain.

    You can specify a domain name with an asterisk wildcard character (*) that represents the entire DNS subtree. For example, specifying *.example.com as a domain will allow redirection to all children domain under examle.com including example.com. The WWW prefix is not required. You can specify the * wildcard only at the lowest level of the subtree.

    For example:

    Valid domain name: *.example.com

    Invalid domain name: innerweb.*.com.

    You must configure at least one domain to prevent open redirection.

    • Liberty: The target parameter is filtered. If the requested target is not the white list, the Identity Server does not login.

    • WS-Fed: The wreply parameter is filtered. If the requested wreply is not in the white list, the Identity Server does not login. However, if wreply is same as the provider's single logout or single sign-on URL domain, the request is accepted.

    • SAML2: For idpsend, the target parameter is filtered using this list. This list is not applicable for spsend.

  3. Click OK.

Configuring the General Identity Consumer Settings

The following settings affect all identity consumers (service providers) that the Identity Server has been configured to trust.

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

  2. Specify whether the Identity Server can run as an identity consumer.

    When the Identity Server is configured to run as an identity consumer, the Identity Server can receive (consume) authentication assertions from other identity providers.

    Enable: Enables this site to function as service provider. This setting is enabled by default.

    If this option is disabled, the Identity Server cannot trust or consume authentication assertions from other identity providers. You can create and enable identity providers for the various protocols, but they are not loaded or used until this option is enabled.

    Require Signed Assertions: Specifies that all SAML assertions received by the service provider are signed by the issuing SAML authority. The signing authority uses a key pair to sign SAML data sent to this trusted provider.

    Sign Authentication Requests: Specifies that the service provider signs authentication requests sent to an identity provider when using the Liberty 1.2 and SAML 2.0 protocols.

    Use Introductions (Discover IDP Authentications): Enables a service provider to discover whether a user has authenticated to a trusted identity provider, so the user can use single sign-on without requiring authentication credentials.

    • Service domain: The shared, common domain for all providers in the circle of trust. This domain must resolve to the same IP address as the base URL domain. You must enable the Identity Consumer option to enable this field.

    • Port: The port to use for identity consumer introductions. Port 8446 for HTTPS is the default and must be opened on your firewall. If you specify a different port, you must edit the Tomcat server.xml file.

    IMPORTANT:If you enable the Use Introductions option and you want to allow your users to select which identity provider to use for authentication rather than use single sign-on, you need to configure the Introductions class. See Configuring the Introductions Class.

    SSL Certificate: Displays the Keystore page that you use to locate and replace the test-consumer SSL certificate for this configuration.

    The Identity Server comes with a test-consumer certificate that you must replace for your production environment. This certificate is used for identity consumer introductions. You can replace the test certificate now or after you have configured the Identity Server. If you create the certificate and replace the test-connector now, you can save some time by restarting Tomcat only once. Tomcat must be restarted whenever you assign an Identity Server to a configuration and whenever you update a certificate key store. See Managing the Keys, Certificates, and Trust Stores.

  3. Click OK, then update the Identity Server.

Configuring the Introductions Class

The Introduction class determines whether the user can select an identity provider to trust when the Identity Server is acting as a service provider. The default behavior is for introductions to happen automatically, thus allowing single sign-on. The Identity Server passively checks with the identity providers, one at time, to see if they can authenticate the service provider. If the identity provider can authenticate the user and the Introductions class is enabled, the user is presented with one or more cards that look similar to the following:

The small check mark indicates to the user that this is a possible card. When the user mouses over the card, the description appears. If the user selects one of these cards, the user is automatically authenticated.

To configure the Introductions class:

  1. In the Administration Console, click Devices > Identity Server > Servers > Edit > Local > Classes > Introductions.

  2. Click Properties > New, then specify the following values.

    Property Name: Specify ShowUser.

    Property Value: Specify true.

  3. Click OK.

  4. Return to the Servers page, then update the Identity Server.

  5. When you configure this class, you need to also enable the Use Introductions option. Continue with Configuring the General Identity Consumer Settings.

Configuring the Trust Levels Class

The Trust Levels class allows you to specify an authentication level or rank for class types that do not appear on the Defaults page and for which you have not defined a contract. The level is used to rank the requested type. Using the authentication level and the comparison context, the Identity Server can determine whether any contracts meet the requirements of the request. If one or more contracts match the request, the user is presented with the appropriate authentication prompts. For more information and other configuration options, see Specifying Authentication Defaults and Specifying Authentication Types

  1. In the Administration Console, click Devices > Identity Server > Servers > Edit > Local > Classes > Trust Levels.

  2. Click Properties > New, then specify the following values.

    Property Name: Specify SetClassTrustLevels.

    Property Value: Specify true.

  3. For each class type for which you want to set a level, create a property for that class.

    1. Set the Property Name to the name of the class. For example, use one of the following:

      urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
      urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol

      For additional values, refer to the SAML2 and Liberty Authentication Context Specifications.

    2. Set the Property Value to the security level or rank you want for the class. A level of 2 is higher than a level of 1.

  4. Click OK, then update the Identity Server.

3.9.3 Managing Trusted Providers

The procedure for establishing trust between providers begins with obtaining metadata for the trusted provider. If you are using the NetIQ Identity Server, protocol-specific metadata is available via a URL.

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

    For the protocol, select Liberty, SAML 1.1 or SAML 2.0.

  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. See one of the following for more information:.

    Delete: Allows you to delete the selected identity or service provider.

    Enable: Enables the selected identity or service provider.

    Disable: Disables the selected identity or service provider. When a provider is disabled, the server does not load the definition. The definition is not deleted, and at a future time, the provider can be enabled.

IMPORTANT:When selecting which protocol to use, be aware of logout behavior of the SAML 1.1 protocol. 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, the user must navigate to the identity provider that authenticated him to the SAML 1.1 service provider and log out manually.

Creating a Trusted Identity Provider

Before you can create a trusted identity 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 Managing the Keys, Certificates, and Trust Stores.

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

  • Obtained the metadata URL from the identity 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 Identity Provider’s Metadata.

  • Shared the metadata URL of your Identity Server with the identity 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 an identity provider:

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

  2. Click New, then click Identity 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 an identity 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.

    The cacerts file is located at:

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

    Windows Server 2012: \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: (SAML 1.1) 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 Identity Provider’s Metadata.

    Metadata Repositories: (SAML 1.1 and SAML 2.0) Allows you to configure several identity and/or service providers using a multi-entity metadata file available in a central repository.

  5. Click Next.

  6. Review the metadata certificates, then click OK.

  7. Configure an authentication card to use with this identity provider. Fill in the following fields:

    ID: (Optional) Specify an alphanumeric value 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.

    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 and idp.siteb.novell.com is the name of the service provider:

    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.

    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.

  8. Click Finish. The system displays the trusted provider on the protocol page.

  9. 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 Modifying a Trusted Provider.

Creating a Trusted Service Provider

You can configure 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 Identity Server acts as a service provider.

  • When you create a trusted service provider, you are configuring Identity Server to provide authentication for the service provider and 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.

The default settings of identity and service providers when you import the metadata repository are as follows:

  • SAML 1.1 Identity Provider

    • No contracts associated to Satisfiable list of IDP

    • No image selected for the IDP card

    • Login URL will be empty with Show card disabled.

    • No attribute set associated

  • SAML 1.1 Service Provider

    • No contracts associated to Satisfiable list of SP

    • No Attribute set associated

  • SAML 2.0 Identity Provider

    • Persistent Federation as the Name Identifier

    • Post Binding

    • No contracts associated to Satisfiable list of IDP

    • No image selected for the IDP card

    • No Attribute set associated

  • SAML 2.0 Service Provider

    • No contracts associated to Satisfiable list of SP

    • Post Binding

    • No Attribute set associated

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 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].

  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

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

    • SAML:

      http://10.1.1.1:8080/nidp/saml2/metadata

      https://10.1.1.1:8443/nidp/saml2/metadata

    • OIOSAML:

      http://10.1.1.1/nidp/saml2/metadata_oiosaml

      https://10.1.1.1/nidp/saml2/metadata_oiosaml

    • SAML 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 2012: \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 or 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.

  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 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 Modifying a Trusted Provider.

3.9.4 Modifying a Trusted Provider

The following sections describe the configuration options available for identity providers and service providers:

You can modify the following features of an identity provider:

You can modify the following features of a service provider:

3.9.5 Communication Security

The communication security settings control the direct communication between the Identity Server and a trusted provider across the SOAP back channel. You can secure this channel with one of three methods:

Message Signing: This is the default method, and the Identity Server comes with a test signing certificate that is used to sign the back-channel messages. We recommend replacing this test signing certificate with a certificate from a well-known certificate authority. This method is secure, but it is CPU intensive. For information about replacing the default certificate, see Managing the Keys, Certificates, and Trust Stores.

Mutual SSL: This method is probably the fastest method, and if you are fine-tuning your system for performance, you must select this method. However, it requires the exchange of trusted root certificates between the Identity Server and the trusted provider. This exchange of certificates is a requirement for setting up the trust relationship between the two providers. To verify that you have exchanged certificates, see Managing the Keys, Certificates, and Trust Stores.

Basic Authentication: This method is as fast as mutual SSL and the least expensive because it does not’ require any certificates. However, it does require the exchange of usernames and passwords with the administrator of the trusted provider, which might or might not compromise the security of the trusted relationship.

If your trusted provider is another Identity Server, you can use any of these methods, as long as your Identity Server and the trusted Identity Server use the same method. If you are setting up a trusted relationship with a third-party provider, you need to select a method supported by that provider.

For configuration information, see the following sections:

3.9.6 Selecting Attributes for a Trusted Provider

You can select attributes that an identity provider sends in an authentication request or that a service provider receives in an authentication response. The attributes are selected from an attribute set, which you can create or select from a list of already defined sets (see Configuring Attribute Sets).

For best performance, you must configure the trusted providers to use attribute sets, especially for attributes that have static values such as a user’s e-mail address, employee ID, or phone number. It reduces the traffic between the provider and the LDAP server, because the attribute information can be gathered in one request at authentication rather than in a separate request for each attribute when a policy or protected resource needs the attribute information.

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.

  1. In the Administration Console, click Devices > Identity Servers > Edit > [Protocol] > [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. Optionally, provide the name of the remote attribute and a namespace.

    5. Click OK.

      For more information about this process, see Configuring Attribute Sets.

    6. To add other attributes to the set, repeat Step 2.b through Step 2.e.

    7. Click Finish.

  3. Select an attribute set

  4. Select attributes from the Available list, and move them to the left side of the page.

    The attributes that you move to the left side of the page are the attributes you want to be obtained during authentication.

  5. Click OK twice.

  6. 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 accounts on the service provider.

  1. In the Administration Console, click Devices > Identity Servers > Edit > [Protocol] > [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. Optionally, you can provide the name of the remote attribute and a namespace.

    5. Click OK.

      For more information about this process, see Configuring Attribute Sets.

    6. To add other attributes to the set, repeat Step 2.b through Step 2.e.

    7. Click Finish.

  3. Select an attribute set

  4. Select attributes from the Available list, and move them to the left side of the page.

    The left side of the page lists the attributes that you want sent in an assertion to the service provider.

  5. Click OK twice.

  6. Update the Identity Server.

Sending Attributes to the Embedded Service Provider

You can configure the Embedded Service Provider (ESP) of the Access Gateway to receive attributes when the user authenticates. LDAP traffic is reduced and performance is improved when the required LDAP attribute values are retrieved during authentication. This improvement is easily seen when you have many users and you have configured Identity Injection or Authorization policies to protect resources and these policies use LDAP attributes or Identity Server roles.

When the authentication process does not gather the LDAP attribute values, each user access can generate a new LDAP query, depending upon how the user accesses the resources and how the policies are defined. However, if the LDAP values are gathered at authentication, one LDAP query can retrieve all the needed values for the user.

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

  2. On the Attributes page, click New, specify a name, then click Next.

  3. For each attribute you need to add because it is used in a policy:

    1. Click New.

    2. In the Local attribute drop-down list, scroll to LDAP Attribute section, then select the attribute.

    3. Click OK.

      The other fields do not need to be configured.

  4. If you use Identity Server roles in your policies, click New, select the All Roles attribute, then click OK.

  5. Click Finish.

    This saves the attribute set.

  6. Click Servers > Edit > Liberty.

  7. Click the name of the Embedded Service Provider.

    If the Embedded Service Provider is part of a cluster of Access Gateways, the default name is the cluster name. If the Access Gateway is not part of a cluster, the default name is the IP address of the Access Gateway.

  8. Click Attributes.

  9. For the attribute set, select the set you created for the Embedded Service Provider.

  10. Select attributes from the Available list, then move them to the left side of the page.

  11. Click OK, then update the Identity Server.

3.9.7 Managing Metadata

The Liberty, SAML 1.1, and SAML 2.0 protocols contain pages for viewing and reimporting the metadata of the trusted providers.

Viewing and Reimporting a Trusted Provider’s Metadata

You might need to reimport a trusted provider’s metadata if you learn that it has changed. The metadata changes when you change the provider to use HTTPS rather than HTTP and when you change the certificate that it is using for SSL. The steps for reimporting the metadata are similar for Liberty and SAML protocols.

NOTE:The trusted providers that are from the metadata repository cannot be reimported from this option. Go to Shared Settings > > Metadata Repositories and click on the metadata repository created to reimport the trusted provider.

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

  2. Click the trusted provider, then click the Metadata tab.

    This page displays the current metadata the trusted provider is using.

  3. To reimport the metadata:

    1. Copy the URL in the providerID field (Liberty) or the entityID (SAML).

    2. (SAML 1.1) Paste the URL to a file, click Authentication Card, copy the Login URL to the file, then click Metadata.

    3. Click Reimport.

    4. Follow the prompts to import the metadata.

      For the metadata URL, paste in the value you copied.

      If your Administration Console is installed with your Identity Server, you need to change the protocol from HTTPS to HTTP and the port from 8443 to 8080.

  4. Confirm metadata certificates, then click Finish, or for an identity provider, click Next.

  5. (Identity Provider) Configure the card, then click Finish.

    For SAML 1.1, copy the value you saved into the Login URL.

  6. Update the Identity Server.

NOTE:Reimport support is not available for SAML 1.1 and SAML 2.0 protocols.

Viewing Trusted Provider Certificates

You can review and confirm the certificate information for identity and service providers.

  1. In the Administration Console, click Devices > Identity Servers > Edit > [Protocol] > [Name of Provider] > Metadata > Certificates.

  2. View the following information is displayed for the certificates:

    Subject: The subject name assigned to the certificate.

    Validity: The first date the certificate was valid, and the date the certificate expires.

    Issuer DN: The distinguished name of the Certificate Authority (CA) that created the certificate.

    Algorithm: The name of the algorithm that was used to create the certificate.

    Serial Number: The serial number that the CA assigned to the certificate.

  3. Click OK if you are viewing the information, or click Next or Finish if you are creating a provider.

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.

  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.

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.

3.9.8 Configuring an Authentication Response for a Service Provider

The Liberty and SAML 2.0 protocols support slightly different options for configuring how you want the Identity Server to respond to an authentication request from a service provider. The SAML 1.1 protocol does not support sending an authentication request. However, you can configure an Intersite Transfer Service (see Using the Intersite Transfer Service) to trigger a response from the Identity Server.

When the Identity Server receives an authentication request from a trusted service provider, the request contains the conditions that the Identity Server needs to fulfill. The Authentication Response page allows you to configure how you want the Identity Server to fulfill the binding and name identifier conditions of the request, or for SAML 1.1, respond to the Intersite Transfer Service. For configuration information, see one of the following:

The Defaults page allows you to specify which contract is used when the authentication request specifies a class or type rather than a contract. For more information, see Specifying Authentication Defaults.

When the service provider sends an authentication request that specifies a specific contract, you need to ensure that the Identity Server has a the contract matches the expected URI. For information about how to configure such a contract, see Creating a Contract for a Specific Authentication Type.

3.9.9 Routing to an External Identity Provider Automatically

When the NetIQ Identity Server is configured to federate with multiple external Identity Providers, administrator can specify the list of Authentication Contracts that an external provider can execute. This configuration allows the NetIQ Identity Server (acting as service provider) to automatically select the external identity provider without the user having to click on the external provider's card.

Authentication Contracts in the NetIQ Identity Servers have been enhanced to be configured with an Authentication Class Reference. This reference can be used in federating with External Identity or Service Providers that only respond to AuthnContextClassRef in the Authentication Request and Response. For more information about setting up the contract mapping and adding contracts to the satisfiable list, see Modifying the Authentication Card for Liberty or SAML 2.0 and Configuring Authentication Contracts.

3.9.10 Using the Intersite Transfer Service

Understanding the Intersite Transfer Service URL

The Intersite Transfer Service is used by an identity provider to provide authentication to occur at a service provider that it trusts. The URLs for accessing the Intersite Transfer Service differ for each supported protocol (Liberty, SAML 1.1, and SAML 2.0). The NetIQ Access Manager identity and service provider components use the following format of the Intersite Transfer Service URL:

<identity provider URL>?PID=<entityID>&TARGET=<final_destination_URL>

The <identity provider URL> is the location where the authentication request can be processed. For an Access Manager Identity Server, the URL is the Base URL of the server that provides authentication, followed by the path to the protocol application being used for federation.

For example:

SAML 1.1: https://idp.sitea.novell.com:8443/nidp/saml/idpsend

SAML 2.0: https://idp.sitea.novell.com:8443/nidp/saml2/idpsend

Liberty: https://idp.sitea.novell.com:8443/nidp/idff/idpsend

If a third-party server provides the authentication, refer the documentation for the format of this URL.

The <entityID> is the URL to the location of the metadata of the service provider. The scheme (http or https) in the <entityID> must match what is configured for the <identity provider URL>.

For SAML 1.1 and SAML 2.0, search the metadata for its entityID value. For Liberty, search the metadata for the providerID value. Access Manager Identity Servers acting as service providers have the following types of values:

SAML 1.1: https://idp.siteb.novell.com:8443/nidp/saml/metadata

SAML 2.0: https://idp.siteb.novell.com:8443/nidp/saml2/metadata

Liberty: https://idp.siteb.novell.com:8443/nidp/idff/metadata

If you are setting up federations with a third-party service provider, refer the documentation for the URL or location of its metadata.

The <final_destination_URL> is the URL to which the browser is redirected following a successful authentication at the identity provider. If this target URL contains parameters (for example, TARGET=https://login.provo.novell.com:8443/nidp/app?function_id=22166& amp;Resp_Id=55321 &amp;Resp_App_Id=810&amp;security_id=0), the URL must be encoded to prevent it from being truncated.

For example:

  • SAML 1.1: https://idp.sitea.novell.com:8443/nidp/saml/idpsend?PID=https://idp.siteb.novell.com:8443/nidp/saml/metadata&TARGET=https://eng.provo.novell.com/saml1/myapp

  • SAML 2.0: https://idp.sitea.novell.com:8443/nidp/saml2/idpsend?PID=https://idp.siteb.novell.com:8443/nidp/saml2/metadata&TARGET=https://eng.provo.novell.com/saml2/myapp

  • Liberty: https://idp.sitea.novell.com:8443/nidp/idff/idpsend?PID=https://idp.siteb.novell.com:8443/nidp/idff/metadata&TARGET=https://eng.provo.novell.com/liberty/myapp

To read more about configuring an intersite URL, see Configuring an Intersite Transfer Service Target for a Service Provider.

If you configure an Intersite Transfer Service URL for an Identity Server that is the Access Manager Identity Server and the service provider is either another Identity Server or a third-party server, you can simplify the Intersite Transfer Service URL to the following format:

<identity provider URL>?id=<user_definedID>

For example:

  • SAML 2.0: https://test.blr.novell.com:8443/nidp/saml2/idpsend?id=testsaml2&TARGET=https://eng.provo.novell.com

  • SAML 1.1: https://testsb.blr.novell.com:8443/nidp/saml/idpsend?id=testsaml&TARGET=https://eng.provo.novell.com

  • Liberty: https://testsb.blr.novell.com:8443/nidp/idff/idpsend?id=libertytest&TARGET=https://eng.provo.novell.com

If the Allow any target option is enabled and if the Intersite Transfer Service URL has a target value, then the user is redirected to target URL.

The Intersite Transfer Service URL for SAML 2.0 will be https://testsb.blr.novell.com:8443/nidp/saml2/idpsend?id=testsaml2&TARGET=http://www.google.com where http://www.google.com is the target URL.

NOTE:Depending on the usage, the target parameter serves different purpose. It is case-sensitive.

  • target: Specifies the idpsend URL with a contract id.

  • TARGET: Specifies URL of the final destination.

Use case: If authentication with a particular contract is enabled in Intersite URL, you are redirected to the default target URL. Use the following format: http(s)://<$idp_host_name>/nidp/app?id=<$contract_to_be_executed>&target=http(s)://<$idp_host_name>/nidp/saml2/idpsend?id=<$saml_sp_identifier>.

For more information, see How to access an Identity Server Intersite Transfer URL with a specific contract.

NOTE:The contract_to_be_executed is executed by the Identity Server and is case sensitive.

For example, https://www.idp.com:8443/nidp/app?id=npbasic&target=https://www.idp.com:8443/nidp/saml2/idpsend?id=serviceprovider1.

How it works?

In the above example, identity provider authentication is done with the contract id npbasic. You are now redirected to the service provider by using the saml_sp_identifier id (serviceprovider1). After authentication (if configured with persistent federation), the page redirects you to the available default target, or to the nidp login page of the service provider.

For configuration and ID information, see Configuring an Intersite Transfer Service Target for a Service Provider.

In the Intersite Transfer Service URL, id can be used for the following purposes:

  1. To simplify the intersite URL.<identity provider URL>?id=<user_definedID>

  2. To execute a particular contract in the Identity Server login service with intersite URL.

    http(s)://<$idp_host_name>/nidp/app?id=<$contract_to_be_executed>&target=http(s)://<$idp_host_name>/nidp/saml2/idpsend?id=<$saml_sp_identifier>

Specifying the Intersite Transfer Service URL for the Login URL Option

Liberty and SAML 2.0 support a single sign-on URL. Because SAML 1.1 does not support a single sign-on URL, you need to specify the Intersite Transfer Service URL in the Login URL option on the authentication card for the SAML 1.1 identity provider:

Figure 3-21 SAML 1.1 Authentication Card

For a card to appear as a login option, you must specify a Login URL and select the Show Card option. Figure 3-22 illustrates a possible configuration that requires the Intersite Transfer Service for the SAML 1.1 protocol.

Figure 3-22 Federated Identity Configuration

If you want a card to appear that allows the user to log in to Site A (as shown in Figure 3-21), you need to specify a value for the Login URL option.

Using the DNS names from Figure 3-22, the complete value for the Login URL option is as follows:

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

The following happens when this link is invoked:

  1. The browser performs a Get to the identity provider (Site A).

  2. If the identity provider (Site A) trusts the service provider (Site B), the identity provider prompts the user for authentication information and builds an assertion.

  3. The identity provider (Site A) sends the user to the service provider (Site B), using the POST or Artifact method.

  4. The service provider (Site B) consumes the assertion and sends the user to the TARGET URL (the user portal on Site B).

To configure the settings for the intersite transfer service, see Modifying the Authentication Card for SAML 1.1.

Using Intersite Transfer Service Links on Web Pages

The Intersite Transfer Service URL can be used on a Web page that provides links to various protected resources requiring authentication with a specific identity provider and a specific protocol. Links on this Web page are configured with the URL of the Intersite Transfer Service of the identity provider to be used for authentication. Clicking these links directs the user to the appropriate identity provider for authentication. Following successful authentication, the identity provider sends a SAML assertion to the service provider. The service provider uses the SAML assertion to verify authentication, and then redirects the user to the destination URL as specified in the TARGET portion of the Intersite Transfer Service URL.

Below are sample links that might be included on a Web page. These links demonstrate the use of SAML 1.1, SAML 2.0, and Liberty formats for the Intersite Transfer Service URL:

SAML 1.1: <a href="https://idp.sitea.novell.com:8443/nidp/saml/idpsend?PID=https://idp.siteb.novell.com:8443/nidp/saml/metadata&TARGET=https://eng.provo.novell.com/saml1/myapp">SAML1 example</a>

SAML 2.0: <a href="https://idp.sitea.novell.com:8443/nidp/saml2/idpsend?PID=https://idp.siteb.novell.com:8443/nidp/saml2/metadata&TARGET=https://eng.provo.novell.com/saml2/myapp">SAML2 example</a>

Liberty: <a href="https://idp.sitea.cit.novell.com:8443/nidp/idff/idpsend?PID=https://idp.siteb.novell.com:8443/nidp/idff/metadata&TARGET=https://eng.provo.novell.com/liberty/myapp">Liberty example</a>

Figure 3-23 illustrates a network configuration that could use these sample links.

Figure 3-23 Using the Intersite Transfer Service URL

In this example, Site Z places links on its Web page, using the Intersite Transfer Service URL of Site A. These links trigger authentication at Site A. If authentication is successful, Site A sends an assertion to Site B. Site B verifies the authentication and redirects the user to the myapp application that it is protecting.

When defining the intersite transfer URL within the Administration Console, you can define an id and target for the SAML service provider (SP) you are accessing. For more information about accessing an Identity Server intersite transfer URL with a specific contract, see TID 7005810.

Configuring an Intersite Transfer Service Target for a Service Provider

If you have created Web pages that have links that specify a Intersite Transfer Service URL (see Using Intersite Transfer Service Links on Web Pages), you can have the Identity Server control the TARGET parameter.

  1. Click Devices > Identity Servers > Edit > [Liberty, SAML1.1, or SAML 2.0] > [Service Provider] > Intersite Transfer Service.

  2. Fill in the following:

    ID: (Optional) Specify an alphanumeric value that identifies the target.

    If you specified an ID for the target, you can use this value to simplify the Intersite Transfer URL that must be configured at the service provider. This is the <user_definedID> value in the following format for the Intersite Transfer URL.

    <identity provider URL>?id=<user_definedID>

    The ID specified here allows the Identity Server to find the service provider’s metadata.

    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. NetIQ recommends you to specify a default target URL, for example, https://www.serviceprovider1.com.

    Allow any target: You can either select or not select this option.

    • When you select this option,

      • if the Intersite Transfer URL has a target value, then the user is sent to target url.

      • if the Intersite Transfer URL does not have a target value, then the user is sent to the configured target, that is, www.serviceprovider1.com.

    • When you do not select this option,

      • if the Intersite Transfer URL has a target value, then the user is sent to the target www.serviceprovider1.com irrespective of the target mentioned in the Intersite Transfer URL.

      • if the Intersite Transfer URL does not have a target value, the user is sent to www.serviceprovider1.com.

  3. Click OK twice.

  4. Update the Identity Server.

Configuring Whitelist of Target URLs

Redirection, which is required by many applications and services, inherently brings in a security risk. Redirects are dangerous because unsuspecting users who are visiting trusted sites can be redirected to malicious sites that exploit the users' trust. A new featured, called whitelist, has been added that restricts target URLs to specific domains.

The whitelist feature allows you to restrict target URLs to URLs which match the domains in the whitelist. Any target URLs that use a domain that is not in the list are blocked and the user receives the following error message: The request to provide authentication to a service provider has failed (outsidedomain.com-89F57BF823DFE551).

  1. Click Devices > Identity Servers > Edit > [Liberty, SAML1.1, or SAML 2.0] > [Service Provider] > Intersite Transfer Service.

  2. In the Domain List, click New.

  3. Enter the domain name, then click OK.

    The domain name must be a full domain name, such as www.novell.com. Wildcard domain names, such as www.novell.*.com, do not work.

  4. To edit an existing domain name, click the name, modify the name, then click OK.

  5. To delete an existing domain name, select the check box by the domain, click Delete, then click OK to delete or Cancel to close the window.

  6. Click OK.

  7. Update the Identity Server.

Validating Incoming Authentication Request for Assertion Consumer Service URL

When an authentication request from a service provider is not signed, Identity Provider cannot validate the authenticity and integrity of the request. So any malicious user who can intercept the request can change the Assertion Consumer Service URL in the request and make the Identity Provider to send the assertion to malicious sites.

To secure and validate the authentication request from the service provider, you can use the following options in the service provider configuration of Identity provider:

NOTE:These options must be defined to avoid security issues during an unsigned SAML Authentication Request.

SAML2_ACS_URL_RESTRICT : This option ensures Identity Provider will validate the Assertion Consumer Service URL in the request against the trusted metadata URL before sending the assertion. So if the Assertion Consumer URL in the Authentication Request is tampered by any malicious user, Identity Provider terminates the request and assertion will not be sent.

SAML2_ACS_DOMAIN_WHITELIST: This option ensures Identity Provider will validate the Assertion Consumer Service URL in the request against a white list of domains. If the Assertion Consumer Service URL is not matching with any of the domain URLs in the white list, request is terminated by the Identity Provider.

You must define SAML2_ACS_DOMAIN_WHITELIST along with SAML_ACS_URL_RESTRICT for a service provider in Identity Provider because this option does not work if SAML_ACS_URL_RESTRICT is not enabled.

To define these options, perform the following in Administration Console:

  1. Click Devices > Identity Servers > IdP Cluster > SAML2.

  2. Select the required service provider from the Service Providers list.

  3. Click Options.

  4. Click New, then select OTHER from the drop down list.

    1. If you want Identity Provider to allow authentication only to the trusted ACS URLs, specify the following:

      Property Name: SAML2_ACS_URL_RESTRICT

      Property Value: true

    2. If you want Identity Provider to perform additional validation of the authentication request with the ACS domain whitelist, specify the following:

      Property Name: SAML2_ACS_DOMAIN_WHITELIST

      Property Value: Domain names separated with semi-colon(;) and no space. For example, www.airlines.com;www.example.com.

Federation Entries Management

Identity federation is the association of accounts between an identity provider and a service provider.

Step up Authentication Example for an Identity Provider Initiated Single Sign-On Request

Setup: Let us assume that:

  • NetIQ Access Manager is acting as an identity provider.

  • The following three contracts in the identity provider are configured:

    • name password basic contract with Authentication level as 10

    • name password form contract with Authentication level as 20

    • secure name password contract with Authentication level as 30

      NOTE:Enable the Satisfiable by a contract of equal or higher level option for contracts with authentication level 10 or 20 to avoid prompting for authentication when a user is already authenticated against the contract with level 30.

  • The name password form contract for a service provider named SP_A is configured in the identity provider.

    For more information about creating and configuring the contracts, see Configuring Authentication Contracts.

Configuration: Complete the following steps:

  1. In the NetIQ Identity Server, configure the service provider as a trusted provider.

    For more information, see Managing Trusted Providers.

  2. In the service provider, configure the NetIQ Identity Server as a trusted provider.

    For more information, see Managing Trusted Providers.

  3. In the NetIQ Identity Server, configure the service provider with the required authentication contracts.

For information about how to configure a service provider, see Defining Options for SAML 2.0, To Define Options for Liberty Service Provider andDefining Options for SAML 1.1 Service Provider.

Results: The following are the four possible scenarios:

  • If the user was authenticated with the name password basic contract before making an Intersite Transfer Service request to SP_A, the identity provider will step up to the name password form authentication.

  • If the user was authenticated with the name password form contract before making an Intersite Transfer Service request to SP_A, the identity provider will not ask for the authentication.

  • If the user was authenticated with the secure name password contract before making an Intersite Transfer Service request to SP_A, the identity provider will not ask for the authentication.

  • If the user is not authenticated while making an Intersite Transfer Service request to SP_A, the identity provider will step up to the name password form authentication.

The following diagram illustrates the workflow:

Workflow:

  1. User tries to authenticate in the identity provider.

  2. User is prompted to authentication using the Name Password Basic contract.

  3. User enters the credentials.

  4. The Name Password Basic contract is authenticated in the identity provider and added to the user session.

    The Name Password Basic contract is the default contract in the identity provider.

  5. User logs into the identity provider.

  6. User makes an Intersite Transfer Service request to SP_A.

  7. The identity provider prompts for the authentication using the Name Password Form contract.

  8. User enters the credentials.

  9. The Name Password Form contract is authenticated in the identity provider and added to the user session.

  10. User is redirected to SP_A.

NOTE:For information about service provider initiated single sign-on and its example, see Contracts Assigned to a SAML 2.0 Service Provider.

URL Query String Parameters

The following table lists query string parameters and their descriptions:

Parameter

Description

id

While defining the Intersite Transfer Service URL, you can define an id and target for the SAML service provider being accessed.

For example, if you defined the id as testsaml and TARGET as URL of service provider, the login URL is https:// <identity provider server >:<port>/nidp/saml/idpsend?id=testsaml&TARGET=<URL of service provider>.

If TARGET is not specified, the login URL is https:// <identity provider server >:<port>/nidp/saml/idpsend?id=testsaml.

PID

You can use this parameter when another provider is added and an Intersite Transfer Service id is not defined.

For example, the login URL in this case can be https:// <identity provider server >:<port>/nidp/saml/idpsend?PID=<https://identity provider server>:8443/nidp/saml/metadata&TARGET=<URL of service provider>.

target

Specifies the idpsend URL with a contract ID.

If authentication with a particular contract is enabled in the Intersite Transfer Service URL, you are redirected to the default target URL.

Use the following format: http(s)://<$idp_host_name>/nidp/app?id=<$contract_to_be_executed>&target=http(s)://<$idp_host_name>/nidp/saml2/idpsend?id=<$saml_sp_identifier>.

For example, https://www.idp.com:8443/nidp/app?id=npbasic&target=https://www.idp.com:8443/nidp/saml2/idpsend?id=serviceprovider1.

TARGET

Specifies URL of the final destination. Format of the URL: <identity provider URL>?PID=<entityID>&TARGET=<final_destination_URL>

For example, https://<identity provider url/nidp/saml2/idpsend?id=testsaml2&TARGET=http://www.google.com. Here http://www.google.com is the destination.