Realms

A realm is the unit that OpenSSO Enterprise uses to organize configuration information. Authentication properties, authorization policies, data stores, subjects (including a user, a group of users, or a collection of protected resources) and other data can be defined within the realm. The data stored in a realm can include, but is not limited to:

• One or more subjects (a user, a group of users, or a collection of protected resources)

• A definition of one or more data stores to store subject (user) data

• Authentication details identifying, for example, the location of the authentication repository, and the type of authentication required.

• Policy information that will be used to determine which resources protected by OpenSSO Enterprise the subjects can access.

• Responder configurations that allows applications to personalize the user experience, once the user has successfully authenticated and been given access.

• Administration data for realm management

You create a top-level realm when you deploy OpenSSO Enterprise. The top-level realm (by default opensso) is the root of the OpenSSO Enterprise instance and contains OpenSSO Enterprise configuration data; it cannot be changed after it is created. In general, you should use the default root realm to configure identity data stores, and manage policies and authentication chains. During deployment, OpenSSO Enterprise creates a Realm Administrator who can perform all operations in the configured root realm, and a Policy Administrator who can only create and manage policies.

All other realms are configured under the opensso realm. These sub-realms may contain other sub-realms and so on. Sub-realms identify sets of users and groups that have different authentication or authorization requirements. The use of sub-realms should be restricted to the following two scenarios.

1. Application Policy Delegation The use case for this is when you need to have different Policy Administrators to create policies for a sub-set of resources. For example, let's assume a sub-realm is created and named Paycheck. This sub-realm is configured with a policy referral from the root realm for configuring protection of resources starting with https://paycheck.sun.com/paycheck. Within the Paycheck sub-realm, a Paycheck Administrator role or group is created and assigned Policy Administration privileges. These administrators are now able to login to the sub-realm and create policies for their applications. By default, the sub-realm inherits the same configuration data store and authentication chains configured for its parent; if these configurations change in the parent, a corresponding change would be needed in the sub-realm. Additionally, all users will still log in to the root realm for access to all the applications. The sub-realm is primarily for the Policy Administrator to manage policies for the application. An educated guess on the number of sub-realms that can be supported would be about 100.

2. ISP/ASP/Silo The use case for this scenario is when each sub-realm is to have its own set of identity data stores, authentication chains, and policies. Ideally the only common thread between the root and the sub-realm would be the referral policy created in the root realm to delegate a set of resources to the sub-realm. Users would not be able to log in to the root realm (unless they are a member) but would have to authenticate to their sub-realm. Also, agents would have to be configured to redirect user authentication to the particular sub-realm. With regards to performance, the most resource consuming component would be when persistent searches created by the data stores connect to the same directory. An educated guess on the number of sub-realms that can be supported would be about 50.

The OpenSSO Enterprise framework aggregates realm properties as part of the configuration data. Figure 2–13 illustrates how configuration data can use a hierarchy of realms to distribute administration responsibilities. Region 1, Region 2, and Region 3 are realms; Development, Operations, and Sales are realms sub to Region 3.

Figure 2–13 Realm Hierarchy for Configuration Data

OpenSSO Enterprise 8.0 supports the Sun Java System Access Manager Legacy mode (which contains no realms) with a provided interface.