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 RSA SecurID Access trusted realm to allow users who are not in an Authentication Manager identity source or the internal database to use RSA SecurID Authenticate Tokencodes on RSA authentication agents. For more information, see RSA 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.
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.
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.