Choosing and Using Realms
After the authenticator has established a user's identity, it's time to search for it. Usually, the ActiveDirectoryRealm
will do, but for testing purposes you will find the default UserDatabaseRealm
very handy.
- Tip
- I strongly recommend to try the
UserDatabaseRealm
first, you'll see whether the authenticator works at all. If it does, go on to theActiveDirectoryRealm
.
Active Directory Realm
The ActiveDirectoryRealm
will query your Active Directory domain for a user by the string name type of the supplied username and retrieve all the necessary information, e.g., his/her security groups.
It requires a two-step setup: First, you will need to configure a DirContextSourceFactory
with the parameters of your Active Directory domain. Second, the realm itself pointing to that Active Directory domain.
Configuring a Directory Context Source Factory
Please read the documentation of the DirContextSourceFactory
on how to configure it in detail. Here is a minimal working configuration:
- Tip
- Never rely on hard-coded hostnames, use my
ActiveDirectoryLdapDnsProvider
to auto-locate servers for Active Directory domains via DNS.
[…] <!-- Add this --> <Resource name="my-active-directory" type="net.sf.michaelo.dirctxsrc.DirContextSource" factory="net.sf.michaelo.dirctxsrc.DirContextSourceFactory" urls="ldap://ad.example.com" auth="gssapi" loginEntryName="my-client" /> […]
Referral Handling
In general, you should pick LDAP URLs which avoid any referral chasing because it amplifies execution in space and time. You are highly recommended using the Global Catalog (port 3268) only. More details on how this realm deals with referrals can be found in the Javadoc.
Configuring the Realm
Now we need to wire that to the realm. Open or create your app's context.xml
and add:
<Context> […] <!-- Add this --> <Realm className="net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm" dirContextSourceName="my-active-directory" localDirContextSource="true|false" /> […] </Context>
Provide the dirContextSourceName
you have configured for the DirContextSource
above and hint whether this directory context source has been configured locally or globally. Default value is false
.
You have successfully configured the ActiveDirectoryRealm
in your webapp. It is now ready to use.
Authenticated Principal
After successful authentication and retrieval, this realm will create an ActiveDirectoryPrincipal
with several attributes. Refer to the Javadoc for details.
- Important
- If you intend to authenticate with the
SSLAuthenticator
your client certificates must contain a subject alternative name type of 0 (otherName
) with the type OID of 1.3.6.1.4.1.311.20.2.3 (msUPN
).
Using Security Groups from Active Directory
The ActiveDirectoryRealm
will populate all roles as SID strings for the given principal by default. While it might not look convenient in the first place, it adds benefit when security groups are moved from/to other domains, the SID history is completely retained. I.e., your application will continue to work even with the old SID. If you would like to map SIDs to developer-friendly role names, checkout the PropertiesRoleMappingListener
or use other role formats, but the SID see extended capabilities of this realm in the Javadoc.
Using a Realm for Testing Purposes
In most cases you are not able to modify Active Directory entries easily (usually admins can), e.g., adding and removing groups or their members. Therefore, you can use the UserDatabaseRealm
, fiddle quickly with users and roles to test your application.
Follow the Tomcat documentation and configure a tomcat-users.xml
file with the according resource declaration. Type in the user and group principals, but leave the passwords out.
Open or create your app's context.xml
and add:
<Context> […] <!-- Add this --> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" stripRealmForGss="false" /> […] </Context>
You have successfully configured the UserDatabaseRealm
in your webapp. It is now ready to use.
Alternative Realm Implementations
If you are not using Active Directory as a user repository (e.g. database or another directory server) and can still make use of this library. Extend Tomcat's RealmBase
class and override any of these methods:
Next Step
You have freed your users from typing usernames and passwords over and over again. Go on and try your new SSO setup.