Trusted Realms

A deployment is an RSA Authentication Manager installation that consists of a primary instance and, optionally, one or more replica instances.

A realm is an organizational unit that includes all of the objects managed within a single deployment, such as users and user groups, tokens, password policies, and agents. Each deployment has only one realm.

For example, a corporation with headquarters in London has an office in New York. The London office and the New York office each has a deployment of Authentication Manager. The objects managed in each deployment constitute a realm: the London realm and the New York realm.

Two or more realms can have a trust relationship, which gives users on one realm permission to authenticate to another realm and access the resources on that realm.

For example, the London realm has a trust relationship with the New York realm. This means that the New York realm “trusts” users from the London realm and gives users from the London realm the same privileges as users in the New York realm. When users from the London office are in New York, they are able to able to authenticate at the New York office like all of the other New York users.

Note: You can create an SecurID trusted realm to allow users who are not in an Authentication Manager identity source or the internal database to use SecurID Authenticate Tokencodes on RSA authentication agents. For more information, see SecurID Authenticate Tokencodes.

You create a trust relationship by performing the following tasks:

  • Add an external realm as a trusted realm.

  • Specify an agent to authenticate trusted users from the trusted realm.

  • Specify the trusted users. You may not want to give all users from the trusted realm permission to authenticate on your realm, so you designate which users from the trusted realm are trusted users. Only trusted users have permission to authenticate.

A trust relationship can be either a one-way trust or a two-way trust. In a one-way trust, only trusted users on one realm are allowed to authenticate on the other realm.

For example, if the trust relationship between London and New York is one way, either trusted London users can authenticate on New York or trusted New York users can authenticate on London. In a two-way trust, trusted users on each realm can authenticate on the other. For example, if the trust relationship between London and New York is two way, London users can authenticate on New York and New York users can authenticate on London.

The following figure shows a one-way trust. London has added New York as a trusted realm. This allows Alice, who is a trusted user in the New York realm, to authenticate to the London realm when she is in London on business.

securid_one_way.gif

While in London, Alice attempts to access London’s virtual private network (VPN) using her New York realm credentials (user name and passcode). London’s VPN server is protected by an agent that is configured to provide trusted realm authentications. This agent does not recognize Alice and looks for Alice in other realms. After the agent finds Alice in the New York realm, the New York realm verifies Alice’s credentials, authenticates Alice, and tells the agent to grant Alice access.

The following figure shows a two-way trust. London has added New York as a trusted realm, and New York has added London as a trusted realm. This allows Alice, who is a trusted user in the New York realm, to authenticate to the London realm, and Bob, who is a trusted user in the London realm, to authenticate to the New York realm.

securid_two_way_614x346.gif

For more than two realms to trust each other, additional trust relationships must be established. Trusted realms cannot inherit or transfer trust from other realms. Trusted realm authentication only occurs between realms that have a direct, explicit trust relationship. In the previous example, even if the London realm were to add Paris as a trusted realm, New York and Paris would not trust each other unless you created a trust relationship between New York and Paris.

Creating a Trust Relationship

Two or more RSA Authentication Manager realms can have a trust relationship, which gives users on one realm permission to authenticate to another realm and access the resources on that realm. You use the Security Console to create and manage trust relationships between two RSA Authentication Manager8.0 or later realms.

Note: You can create an SecurID trusted realm to allow users who are not in an Authentication Manager identity source or the internal database to use SecurID Authenticate Tokencodes on RSA authentication agents. For more information, see SecurID Authenticate Tokencodes.

Procedure

  1. Add a Trusted Realm
  2. Configure an Agent for Trusted Realm Authentication
  3. Add a Trusted User
  4. (Optional) Add a Trusted User Group
  5. (Optional) Add Trusted Users to a Trusted User Group

Add a Trusted Realm

