Implicitly invoke REALM through FQDN a.k.a DNS Aliases

If you do not wish to explicitly configure a realm ?realm=thirdParty in your URL, you have the option to implicitly configure realms to be associated with specific Fully Qualified Domain Name (FQDN).

For example, consider a deployment with the following characteristics:

* The FQDN for AM and the top level realm is openam.example.com.

* AM also services realm1.example.com, and realm2.example.com. In other words, AM receives all HTTP(S) connections for these host names. Perhaps they share an IP address, or AM listens on all interfaces.

Without applying DNS aliases to the relevant realm, when a user visits http://realm1.example.com:8080/openam, AM redirects that user to the top level realm, http://openam.example.com:8080/openam. If the authenticating user is present only in realm1, then authentication fails even with correct credentials.

If no DNS alias is configured for a realm, realm1 users must visit URLs such as http://openam.example.com:8080/openam/XUI/?realm=/realm1#login. This format of URL reveals the top level realm, and exposes extra information about the service.

It’s not working?

The addition of DNS aliases using the AM console also adds FQDN mappings to the AM server. But I have seen scenarios at least in older versions like OpenAM 11 where it does not add this mapping. So do confirm you have the following property set:

• com.sun.identity.server.fqdnMap — AM 5+ and available through Deployment > Servers > Server Name > Advanced.
• com.sun.identity.agents.config.fqdn.mapping[openam.sqoopdata.local]=openam.sqoopdata.local — OpenAM 11+ and available through Default Site Settings or through individual server.

If you are using OpenAM 10 which btw has already hit EOSL, you could be running into OpenAM-1831.

And if you toggle debug level of Authentication to Message you would be able to assert if a given URL matched any of the configured FQDNs.

Still having issues? Please leave a comment.