5.2.4 Configuring SAML 2.0

Access Manager has two different ways of configuring a SAML 2.0 federated connection for single sign-on to external web services and applications. The heritage way still works and that is what is covered in the following sections. The new way of creating a federated SAML 2.0 connection is to use the predefined SAML 2.0 connector templates that simplify the configuration process. For more information, see Understanding Federated Single Sign-On with SAML 2.0 in the Access Manager Applications Configuration Guide 4.4.

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.

Identity Server allows SAML assertions to be exchanged with trusted service providers that use 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 website.

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

Attribute Mapping with Liberty

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

To interoperate with trusted service providers through the SAML protocol, Identity Server distinguishes between different attributes from different SAML implementations. Access Manager uses Liberty attributes in the SAML administration. When you specify which attributes to include in an assertion, or which attributes to use when locating the user from an assertion, these attributes must always be specified in the Liberty format.

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

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

Trusted Provider Reference Metadata

Identity Server generates metadata for server communication and identification. You can obtain metadata through URL or XML document and then enter it in the system while creating the reference. Metadata is traded with federation partners and supplies various information regarding contact and organization information located at 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. 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.

Authorization Services

When a user has authenticated to a site or application, the user has access to a resource controlled by a Policy Enforcement Point (PEP). The PEP checks for user access to the desired resource. The user is either granted or denied access to the resource. SAML is used as the communication mechanism between the PEP and a Policy Decision Point (PDP). In NetIQ product terminology, a PEP could be thought of as the NetIQ Access Gateway, and the PDP as the NetIQ Identity Server.

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-9 SAML Service Provider Process Flow

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

    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. Identity Server processes attributes as follows:

    1. The server looks up for 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. 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 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. Identity Server uses the PP service to look up the values for the user’s PP: sn and PP: ph# attributes.

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

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

    Identity Server now has the information to generate a SAML assertion. Identity Server sends an HTTP redirect containing the artifact 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 Identity Server.

  5. 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) 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-10 SAML Consumer Process Flow

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

    This generates a SAML assertion intended for 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 Identity Server looks similar to the following:

    http://nidp.com/auth/afct?TARGET=http://abc.com/index.html&SAMLArtifact =<<artifact>>
  2. Identity Server at abc.com receives the assertion.

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

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

    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 must be used for this purpose. In this case, the you specified that PP: sn and PP: ph# must be used.

    1. 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 Identity Server.

    2. 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, Identity Server knows that the service provider’s names for these attributes are lastname and phonenumber, respectively.

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

      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 Identity Server, and the user is authenticated.

  4. The user’s DN is returned to 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 server metadata, so you must determine these 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. An identity provider uses the incoming metadata to determine how to respond.

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

  1. Click Devices > Identity Servers > Edit > SAML 2.0 > Profiles.

  2. Specify the following details 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 URL 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 SAML requester and responder communicate through an HTTP user agent. This occurs when the communicating parties do not share a direct path of communication. You also use this when the responder requires user interaction 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 options:

    • 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 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 you enable the Show logged out providers option (Identity Servers > Edit > Identity Providers) with HTTP Post profile, Access Manager does not complete a logout request from the service provider. This occurs because of 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 providers 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 provider 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 options:

    • 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 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 Identity Server.

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

Managing a SAML 2.0 Service Provider

Topics include:

Creating a SAML 2.0 Service Provider

See Creating a Trusted Service Provider.

Creating Different Instances of a SAML 2.0 Service Provider in an Identity Server Cluster

You can create different instances of the same SAML 2.0 service provider in an Identity Server instead of having separate Identity Server for each instance.

Consider a scenario where a service provider requires different SAML 2 policies to be defined for different set of users. With Access Manager 4.3 or earlier, you had to set up multiple Identity Server clusters to specify different policies for different set of users of same service provider.

With Access Manager 4.4 and later, you need one Identity Server cluster to specify different policies for different set of users of the same service provider.