You create a trust relationship by adding an external realm as a trusted realm. A trust relationship allows users to authenticate between two RSA Authentication Manager 8.3 realms or an RSA Authentication Manager 8.3 realm and an RSA Authentication Manager 8.0 or later realm. Trust is not inherited or transferred from other realms, but instead, you must explicitly establish trust relationships as needed.

Note: You can create a Cloud Authentication Service trusted realm to allow users who are not in an Authentication Manager identity source or the internal database to use SecurID Authenticate Tokencodes on RSA authentication agents. For more information, see SecurID Authenticate Tokencodes.

Before you begin

  • You and the administrator of the realm you are adding as a trusted realm need to perform this procedure at the same time.

  • You and the administrator of the realm you are adding as a trusted realm need to be able to communicate while you perform this procedure.

Procedure

  1. In the Security Console, click Administration > Trusted Realms > Add New.

  2. Under Generate Trust Package, click Generate & Download.

  3. After the trust package is generated, use a secure method to exchange your trust package with the trust package from the trusted realm administrator. Wait until you receive the trust package before you continue.

    Note: The trust package is not compatible with RSA Authentication Manager 7.1. Do not import the trust package into a version 7.1 system.

  4. In the Trust Package from Trusted Realm field, enter the path to the trust package that you just received by browsing to the package file, and click Open.

  5. Click Next.

  6. Verify the trust package confirmation codes with the trusted realm administrator. Go to the next step only after verifying the confirmation codes.

  7. Click Confirm and Next.

  8. In the Trusted Realm Name field, enter a unique, user-friendly name that identifies the trusted realm, for example, London office.

  9. For Authentication Status, select Authenticate Trusted Users if you want your realm to authenticate users from the trusted realm.

  10. For Trusted Realm Status, select Enable Trusted Realm. When enabled, your realm can send authentication requests to the trusted realm.

  11. For Create Trusted Users in Security Domain, select the security domain that will own users from the trusted realm.

    After your realm authenticates users from the trusted realm, the users must belong to a security domain in your realm. The security domain that you select must be configured to use the internal database as an identity source.

  12. In the Trusted User Name Identifier field, enter a unique identifier that your realm can recognize for the trusted user, and click Add. The unique identifier could be the user's domain name or e-mail address, such as jsmith@company.com. The value must be unique among trusted realms.

    For example, suppose John Smith from Realm A is jsmith in his local realm. Your realm does not know the identity of jsmith. If you enter yourcompany.com in this field, John Smith will be identified within your realm as jsmith@yourcompany.com.

  13. Click Save.

  14. In the Security Console, click Administration > Trusted Realms > Manage Existing.

  15. Test the network connection between the trusted realms. Click the name of the trusted realm, and from the context menu, select Test Trusted Realm.

After you finish

Before trusted realm authentication can take place, you must enable an agent to process authentication requests from trusted users.

For more information, see Configure an Agent for Trusted Realm Authentication.

Edit a Trusted Realm

You can edit a trusted realm to change its basic configuration settings.

Procedure

  1. In the Security Console, click Administration > Trusted Realms > Manage Existing.

  2. Select the trusted realm that you want to edit.

  3. From the context menu, click Edit.

  4. Make any necessary changes. For more information, see Add a Trusted Realm.

  5. Click Save.

Enable and Disable a Trusted Realm

Enabling a trusted realm permits users from your realm to send authentication requests to the trusted realm. When you add a trusted realm, the trusted realm is enabled by default. You can also enable your realm to authenticate users from the trusted realm. For instructions, see Enable Authentication Between Realms.

Procedure

  1. In the Security Console, click Administration > Trusted Realms > Manage Existing.

  2. Use the search fields to find the trusted realm that you want to edit.

  3. Select the trusted realm that you want to edit.

  4. From the context menu, click Edit.

  5. In the Trusted Realm Status field, select Enable Trusted Realm.

  6. Click Save.

