Application Delivery Management
Application Modernization & Connectivity
CyberRes
IT Operations Management
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:
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.
Before you begin the configuration, ensure that the following are installed:
The following figure illustrates a simple setup that has been deployed and tested for Identity Federation:
Figure 1: Setup Diagram of Identity Federation in Bi-direction
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:
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:
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.
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.
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).
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.
Figure 4: Creating a new Trusted Identity Provider
2. Fill in the following fields as shown in Figure 4:
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.
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.
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.
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.
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:
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:
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.
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.
Figure 11: Trusted Service Provider Access settings
11. Repeat the entire Step 5 procedure on the NIDP2 Server.
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.
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.
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.
Figure 14: Successful Identity Federation of IDP and SP
If the federation has any issues, follow these tips:
For Keystore generation refer to:
KeyStore Generation
You can configure Identity Federation in a secure mode, using the steps described in this AppNote.