When you import a service provider for the second time in the same Identity Server cluster, you will be prompted to enter a unique ID. Access Manager uses this unique ID to change its metadata for a specific instance of service provider. This helps Access Manager to recognize which policy should be used for each SAML2 request coming from the same service provider. To import the same service provider subsequently, add Unique ID for different instances and ensure that the ID is unique and not used by any instance of any service provider. To understand the changes and how Access Manager uses the unique ID, refer to the following example:

An Office 365 service provider has two domains namely, abctest.com and abc.com. For any number of domains that are created in Office 365 the entity ID will be same.

If the Office 365 service provider uses Access Manager as the identity provider, perform the following:

  • Import Office 365 for the first instance with the domain abc.com.

    The Access Manager metadata contains the following:

    The entity ID: entity ID="https://www.idp.com:8443/nidp/saml2/metadata"

    The SSO endpoint: <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.idp.com:8443/nidp/saml2/sso>

  • Import Office 365 for the second instance with domain abctest.com, Access Manager will prompt for a unique ID. If the unique ID is uid, Access Manager generates a new metadata that includes separate entity ID and endpoint URLs for the domain abctest.com.

    The generated metadata will contain the following and this metadata must be imported by Office 365:

    For entity ID: entity ID="https://www.idp.com:8443/nidp/saml2/metadata?namInstance=uid"

    For SSO endpoint: <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.idp.com:8443/nidp/saml2/sso?uniqueId=uid"/>

    Similarly, all other endpoints will include uid as mentioned in the preceding SSO endpoint.

    This metadata must be imported by the service provider.

    The unique ID, uid in entityID helps a service provider to recognize the Identity Server as a separate entity. The uid specified for a SAML 2 endpoint is for the Identity Server to recognize the service provider as a separate entity. Hence, the service provider must import the metadata specified in the Identity Server cluster for each domain.

The unique ID configuration is available only when you add the trusted service provider whose metadata is already imported. For information about creating a unique ID for different instances of a service provider, see Creating a Trusted Service Provider.

NOTE:After the federation if you change the unique ID, Access Manager’s metadata gets changed for the service provider. The metadata URL will not be same as the entity ID. The metadata link is displayed within a note mentioned on the Trust tab of the trusted service provider page in the Administration Console.

Hence, the service provider must ensure to re-import the Access Manager metadata.

Minimizing Service Interruption of SAML 2.0 Service Providers

In a SAML 2 federation, Identity Server and the service provider sign their messages using their respective signing certificates. These message signatures are verified by both trusted providers before processing a SAML 2 request. If these signing certificates expire, the federation does not work as expected. The administrators have to exchange the new certificates to resume federation services. When the signing certificate expires, the administrator has to update the certificates and the metadata that results in interruption of the services, impacting the business continuity.

To continue with the services of SAML 2 service providers without impacting the continuity of the services, Access Manager provides the following provisions:

Include an Additional Signing Certificate

You can add an additional signing certificate as a secondary certificate that will be used when the default signing certificate expires. For example, if the default certificate is valid from January to June and secondary certificate is valid from May to October, then when the default certificate expires in June, Identity Server will automatically switch to use the secondary certificate. Hence, there is no interruption in federation service between the service provider and Identity Server.

For information about adding a secondary certificate, see Configuring Communication Security for a SAML 2.0 Service Provider and Editing a SAML 2.0 Service Provider’s Metadata.

Update the Settings of Trusted Service Provider

After modifying any settings of SAML 2 trusted service providers in Identity Server, you can update the modified settings of trusted provider instead of updating the complete Identity Server cluster configuration settings. Updating all the Identity Server cluster configurations takes a longer time, which interrupts the services of the service provider. Access Manager updates the changes done for SAML 2 trusted providers without impacting other configurations of the Identity server cluster. To update the settings of trusted service provider, perform the following in Administration Console:

  1. Click Devices > Identity Servers.

  2. Click Update All next to the required Identity Server or cluster.

    The SAML2 Trusted Provider Update option is selected. This option ensures that only the settings that are changed in the Identity Server for the SAML 2 trusted provider will be updated.

    NOTE:

    • This option will be displayed for updating Identity Server when a trusted service provider setting is changed without changing Unique ID and Provider ID.

    • If you modify a certificate that is assigned to multiple service providers, the certificate changes done for a single service provider will change it for all service providers even when a specific SAML 2 trusted provider is updated.

    • If you change the Attributes setting, you must perform update for complete Identity Server cluster configuration.

  3. Click OK to update with the specified option else click Cancel.

    Clicking OK ensures that the services are operational with immediate effect because updating the specific trusted service provider settings take lesser time than updating an Identity Server cluster.