Disabling a trusted realm prevents any cross-realm authentication from taking place. Configuration data and trusted users are not deleted from your realm. If you want to delete this data, you must delete the trusted realm. For instructions, see Delete a Trusted Realm .

You can still view a disabled trusted realm in the Security Console.

Procedure

  1. In the Security Console, click Administration > Trusted Realms > Manage Existing.

  2. Use the search fields to find the trusted realm that you want to edit.

  3. Select the trusted realm that you want to edit.

  4. From the context menu, click Edit.

  5. In the Trusted Realm Status field, select Disable Trusted Realm.

  6. Click Save.

Delete a Trusted Realm

Deleting a trusted realm makes the following changes on your deployment:

  • All of the trusted realm's configuration data are deleted.

  • All users owned by the trusted realm are deleted.

If you want to reestablish the trust relationship, you must add the trusted realm.

Procedure

  1. In the Security Console, click Administration > Trusted Realms > Manage Existing.

  2. Select the trusted realm that you want to delete.

  3. From the context menu, click Delete.

  4. Click OK.

View Trusted Realms

Use this procedure to view a list of all the trusted realms that have a trust relationship with your realm.

Procedure

In the Security Console, click Administration > Trusted Realms > Manage Existing.

Test a Trusted Realm

For a trust relationship to work, your realm must be able to communicate with the trusted realm. You can verify communication between realms by testing the trusted realm.

Before you begin

Perform this test after you have added the trusted realm, or any time that cross-realm authentication continually fails. For more information, see Add a Trusted Realm.

Procedure

  1. In the Security Console, click Administration > Trusted Realms > Manage Existing.

  2. Select the trusted realm that you want to test.

  3. From the context menu, click Test Trusted Realm.

    A message indicates whether the test succeeded or failed. If the test fails, try reimporting the trust package that you received from the trusted realm.

Enable Authentication Between Realms

You can enable authentication between realms to allow users to authenticate across deployments and access resources in another realm protected by Authentication Manager. To enable authentication between realms, you enable your realm to authenticate users from the trusted realm, and the administrator of the trusted realm must perform the same procedure so that the trusted realm can authenticate users from your realm.

For a trust relationship to work, at least one realm must permit its users to send authentication requests to the other realm.

Procedure

  1. In the Security Console, click Administration > Trusted Realms > Manage Existing.

  2. Use the search fields to find the trusted realm that you want to edit.

  3. Select the trusted realm that you want to edit.

  4. From the context menu, click Edit.

  5. Select Authenticate Trusted Users.

  6. Click Save.

Configure an Agent for Trusted Realm Authentication

You must specify which authentication agents are available for trusted realm authentication.

On each agent in your realm, you specify one of the following:

  • Not open to trusted users

  • Open to all trusted users

  • Open only to trusted users in trusted user groups

For a one-way trust, the trusted realm administrator enables the agents for authentication in the trusted realm. For a two-way trust, you and the trusted realm administrator enable the agents in both your realms.

Before you begin

Procedure

  1. In the Security Console, click Access > Authentication Agents > Manage Existing.

  2. Use the search fields to find the agent that you want to configure.

  3. From the search results, click the authentication agent that you want to configure.

  4. From the context menu, click Edit.

  5. Do one of the following:

    • If you do not want trusted users to access this agent:

      1. Under Trusted Realm Settings, ensure that Enable Trusted Realm Authentication is not selected.

      2. Click Save.

    • If you want trusted users to access this agent:

      1. Under Trusted Realm Settings, select Enable Trusted Realm Authentication.

      2. For Trusted User Authentication, select one of the following:

        • Open to all Trusted Users. This option automatically designates users from a trusted realm as trusted users after successful authentication.

        • Only Trusted Users in Trusted User Groups with access to the agent can authenticate. These trusted users and trusted user groups are manually created by the administrator.

      3. Click Save.

Duplicate Agent Record for Access Control

