Introduction

The goal of Identity Federation is to enable users of one trusted business partner to securely and seamlessly access resources/systems of another business partner based on the business and technical agreements in a trustworthy manner. Identity Federation enables Single Sign-On, Access Control and Single Sign-Off provisioning for users and links users' identities.

This AppNote helps the user to Configure the Identity Federation in a secure mode in Novell Access Manager. It is intended for those who want to do the following:

• Deploy Identity Federation in secure mode

• Create keystore in Identity server

Prerequisites/Assumptions

Users/administrators should be familiar with the functioning of Novell Access Manager. They should be able to configure and bring up the Identity Server - i.e., IDP, SP, and Userstore. Administrators should clearly know the purpose of the Identity Federation and the servers which they want to federate. This AppNote covers at a high level what needs to be configured for Identity Federation functionality.

Software Requirements

Before you begin the configuration, ensure that the following are installed:

• Two Identity Servers

• User store for each Identity server

• Device manager for administrator configuration

Conventions

• IDP - Identity Provider

• SP - Service Provider

• Administration Console - Device Manager

• NIDP - Used for Identity Server in this document

Setup

The following figure illustrates a simple setup that has been deployed and tested for Identity Federation:

Click to view.

Figure 1

Figure 1: Setup Diagram of Identity Federation in Bi-direction

Initial Server Configuration

Before starting the configuration, you need to decide on how to establish a secure method for Identity federation. This means whether to configure Identity federation in a bi-directional or a unidirectional mode, or whether the Identity server must be configured as one of the following:

• Identity Provider

• Service Provider

• As both Identity Provider and Service Provider

The Trusted Identity Provider is used to provide authentication to Trusted Service Providers. The administrator also must decide whether to configure the Identity Servers in a trust model using the SAML or Liberty protocols.

This document covers Identity federation in a bi-directional mode; that is, in each Identity server both IDP and SP are configured using Liberty protocol. The setup details and basic configuration that needs to be performed on both the NIDP servers are:

• NIDP1 and NIDP2 are Identity servers that are installed and configured with UserStore1 and Userstore2 respectively, in secure mode.

• The Identity Servers are configured with HTTPS as the base URL to run securely in SSL mode.

• User1 is created in Userstore1, and User2 is created in Userstore2.

• The default User authentication contract is configured as Secure name and password.

• Both the Identity servers should be able to resolve each other's DNS names. For example, NIDP1 and NIDP2 are the DNS names of the Identity servers used in this document.

Configuration Steps

1. Exporting certificates

• Importing certificates

• Creating the key-store using keytool

• IDP configuration: IDP1 and IDP2 are Trusted Identity Providers that will be configured in NIDP2 and NIDP1 respectively.

• SP configuration: SP1 and SP2 are Trusted Service Providers that will be
  configured in NIDP2 and NIDP1 respectively.

Step 1: Exporting Certificates

First, export the Trusted CA of NIDP1 to a file.

1. In the Administration Console of NIDP1, click Access Manager > Certificates > Trusted Roots.

2. Select the server CA.

3. Select Export Public Certificate > Der file

4. Save the file (e.g., nidp1.der).

5. Save the Server CA, as shown in Figure 2, on your local machine.

Click to view.

Figure 2

Figure 2: Exporting the Public Certificate

6. Repeat the entire Step 1 procedure the NIDP2 server.

Step 2: Importing the Certificate

The stored CA certificate needs to be imported to the other Server (CA of NIDP1 needs to be imported to NIDP2 server). To import the CA certificate, do the following:

1. In the Administration Console of NIDP2, click Access Manager > Certificates > Trusted Roots > Import.

2. Provide the name of the certificate (e.g., NIDP1) that needs to be imported.

3. Browse and select the file (e.g., nidp1.der) that was stored in Step 1, as shown in Figure 3.

Click to view.

Figure 3

Figure 3: Importing the Trusted Root Certificate

4. In the Administration Console, click Access Manager > Certificates > Trusted Roots.

5. Select the Trusted Root Certificate added above.

6. Select Add Trusted Roots to Trust Stores.

7. Browse and select 'NIDP-truststore'.

8. Repeat the entire Step 2 procedure on the other server (NIDP1).

Step 3: Creating the KeyStore using Keytool

Because the Administration Console cannot dynamically update the truststore, you need to manually restore the JVM truststore in the server using the Keytool utility. This Keytool is a key and certificate management utility. This tool manages certificates (that are "trusted" by the user), which stores the keys and certificates in a keystore as a file protected by a password.

To create the keystore on Identity server (NIDP2), do the following:

1. Find the Keytool executable in JAVA_HOME/jre/bin folder of the Identity Server, or use the following command at the command prompt of the server, to locate the tool:

find / -name keytool

JAVA_HOME is the JAVA home location used by the Administration Console.

2. Copy the trusted root certificate file (nidp1.der) stored in Step 1 to the other identity server (NIDP2) in JAVA_HOME/jre/bin folder or in the folder where keytool executable exists.

3. Run the following command to generate the key store:

./keytool -import -trustcacerts -alias <alias> -keystore <keystore> -storepass <storepass> -file <cert_file>

Be sure to use an appropriate alias, keystore, storepass and filename. For example:

./keytool -import -trustcacerts -alias server1 -keystore nidp1-key -storepass novell -file nidp1.der

4. Copy the keystore generated in Step 2 to JAVA_HOME/jre/lib/security folder or /jre/lib/security folder, depending on the Keytool executable location.

5. After the JVM Keystore is generated, restart tomcat for JVM to reflect the changes using the following command:

/etc/init.d/novell-tomcat4 restart

6. Repeat the entire Step 3 procedure to generate a trusted keystore on the other Identity Server (NIDP1).