Contracts Assigned to a 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, Identity Server executes a default contract for validating the user. You can use the step-up authentication 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 a SAML 2.0 service provider:

Figure 5-11 Step-up authentication example with two applications

Two web applications Payroll Portal and HR Portal that are protected through different service providers use Access Manager Identity Server as an identity provider. A user wants to use the name/password form contract whenever the user accesses the HR application and wants to use the higher level contract X509 for the Payroll application. 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 a service provider:

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

  2. Click the 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 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 is sent in the response.

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

C1 is executed for validating the user and C1 is sent in the response.

Service provider requests execution of contract C1 at Identity Server

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

C1 is executed for validating the user and C1 is sent in the response.

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

C1 is executed for validating the user and C1 is sent in the response.

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

C2 is executed for validating the user and C2 is sent in the response.

NOTE:C1 is not considered to be executed in this case.

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 is executed and C2 is sent in the response.

If trust level of C2 < trust level of C1, then C1 is executed and C1 is sent in the response.

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

NOTE:When using the service provider (SP) initiated login with a SAML 2.0 SP federation, the SP configuration can impact the selection of the Access Manager contract for authentication depending on the values sent in SAML authentication request. To make it work properly, you must define your Access Manager contract URI to match with the request sent by the service provider.

For more information, see Allowable Class in Section 5.1.4, Configuring Authentication Contracts.

Configuring A SAML 2.0 Authentication Response

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

  1. 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 enhanced security by using a back-channel communication between two servers. Select Post to use HTTP redirection for the communication channel between two servers. If you select Post, you might require the signing of the authentication requests. See Configuring the General Identity Provider Settings.

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

    1. Click Devices > Identity Servers > Edit > Options > New.

    2. Select IS SAML2 POST INFLATE in Property Type and true in Property Value. This provider will receive deflated SAML2 POST messages from its trusted providers.

    3. Click OK.

    4. Click Devices > Identity Servers > Edit > SAML 2.0 > Service Provider or Identity Provider> Options > New.

    5. Select SAML2 POST DEFLATE TRUSTEDPROVIDERS in Property Type and specify trusted providerʹs name, metadata URI, or provider ID in Property Value. You can specify multiple trusted providers in a comma separated format. These are the trusted providers who expect SAML2 POST messages in deflated format.

    6. Click OK.

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

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

    • 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 Identity Server must send if the service provider does not specify a format.

    If you select E-mail, Kerberos, x509, or unspecified as the default format, you must 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 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 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, deselect Use proxied requests. When the option is not selected and Identity Server cannot authenticate the user, the user is denied access.

    When this option is selected, Identity Server verifies if other identity providers can satisfy the request. If yes, the user is allowed to select the identity provider to perform the authentication. If a proxied identity provider performs the authentication, it sends the response to Identity Server. Identity Server then sends the response to the service provider.

  7. If you select Include the Session Timeout attribute in the assertion, Identity Server sends 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 > OK, then update Identity Server.

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

Access Manager service provider federation profiles do not allow control based authorization policies. Usually, the service providers enforce authorization rules. However, every service provider does not 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. Identity Server evaluates service providers and generates assertions.

Scenario: Company xyz.com uses a CRM application that is protected through a SAML 2.0 service provider. This application must only be accessible to the sales team. Whenever a user accesses the application through the service provider, it redirects to Identity Server for validating the user.

Figure 5-12 Executing Authorization Policy Based on Role

