Understanding Realms

A realm is the administrative unit for OpenSSO Enterprise. After OpenSSO Enterprise is deployed and configured, the default / (Top Level Realm) is created. The top-level realm is the root realm that, with the exception of bootstrapping information configured during installation, contains the configuration data for the OpenSSO Enterprise instance. The top-level realm can contain sub realms. Sub realms under the top-level realm can also contain sub realms. Information that can be defined in the top-level or a sub realm includes:

• The location of one or more identity repositories containing users, groups, and roles to whom the remaining configuration information applies.

  ---

  Note –

  Roles are a feature of Sun Java System Directory Server but not Active Directory. Identity repositories defined in Active Directory cannot include roles.

  ---

• An authentication process that defines, among other information, the location of an authentication repository and the type of authentication required.

• Policies that are used to determine whether an authenticated user can access protected resources.

• Privileges to define administrative permissions within the realm.

• Configuration data for services that can be modified per realm. This includes the realm Administration Service, the Discovery Service, Globalization Settings, the Password Reset Service, the Session Service, and the User Profile.

The hierarchy of a top-level and sub realms can be used to identify users and groups with different authentication and authorization requirements. For example, users in the Human Resources department have access to more sensitive data than other users in an organization. By creating a sub realm for Human Resources personnel, you can enforce an authentication chain that might include entering an LDAP user identifier and password followed by a token generated using a SafeWord card. On the other hand, users not defined in this sub realm might need only enter an LDAP user identifier and password to access their own personal profile. The use of sub realms should be restricted to either of the following scenarios:

• Application-specific policy management in which the creation and delegation of policies for a particular application (for example, a vacation recording tool) is referred to a sub realm. In other words, policy administrators are created in the top-level realm and appointed a sub set of resources for which they can manage access. By default, the sub realm would have the same configuration data store and authentication chains as the top-level realm and all users login to the top-level realm to access the applications.

• Silo management where each sub realm has its own set of data stores (identities), authentication chains and policy management. A user, in this case, would authenticate to their respective sub realm.