Realms
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.
You cannot delete or rename the Top Level Realm, as it is the root of the realm hierarchy.
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 tree or chain. When you create a new realm, AM copies part of the configuration of the parent realm to the new realm. For example, authentication trees and the configuration of identity, policy, and application stores are copied to the new realm. If policies are stored in the configuration store, these are also copied to the new realm.
When a realm has been created, its configuration is separate from that of the parent realm. Configuration changes made to the parent realm, or to the new realm, are not shared. If realms share external stores, they also share the configuration or data kept in the store.
For example, identities, groups, and privileges are linked to identity stores. Realms that share an identity store will also share identity groups and the privileges granted to them. In the same way, realms that share a policy store will share policy configuration, and realms that share an 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 lets you 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 you have multiple realms, you must direct users to the correct realm for authentication. To specify the authentication realm, do one of the following:
-
Use the
realm=realm-namequery string parameter. -
Create fully qualified domain name DNS aliases for your realms.
Creating DNS aliases for realms does not make them more secure. An authenticated user that knows your AM configuration can go to other realms, such as the Top Level Realm, by adding the
?realm=/parameter to their URL.