The procedure documented here might make user sessions available across tenant sites, and so is not recommended in production scenarios. Also in a real-world deployment, tenants would not be in the same domain.
You can use realms in a multi-tenant deployment, where configuration settings and user identities are specific to a realm, and are not made available to other realms.
For example consider a deployment with the following characteristics.
For example, a service provider could have a centralized authentication and authorization service available to multiple customers (tenants) from different companies. The centralized service must not allow employees of one tenant to authenticate to another tenant, nor to be authorized to access resources from another tenant. The separation is achieved using one realm per tenant, such that all users, policies, configuration settings, and changes remain specific to the tenant's realm.
Yet, unless you further configure OpenAM, when an employee is directed to
http://realm1.example.com:8080/openam, and OpenAM redirects that access to
http://openam.example.com:8080/openam. If the user to authenticate is present only in realm1, then authentication fails even with proper credentials. Instead the tenant having realm1 must always use URLs specifying the realm as in
http://openam.example.com:8080/openam/UI/Login?realm=realm1, unfortunately revealing the top-level realm and exposing extra information about the service.
To prevent redirection and having to expose the top-level realm domain, perform the following steps.
openam.example.net, and have realms
realm2.example.com, then the list would include
com.sun.identity.server.fqdnMapunder Configuration > Servers and Sites > Server Name > Advanced.
com.sun.identity.server.fqdnMap[realm-fqdn]to realm-fqdn. For example, set
com.sun.identity.server.fqdnMapto take effect.