The first step in creating a trusted realm relationship is creating the trust in the Authentication Manager. Creating a trust involves exchanging important
configuration information with the administrator of the trusted realm. The two realms must have specific information about one another in order to forward authentication requests and grant access to users from other realms.
Important: Both you and the trusted realm administrator must each create a trust, even if the trust is one way.
Creating a trust involves the following steps:
1. Generate a realm certificate to allow secure communication between the two realms. Both you and the trusted realm administrator need to perform this step.
2. Generate and upload the trust package. Both you and the trusted realm administrator need to perform this step.
3. Confirm the configuration code. Exchange confirmation codes with the trusted realm administrator. This can be done over the telephone.
4. Configure the trusted realm. You must name the trusted realm, enable or disable the trusted realm, and add a trusted user name identifier. This is also where you can configure the trust to be one way or two way.
Note: Trusted realm relationships are disabled by default, and are two way by default.
You generate the realm certificate using the RSA Operations Console. The remaining steps are done using on the Add New Trusted Realm page in the RSA Security Console. All four steps are described in detail in the following sections.
Generating the Realm Certificate
The first step is generating the realm certificate. The realm certificate allows secure communication between the two realms. You generate the realm certificate using the Operations Console.
To generate the realm certificate, go to the Realm Certificates page in the Operations Console. Select the realm for which you want to generate the realm certificate and click the Generate Realm Certificate button.
For instructions, see the Operations Console Help topic “Generate an SSL Realm Certificate.”
Generating and Uploading the Trust Package
The second step is creating a trust package. A trust package is an XML file containing configuration information about the trusted realm. You generate the trust package using the Security Console.
To generate the trust package, go to the Add New Trusted Realm page in the Security Console. Generate a trust package by clicking the Generate & Download button.
Important: After generating a trust package, you and the trusted realm administrator must exchange trust packages.
After exchanging trust packages with the trusted realm administrator, you must upload the trust package. Navigate to the location of the XML file for the other realm, and upload the trust package.
For more information on creating and uploading a trusted package, see the Security Console Help topic “Adding a Trusted Realm.”
Confirming and Exchanging the Confirmation Code
The third step is confirming and exchanging confirmation codes. A confirmation code is a code that is derived from the trust package. When you are creating the trust, the confirmation code displays on the Add New Trusted Realm page in the Security Console. There are two codes: one for your realm and one for the trusted realm.
You and the trusted realm administrator need to exchange codes. Discuss with the trusted realm administrator how and when you can verify the confirmation codes. You and the trusted realm administrator must verify each other's codes at the same time. A telephone call is a good way to confirm this code. Make sure that you and the trusted realm administrator agree on the specific time and place that the call will take place.
Configuring the Trusted Realm
The fourth step is configuring the trust. You can configure the following:
Trusted Realm Name. Name the trusted realm.
Authentication Status. Trusts are two way by default. To create a one-way trust, clear the Authenticate Trusted Users checkbox on the Add New Trust screen.
You should clear this box for the trusted realm.
Using the figure on page 142 as an example, the London administrator would clear the Authenticate Trusted Users checkbox to indicate that London will not authenticate trusted users from New York. Since the figure shows a one-way trust with London users authenticating through New York, the New York administrator selects the Authenticate Trusted Users checkbox to indicate that London users can authenticate through the New York realm.
Trusted Realm Status. Enable or disable the trusted realm. The trusted realm must be enabled to perform trusted realm authentications. Trusted realms are disabled by default.
Note: If the realm is disabled, the associated trusted users and trusted user groups remain.
Create Trusted Users in Security Domain. You can configure the realm to automatically create trusted users as users attempt to authenticate (this option is selected when configuring the agent). Here, you can specify the security domain in which those trusted users are created.
Trusted User Name Identifier. When creating a trust in Authentication Manager, you can associate a trusted user name identifier with the trust. A trusted user name identifier prevents user name collisions between the two trusted realms.
For example, assume that you have an Authentication Manager deployment in London, and a second deployment in New York. Both realms have a user, “jdoe.”
Suppose the London user “jdoe” were to travel to New York and attempt to authenticate. The New York realm would look up the user name and find one of its own users. However, upon attempting to authenticate the tokencode and PIN, the authentication would fail because the New York realm sees the credentials for New York “jdoe.” The New York realm does not realize that it is a trusted user who is trying to authenticate, and the user is denied access.
To avoid this situation, you can assign a trusted user name identifier to the trusted realm. A trusted user name identifier is a name suffix that the user appends to his or her normal user name. For example, if you created a trusted realm with
“abc.com” as the trusted user name identifier, then all users from that realm can authenticate with “[email protected].”
To continue with the example above, assume that you did create the trusted realm with “abc.com” as the trusted user name identifier. When the London “jdoe”
travels to New York, he or she will log on as “[email protected].” The New York realm will see that this is not a New York user and forward the authentication request back to London. London recognizes the user, approves the authentication, and London “jdoe” has a successful authentication in New York.
Important: If your deployment already uses name suffixes as part of the standard user name, do not configure a trusted user name identifier, as it is not necessary.
For more information on creating and configuring a trusted realm, see the Security Console Help topic “Add Trusted Realms.”
After creating the trust, you can specify which authentication agents are available for trusted realm authentication. For more information, see “Adding and Enabling Authentication Agents for Trusted Realm Authentication” on page 149.