Identity Server authenticates the user and then verifies whether the user is a member of the sales team. If yes, Identity Server sends a successful assertion to the service provider. Else, Identity Server sends an error response to the service provider.

By default, Identity Server executes these authorization policies after a user is authenticated during spsend. Set the ALLOW_AUTH_POLICY_EXECUTION option to false to disable Identity Server to execute the authorization policies. For information about how to set this option, see Configuring Identity Server Global Options.

If the authorization policy is configured to deny execution, 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.

Editing a SAML 2.0 Service Provider’s Metadata

See Editing a SAML 2.0 Service Provider’s Metadata.

Configuring Communication Security for a SAML 2.0 Service Provider

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

  1. Click Devices > Identity Servers > Edit > SAML 2.0.

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

    Specify the following details:

    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. You can add a secondary signing certificate that can be used when the default signing certificate expires.

    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.

      To add a secondary certificate, click the Add (+) icon, select a certificate from the keystore, then click Assign to SP.

      You can delete the secondary certificate but not the primary certificate. Access Manager uses primary certificate. If it is expired Access Manager checks for secondary certificate. If the secondary certificate is available, Access Manager automatically switches to use the secondary certificate. If the primary certificate is deleted, secondary certificate becomes primary certificate.

    • 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 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 have the following default metadata URL: <IDP URL>/nidp/saml2/metadata.

      The custom certificates 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. Select periodicity to validate the certificate.

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

    • Message Signing: Relies upon message signing by 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.

  3. Click OK twice.

  4. Update Identity Server.

    If you want to update only the metadata for a specific service provider, you can select Devices > Identity Servers > Update All > SAML2 Trusted Provider Update > OK.

Managing a SAML 2.0 Identity Provider

Topics include:

Creating a SAML 2.0 Identity Provider

See Creating a Trusted Identity Provider.

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 Identity Server.

  1. 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 must 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 must 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. Click Devices > Identity Servers > Edit > Options > New.

    2. Select IS SAML2 POST INFLATE in Property Type and true in Property Value.

    3. Click OK.

    4. Click Devices > Identity Servers > Edit > SAML 2.0 > Service Provider or Identity Provider> Options > New.

    5. Select SAML2 POST DEFLATE TRUSTEDPROVIDERS in Property Type and enter trusted providerʹs name, metadata URI, or provider ID in Property Value. 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.

    6. Click OK.

    7. Restart 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 must 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 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, 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, 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, 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 Communication Security for a SAML 2.0 Identity Provider

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

  1. Click Devices > Identity Servers > Edit > SAML 2.0.

  2. Click the name of an identity provider.

  3. On the Trust page, specify the following details:

    Name: 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 by 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 > OK.

  5. Update Identity Server.

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 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. Click Devices > Identity Servers > Servers > Edit > Liberty or SAML 2.0 > Identity Provider > Options.

  2. Click New.

  3. Select Other in Property Type.

  4. Specify the following values:

    Property Name: config.aselect.sessionsync.enabled

    Property Value: true

  5. For session synchronization, add two options, one to enable the session synchronization and the other to provide the URL to which synchronization message must be sent.

    The session synchronization message is sent from the Access Manager service provider to the A-Select identity provider, in tandem with Access Gateway ESP's activity update. The session synchronization message is sent only if the user session is active at 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.

  6. Click OK, then update 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. To use this profile, you must use a front channel binding.

This section includes the following topics:

Defining Options for a SAML 2.0 Identity Provider

  1. Click Devices > Identity Servers > Servers > Edit > SAML 2.0 > Identity Provider > Options.

  2. Select the required options:

    OIOSAML Compliance: Select this option to make the identity provider OIOSAML compliant.

    Enable Front Channel Logout: Select this option to enable a enable a service provider to initiates a logout at the identity provider by using the HTTP Redirect method.

  3. Click New to set SAML properties for an identity provider. The following table lists the available properties:

    NOTE:Access Manager 4.2 onwards, configuring the following options through files is deprecated. You must configure these option by using Administration Console.

    Property Type

    Property Value

    Extensions

    Specify the value in this format: <samlp:Extensions>. This value is sent in the authentication request to this identity provider.

    SAML ASSERTION INCLUDE MILLISECS

    Select true to get SAML requests for this identity provider including the timestamp in millisecond in IssueInstant.

    SAML2 ATTRIBUTE CONSUMING INDEX

    Select the value of AttributeConsumingServiceIndex in SAML requests to this identity provider from the specified integer value.

    You can provide the value in the format specified in the following example:

    For default value: default->10

    For protected resource URL: https://www.example.com:446/test/Test/test.php->2

    For contract: urn:oasis:names:tc:SAML:2.0:ac:classes:ID->3,

    SAML2 AVOID CONSENT

    Select true to not include Consent as part of the SAML 2.0 request to this identity provider.

    SAML2 AVOID ISPASSIVE

    If you select true, IsPassive is not included in SAML 2.0 request to this identity provider.

    SAML2 AVOID NAMEIDPOLICY

    If you select true, NameIDPolicy is not included in a SAML 2.0 request to this identity provider.

    SAML2 AVOID PROTOCOLBINDING

    If you select true, ProtocolBinding is not included in a SAML 2.0 request to this identity provider.

    SAML2 AVOID PROXYCOUNT

    If you select true, ProxyCount is not included in a SAML 2.0 request to this identity provider.

    SAML2 AVOID SIGN AND VALIDATE ASSERTIONS TRUSTED PROVIDERS

    If you select true, the cluster will accept SAML 2.0 POST responses from this provider when the response is signed and assertion is not.

    SAML2 CHANGE ISSUER

    Specify the provider ID to be sent as issuer in the SAML requests to this identity provider.

    The value is in 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 CUSTOM AUTHNCONTEXT CLASS REF LIST

    Set this option to specify custom authentication class references. Use delimiter & to specify more than one class reference. The value of this property is set to the value of AuthnContextClassRef element of AuthnRequest.

    For example, if you set SAML2 CUSTOM AUTHNCONTEXT CLASS REF LIST as property name and the value as urn:federation:authentication:windows, then the value of AuthnContextClassRef will be urn:federation:authentication:windows.

    SAML2 NAMEIDPOLICY ALLOWCREATE

    Select true to create ALLOWCREATE attribute in the NAMEIDPOLICY element of AuthnRequest.

    SAML2 POST DEFLATE TRUSTEDPROVIDERS

    If you select true, the cluster will send deflated post messages to this provider.

    SAML2 SEND ACS INDEX

    Select true to send AssertionConsumerServiceIndex with AuthnRequest to this identity provider.

    SAML2 SEND ACS URL

    Select true to send AssertionConsumerServiceURL with AuthnRequest to this identity provider.

    SAML2 SIGN METHODDIGEST SHA256

    The default algorithm that is used as signing algorithm for SAML 2 assertions is SHA256. Set the value to false if you want to use SHA1 algorithm as signing algorithm for assertions.

    OTHER

    Specify Property Name and Value if you want to configure any other property for this identity provider.

    SAML2 RESPONSE AVOID REMOVE EXTRANEOUS NAMESPACES: Select true to have assertion name space in a SAML message and assertion.

  4. Click OK > Apply.

Sample XML File When All SAML Options Are Set to True

<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 Options Are Set to False

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

Defining Options for a SAML 2.0 Service Provider

You can use Access Manager as an identity provider for several service providers.You can configure a specific authentication contract that is required for a service provider. If you have configured more than one authentication contract for a service provider, the contract with minimum level is selected.

When providing authentication to a service provider, Identity Server ensures that the user is authenticated by the required contract. When a user is not authenticated or when a user is authenticated, but the authenticated contracts do not satisfy the required contracts, user is prompted to authenticate with the required contract. This is called step up authentication.

If no required contract is configured, then the default contract is executed.

NOTE:For SAML 2.0, this step up authentication is supported for Intersite Transfer Service (for both identity provider initiated and service provider initiated requests). For Liberty, it works only for identity provider initiated requests.