You can control which users have access to an authentication agent in the trusted realm by adding a duplicate authentication record of the agent in the trusted realm. A duplicate authentication record allows you to restrict user access to members of a group. Only the users you assign to this group are able to access the agent in the trusted realm.

For example, suppose that you are the London administrator for a company that has a trusted relationship between two realms: New York and London. The New York realm has an unrestricted VPN agent called “VPN1.” You want to restrict which London users can access VPN1, so you create a duplicate agent record, also called “VPN1,” in the London realm. This agent record contains the same data as the agent record in the New York realm, including IP address. You make VPN1 a restricted agent, and create a user group called “VPN users.” Only London members of VPN users have permission to access VPN1 in New York.

You assign the London-based user “jsmith” to the VPN users group. When jsmith travels to New York and attempts to access VPN1 on the New York realm, the New York realm does not recognize the user jsmith, and forwards the following information to the London realm: user name, agent name, and passcode. The London realm recognizes the user name and agent name, and immediately checks to see if the agent is restricted. Because the agent is restricted, and jsmith is a member of the London-based VPN users, the authentication request is approved and the New York realm allows jsmith to authenticate.

If you create a duplicate agent record, it is important to know if the corresponding agent in the trusted realm has trusted user groups. If a trusted user group in the duplicate agent record does not contain the same users as the group on the agent on the trusted realm, users might not be able to authenticate. Note the following:

  • In the above example, assume that VPN1 in the trusted realm has a trusted user group associated with it. If jsmith is not a member of the trusted user group, he cannot authenticate, even though he is a member of his realm’s corresponding user group.

  • In the above example, assume that a second London user, “sbrown,” is a member of the trusted user group, but is not a member of his realm’s corresponding user group. Despite being a member of the trusted user group, sbrown cannot authenticate because his realm has not given him access to the agent.

Duplicate Agent Record for Resolving Aliases

If you use aliases for user groups, users might attempt to log on to an authentication agent in the trusted realm using their aliases. To ensure successful authentications in this case, add a duplicate record of the agent in the trusted realm with associated user groups and aliases to your realm.

For example, suppose that your realm has a restricted VPN agent, “VPN2.” Only members of the VPN2 user group can access VPN2. In that user group, users have aliases, a special user name they use just for VPN2. For example, the user “jdoe” has the alias “jdoeVPN,” which he uses when he logs on to VPN2.

If jdoe attempts to authenticate to the trusted realm’s VPN agent, “VPN1” using his alias, “jdoeVPN,” the trusted realm does not recognize jdoe and sends his user name and agent information back to jdoe’s realm. Jdoe’s realm does not recognize the agent “VPN1” or the user name “jdoeVPN.” Therefore, access is denied and the user cannot authenticate.

If jdoe’s realm has a duplicate agent record, also called “VPN1” and VPN1 has an associated user group where jdoe is a member and has “jdoeVPN” as his alias, the problem is solved. Now when “jdoeVPN” tries to access VPN1 in the trusted realm, the trusted realm forwards the user name and agent information back to jdoe’s realm. Jdoe’s realm recognizes the agent name and the alias. Now jdoe can authenticate successfully.

View Trusted Realm Settings

Use the following procedure to view the realm settings for a trusted realm or for a trusted legacy realm. For a trusted realm, you can view the status of the trust relationship and the confirmation codes used to add the trusted realm. For a trusted legacy realm, you can view the connection settings for cross realm authentication.

Procedure

  1. In the Security Console, click Administration > Trusted Realms > Manage Existing.

  2. Under Trusted Realm Name, select the trusted realm that you want to view.

  3. From the context menu, select View.

Removing Trust Between Two Realms

