Realms
AM realms are administrative units that group configuration and identities together.
The AM installation process creates the Top Level Realm (/), which contains AM default configuration data. This realm cannot be deleted or renamed, since it is the root of the realm hierarchy in AM.
The Top Level Realm can contain sub-realms, which can also contain sub-realms.
Realms are associated with an identity store and, at least, an authorization chain or tree. When you create a new realm, AM copies part of the configuration of the parent realm to the new realm. For example, authentication trees are copied over, as well as the configuration of identity, policy, and application stores. When stored in the configuration store, policies are also copied over.
Once the realm is created, its configuration is separate from that of the parent realm. Configuration changes done to the parent realm or to the new realm will not be shared, with an exception; realms that share external stores will also share the configuration or data kept in the store.
For example, identities, groups, and privileges are linked to identity stores. Two realms that share a identity store will also share identity groups and the privileges granted to them. In the same way, two realms sharing the same policy store will share policy configuration, and two realms sharing the application store will share OAuth 2.0 client configuration.
Consider the following best practices when configuring realms:
- Separate Administrative Users from End Users
Create realms for your organizations and separate administrative users from end users, keeping the administrative users constrained to the Top Level Realm. This way, in the event that one of your identity stores is compromised, malicious users will not have the credentials of any AM administrator, which could further compromise your platform.
For this configuration to work, you need an identity store in the Top Level Realm that contains your administrative users and different identity store(s) for other realms/users.
- Create Realms to Isolate Identities
Keep users with different authentication and authorization requirements separate. For example, teachers in a University department would have access to more sensitive data than students do. Configuring a realm for teachers and another realm for students allows you to enforce stricter security policies for teachers.
- Keep the Top-level Realm for Administration Purposes Only
The Top Level Realm should not contain federation configuration, agent profiles, OAuth 2.0/OpenID Connect/UMA providers, or STS services.
When working with multiple realms, you need direct the users to the correct realm for authentication. You can either:
Use the
realm=realm-namequery string parameter.Create fully qualified domain name DNS aliases for the realms.
Caution
Creating DNS aliases for the realms does not make them more secure. An authenticated user that knows your AM configuration can navigate to other realms, such as the Top Level Realm, by adding the
?realm=/parameter to their URL.
| Configure Realms Using the AM console Learn about the AM console, Amster, and other tools. | Use realms to logically organize different groups of users. For example, create one realm for customers, and another for employees. |