Perform the following steps to define options for a SAML 2.0 service provider:

  1. 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 option.

  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:Only the contract that is configured first in the Selected contracts list will be executed. This is applicable only for SAML 2.0.

  4. Click New.

    The following table lists the available properties:

    NOTE:Access Manager 4.2 onwards, configuring the following options through files is deprecated. You must configure these option by using Administration Console.

    Property Type

    Description

    SAML ASSERTION INCLUDE MILLISECS

    Select true to get SAML responses for this service provider including the timestamp in millisecond in IssueInstant.

    SAML2 AVOID AUDIENCE RESTRICTION

    Select true to avoid sending the audience restriction information with assertion to this service provider.

    SAML2 AVOID AUTHNCONTEXT CLASS REFERENCE

    Set this to true to exclude AuthnContextClassRef as part of the SAML 2.0 assertion response for this service provider.

    SAML2 AVOID AUTHNCONTEXT DECLARATION REFERENCE

    Set this to true to exclude AuthnContextDeclRef as part of the SAML 2.0 assertion response for this service provider.

    SAML2 AVOID CONSENT

    Select true to not include Consent as part of the SAML 2.0 request.

    SAML2 AVOID SIGN AND VALIDATE ASSERTIONS TRUSTED PROVIDERS

    If you select true, the cluster will sign SAML 2.0 POST responses (excluding the assertion) for this provider.

    SAML2 AVOID SPNAMEQUALIFIER

    Select true to not include SPNAMEQUALIFIER in NAMEIDENTIFER in the assertion.

    SAML2 AVOID SPNAMEQUALIFIER TO

    Select true to send SPNAMEQUALIFIER in NAMEIDENTIFER with the assertion.

    SAML2 NAMEID ATTRIBUTE NAME

    Specify the LDAP attribute name that will be sent in the name identifier in a SAML response for this service provider.

    SAML2 POST DEFLATE TRUSTEDPROVIDERS

    If you select true, the cluster will send deflated post messages to this provider.

    SAML2 POST SIGN RESPONSE TRUSTEDPROVIDERS

    If you select true, the identity provider will sign the entire SAML 2.0 response for this service provider.

    SAML2 REQUEST IGNORE AUTHCONTEXT

    If you select true, the identity provider ignores any specific authentication available in a SAML request from this service provider.

    SAML2 SHOW SHARED ATTRIBUTE NAMES

    If you select true, the attributes shared with the SAML 2 service provider are displayed on the user portal page.

    SAML2 SIGN METHODDIGEST SHA256

    If you select true, assertion will use the SHA 256 algorithm as a hashing algorithm for this service provider.

    OTHER

    Specify Property Name and Value if you want to configure any other property for this service provider.

  5. Click OK > Apply.

Configuring the Liberty or SAML 2.0 Session Timeout