You can stop cross-realm authentication between your realm and a trusted realm by doing one of the following:

  • Disable the trusted realm. This action prevents your realm from receiving authentication requests from the trusted realm. Trusted users are not deleted and configuration data is not removed. If the trusted realm disables your realm, no cross-realm authentication can take place. This action is easily reversible. You can reestablish the trust relationship by enabling the trusted realm. For more information, see Enable a Trusted Realm and Disable a Trusted Realm.

  • Delete the trusted realm. This action deletes all trusted realm configuration data and trusted users from your machine. This action is not easily reversible. If you want to reestablish the trust relationship, you must add the trusted realm again. For more information, see Delete a Trusted Realm .

Repair a Trust Relationship with a Version 8.0 or Later Realm

If you restore the RSA Authentication Manager8.7 SP1 primary instance on a machine with a new hostname, and you had a trust relationship previously with another version 8.0 or later realm, perform the following procedure to repair the trust between the two Authentication Manager deployments.

Note: You can also repair a trust relationship between RSA Authentication Manager and SecurID. For instructions, see the Help topic "Repair an SecurID Trusted Realm."

Note: You can also repair a trust relationship between RSA Authentication Manager and SecurID . For instructions, Repair an SecurID Trusted Realm.

Before you begin

The administrator of the restored deployment and the administrator of the deployment where the trust will be repaired must be able to communicate directly while they perform this procedure.

Procedure

  1. The administrator of the restored deployment performs the following steps to generate a trust package.

    1. In the Security Console, click Administration > Trusted Realms > Manage Existing.

    2. Under Trusted Realm Name, click the trusted realm name to repair.

    3. From the context menu, click Generate Trust Package, and save the file (TrustPackage.xml).

    4. After the trust package is saved, use a secure method to send the trust package to the administrator of the deployment where the trust will be repaired.

  2. The administrator of the deployment where the trust will be repaired performs the following steps to import the trust package.

    1. After receiving the trust package, click Administration >Trusted Realms > Manage Existing.

    2. Under Trusted Realm Name, click the trusted realm name to repair.

    3. From the context menu, click Repair Trust.

    4. In the Trust Package from Trusted Realm field, enter the path to the new trust package by browsing to the package file, and click Open.

    5. Click Next, and contact the restored realm administrator.

  3. The administrator of the restored deployment performs the following steps to share the confirmation code with the administrator of the deployment where the trust will be repaired.

    1. In the Security Console, click Administration > Trusted Realms > Manage Existing.

    2. Under Trusted Realm Name, click the trusted realm name to repair.

    3. From the context menu, click View, locate the confirmation code under Current Realm ConfirmationCode, and read the code to the administrator of the deployment where the trust will be repaired to confirm that the trust package is valid.

      The Current Realm Confirmation Code must match the administrator’s Trusted Realm Confirmation Code.

  4. The administrator of the deployment where the trust will be repaired performs the following steps to repair the trust.

    1. On the Update Trusted Realm page under Trusted Realm Confirmation Code, read the Trust Package Confirmation Code to the restored realm administrator to confirm that the trust package is valid.

      The Trusted Realm Confirmation Code must match the restored realm administrator’s Current Realm Confirmation Code.

      If the confirmation code does not match, ask the restored realm administrator to generate and send a new trust package.

    2. Click Confirm and Next.

    3. (Optional) For Authentication Status, select Authenticate Trusted Users if you want your realm to authenticate users from the trusted realm.

    4. For Create Trusted Users in Security Domain, select the security domain that will own users from the trusted realm.

      After your realm authenticates users from the trusted realm, the users must belong to a security domain in your realm. The security domain that you select must be configured to use the internal database as an identity source.

    5. (Optional) In the Trusted User Name Identifier field, enter a unique identifier that your realm can recognize for the trusted user, and click Add. The unique identifier could be the user's domain name or e-mail address, such as jsmith@company.com. The value must be unique among trusted realms.

      For example, suppose John Smith from Realm A is jsmith in his local realm. Your realm does not know the identity of jsmith. If you enter yourcompany.com in this field, this user will be identified within your realm as jsmith@yourcompany.com.

    6. Click Save.

Related Tasks

Creating a Trust Relationship