Step 4: Configuring the Trusted Identity Provider

The procedure to establish trust between providers begins with obtaining the metadata for trusted providers. This document discusses how you can obtain metadata for the Liberty protocol. For SAML 1.1 or 2.0, refer to the document mentioned in the Related Links section at the end of the AppNote. A sample URL for metadata Liberty Protocol would be http://<DNS-name>:8080/nidp/idff/metadata

To configure Trusted Identity Provider in NIDP2 server, do the following:

1. In the Administration Console of NIDP2 server, click Access Manager > Identity Servers > Servers > Edit > Liberty > New > Identity Provider.

Click to view.

Figure 4

Figure 4: Creating a new Trusted Identity Provider

2. Fill in the following fields as shown in Figure 4:

• Name: The name by which you want to refer the Trusted Identity Provider

• Metadata URL: The metadata URL for a Trusted Identity Provider. The system retrieves protocol metadata using this URL. Mention the DNS name of NIDP1 server which is used while configuring NIDP1 base URL.

3. Click Next.

4. Review the metadata certificates, then click Finish.

The system displays the Trusted Identity provider on the Liberty page, as shown in Figure 5.

Click to view.

Figure 5

Figure 5: Trusted Identity Provider list

5. To view the Metadata, click Identity Provider > Metadata.

The provider ID should be in the HTTPS format for secure federation as shown in Figure 6.

Click to view.

Figure 6

Figure 6: Trusted Identity Provider Meta Data

Next, you need to set common configurations in Trusted Identity Provider:

6. In the Administration Console, click Access Manager > Identity Servers > Servers > Edit > Liberty.

7. Select the Identity Provider Name.

8. Click Access > General.

9. Select Mutual SSL for secure communication between the Identity server and Trusted Identity Provider across the SOAP Back Channel, as shown in Figure 7.

Click to view.

Figure 7

Figure 7: Configure Trusted Identity Provider Access

10. In the Administration Console, click Access Manager > Identity Servers > Servers > Edit > Liberty.

11. Select the Identity Provider Name.

12. Click Access > Authentication.

Click to view.

Figure 8

Figure 8: Trusted Identity Provider authentication settings

Next, enable the following options as shown in Figure 8:

13. Check the "Allow users to federate" check box.

14. Under Authentication Context, configure the following fields:

• Select Use Contracts

• Select the Authentication types as Secure Name Password

• Select the Authentication contracts as Secure Name/Password-Form

15. Click OK.

16. In the Trusted Providers page, click OK.

17. Update the Identity Server configuration on the Servers page.

18. Repeat the entire Step 4 procedure on the NIDP1 Server.

Step 5: Configuring the Trusted Service Provider

Follow the steps below to configure Trusted Service Provider on the NIDP1 server.

1. In the Administration Console of NIDP1 server, click Access Manager > Identity Servers > Servers > Edit > Liberty > New > Service Provider.

2. Fill in the following fields as shown in Figure 9:

• Name: The name by which you want to refer to the Trusted Service Provider.

• Metadata URL: The metadata URL for a Trusted Service Provider. The system retrieves protocol metadata using this URL.

Click to view.

Figure 9

Figure 9: Creating a new Trusted Service Provider

3. Click Next.

4. Review the metadata certificates, then click Finish.

5. To view the Metadata, click Identity Provider > Metadata.

The Service provider ID should be in the HTTPS format for secure federation, as shown in Figure 10.

Click to view.

Figure 10

Figure 10: Trusted Service Provider Metadata

Next set the common configuration in Trusted Service Provider.

7. In the Administration Console, click Access Manager > Identity Servers > Servers > Edit >Liberty.

8. Select the Service Provider Name.

9. Click Access > General.

10. Select Mutual SSL for secure communication between the Identity server and Trusted Service Provider across the SOAP Back Channel as shown in Figure 11.

Click to view.

Figure 11

Figure 11: Trusted Service Provider Access settings

11. Repeat the entire Step 5 procedure on the NIDP2 Server.

Verifying the Setup

Federating the IDPs

As an example, User1 in NIDP1 and User 2 in NIDP2 must federate, because those accounts belong to the same user in both the Identity Servers.

1. Log in into to NIDP2 using https://dns.name:8443/nidp. The login page looks like the one as shown in Figure 12.

Click to view.

Figure 12

Figure 12: NIDP login page

2. Click the IDP1 icon and log in to NIDP1 server as user1.

3. Before federating, users are prompted to specify credentials for the login page of NIDP2. Provide the credentials of User 2.

4. Click Yes, then federate the user as shown in Figure 13.

Click to view.

Figure 13

Figure 13: Identity Federation Consent page

4. After logging in, click Federations. If the Identity servers have federated successfully, it will look similar to Figure 14. If they are not federated, select the Provider and click Federate.

Click to view.

Figure 14

Figure 14: Successful Identity Federation of IDP and SP

Troubleshooting Tips

If the federation has any issues, follow these tips:

• Ensure that you synchronize the correct date, time, and time zone settings between the Identity Servers and the SP. Otherwise, you will encounter federation and session time-out errors. It is recommended that you use NTP for time synchronization.

• Ensure that DNS names/URL's are resolved by all the IDPs.

• Ensure that the certificate subject name matches the URL domain name.

• Make sure the URL is resolvable.

• Enable (allow) browser pop-ups for the Administration Console (administration server).

• If Network Address Translation routers are deployed between the servers, ensure that the servers are able to communicate successfully through the router.

• If a firewall is deployed between the Identity servers, ensure that the respective filters are added so both servers can communicate with each other.

Related Links

For Keystore generation refer to:

KeyStore Generation

Conclusion

You can configure Identity Federation in a secure mode, using the steps described in this AppNote.