Pluggable Authentication - Documentation topics on: custom authentication,deprecated,enterprise only,pam,pluggable authentication,.

Pluggable Authentication

You may develop custom “pluggable” authentication mechanisms that can be executed as part of an authentication chain, before the user is authenticated in the dotCMS system.


  • This is an advanced feature that is only supported in dotCMS Enterprise Professional and higher versions.
  • Pluggable Authenticators are used to authenticate a user in both the backend administrative console AND front-end logins.

Click the topics below for more information:

Extending the BaseAuthenticator Class

To implement a custom pluggable authentication mechanism you must create a class that extends the dotCMS com.dotcms.enterprise.BaseAuthenticator class. This allows you to override the methods called when a user attempts to authorize.

public boolean authenticate(String username, String password) throws NoSuchUserException {
  // TODO Auto-generated method stub
  return false;

public UserAttribute loadAttributes(String username, String password) {
  // TODO Auto-generated method stub
  return null;

public ArrayList loadGroups(String username, String password) {
  // TODO Auto-generated method stub
  return null;
  • The pluggable authenticator class can be wired to fire before the standard dotCMS based login has been called.
    • This is done by creating a $PLUGIN_DIR/conf/ file in your plugin, and wiring your class with the auth.pipeline.pre property in the file:
  • The loadAttributes method is used to load remote user information.
    • It will automatically be synchronized to the user properties stored in dotCMS based on information returned in UserAttribute Object.
  • The loadGroups method is used to load remote user Group information.
    • It will automatically be synchronized with dotCMS Role information based on the ROLE_KEY in the dotCMS Role.

Integrating SSO and Autologin Mechanisms

It is also possible to integrate SSO and other autologin style authentication mechanisms with dotCMS. These classes should be deployed via a dotCMS plugin.

To do this you must implement 2 classes, one each for the backend and one for the frontend. However you only need to implement classes for the logins you need; if you do not need backend integration you only need to implement the frontend class, and vice-versa.

The backend class must implement com.liferay.portal.auth.AutoLogin. The frontend class must override com.dotmarketing.filters.AutoLoginFilter.

The following example implements backend integration for CAS2:

public class CASAutoLogin implements AutoLogin {

  public static final String CAS_FILTER_USER =

  public String[] login(HttpServletRequest req, HttpServletResponse res)
    throws AutoLoginException {

    try {
      String[] credentials = null;

      HttpSession ses = req.getSession();

      String userId = (String)ses.getAttribute(CAS_FILTER_USER);

      if (userId != null) {
        User user = UserLocalManagerUtil.getUserById(userId);

        credentials = new String[3];

        credentials[0] = userId;
        credentials[1] = user.getPassword();
        credentials[2] = Boolean.TRUE.toString();

      return credentials;
    catch (Exception e) {
      throw new AutoLoginException(e);


Note: The login() function returns a String[] which returns 3 strings: userId, password, and a string flag ("true" or "false") specifying wehther or not the password is encrypted.