When you are active on a session on the service provider and a time-out occurs, the service provider initiates a logout.You can configure this time-out by using the web.xml parameter in Access Gateway ESP, then ESP initiates a logout message to the Access Manager service provider over the SOAP back-channel when the time-out 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 time-out message:

  1. Click Devices > Access Gateways > Edit > Reverse Proxy /Authentication > ESP Global Options.

  2. Remove the pound (#) symbol before notifysessionTimetoIDP and set the value as true.

    ESP sends a ESP session time-out message. After time-out, the service provider sends a samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol request to the remote identity provider.

  3. Restart Tomcat on each Identity Server in the cluster by using the following command:

    Linux: Enter the following command:

    /etc/init.d/novell-idp restart

    Windows: Enter the following commands:

    net stop Tomcat8

    net start Tomcat8

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. 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, Identity Server creates one for its internal use. The internal value is not persistent. Whenever 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, must 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 Identity Server to prompt the user for credentials. If 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.

    If the Access Manager identity provider is unable to execute the requested authentication contract, it looks for the configured external identity provider. This happens when the Satisfiable by External Contract option is enabled that satisfies the incoming authentication (contract) request. If the match is found, the identity provider lists all the satisfiable contracts to select the appropriate contract. If only a single match is found, the identity provider redirects it to an external contract.

    If the local identity provider is able to authenticate by using a local contract, which is satisfiable by an external provider, then the first preference is given to the local contract along with the other authentication cards listed.

    To configure the contract matching criteria, see Allowable Class in Section 5.1.4, Configuring Authentication Contracts.

  3. Click OK > OK and update Identity Server.

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

  2. In Administration Console Dashboard of the SAML 2.0 identity provider, click Devices > Identity Servers > Servers > Edit > SAML 2.0 > Service Provider > Options > New.

  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. In Administration Console Dashboard of the SAML 2.0 service provider, click Devices > Identity Servers > Servers > Edit > SAML 2.0 > Service Provider > Options > New.

    2. Set the SAML2 AVOID SPNAMEQUALIFIER TO property to true.

    3. Click OK.

  5. Restart 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 SAML 2.0, 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 2012 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 2012 instance (fsweb.contoso.com) is used to host the AD FS 2.0 federation server and a Windows Server 2012 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 Identity Server component of Access Manager is required for this federation. For more information about installation and deployment of Access Manager, see NetIQ Access Manager 4.4 Installation and Upgrade Guide.

NOTE:You can download the evaluation version of Access Manager from NetIQ’s download portal.

Linux Environment

  • Access Manager 4.x.x.

  • SUSE Linux Enterprise Server (SLES) 11 SP4 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 Identity Server to communicate with Administration Console.

For more information about these ports, see Setting Up Firewalls in the NetIQ Access Manager 4.4 Installation and Upgrade Guide.

For HTTPS communication, 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 Identity Server Configuration Port in the NetIQ Access Manager 4.4 Installation and Upgrade Guide.

For back-channel communication with cluster members, you need to open port 7801. This port 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 2012 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 a 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, 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 ADFS Metadata to Add a New 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 AD FS metadata file 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.

Adding 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 Name, specify a name by which you want to refer to the provider.

  4. Select Metadata Text from the Source list.

  5. In Text, paste the copied AD FS metadata that you saved in Step 5.

  6. Click Next > Finish.

  7. Update Identity Server.

Adding an AD FS Server Trusted Certificate

  1. Download the certificate authority (CA) certificate from the AD FS server.

  2. In Access Manager Administration Console, click Security > Certificates > Trusted Roots > Import.

  3. Specify a name for the certificate and browse for the ADFS certificate.

  4. Click OK.

  5. Click Uploaded AD FS CA.

  6. Click Add to Trusted Store and select config store.

  7. Update Identity Server.

Creating an Attribute Set in Access Manager

  1. In 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 Remote attribute.

  7. Select http://schemas.xmlsoap.org/ws/2005/05/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 Remote Attribute.

  12. Select http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ from the Remote namespace list.

  13. Click OK.

  14. Update 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 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

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, specify the following values:

    Name

    Value

    Claim rule name

    Name Rule

    Incoming claim type

    Name

  11. Keep Pass through all claim values 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 Pass Through or Filter an Incoming Claim.

  16. Click Next.

  17. On the Configure Claim Rule page, specify the following values under Claim rule name:

    Name

    Value

    Claim rule name

    Email Rule

    Incoming claim type

    E-Mail Address

  18. Keep Pass through all claim values 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, specify the following values:

    Name

    Value

    Claim rule name

    Pass Name Rule

    Incoming claim type

    Name

  6. Keep Pass through all claim values 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, specify the following values:

    Name

    Value

    Claim rule name

    Pass Name ID Rule

    Incoming claim type

    Name ID

    Incoming Name ID format

    Unspecified

  11. Keep Pass through all claim values 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, specify 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.

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

  • 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. Modify /opt/novell/nam/idp/conf/tomcat.conf and add JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"

  2. To apply the changes, restart 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 AD FS 2.0 Windows PowerShell Administration of the AD FS 2.0 Operations Guide and 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 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 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 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 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 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 must 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.

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

Modify the /opt/novell/nam/idp/conf/tomcat.conf file 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: