DefaultCredentialHandler Features

With the Jetspeed DefaultCredentialHandler special management of password credentials can easily be configured. Through the provided PasswordCredentialProvider and InternalPasswordCredentialInterceptor components custom logic can be plugged in for:

• providing a custom PasswordCredential implementation
• password encoding
  If an CredentialPasswordEncoder is available from the PasswordCredentialProvider passwords will be encoded with it before they are persisted. The provided MessageDigestCredentialPasswordEncoder uses MessageDigest hash algorithms for the password encryption, and can for example be configured to use SHA-1 and Base64.
• enforcing password value rules
  If an CredentialPasswordValidator is available from the PasswordCredentialProvider, passwords will be validated with it before they are persisted. The DefaultCredentialPasswordValidator for example enforces non-emtpy password. And with the SimpleCredentialPasswordValidator a minimum length and a minum number of numeric characters can be enforced.
• intercepting InternalCredential lifecycle events
  If the DefaultCredentialHandler is provided with an InternalPasswordCredentialInterceptor, it will invoke this interceptor (or an arbirary set if InternalPasswordCredentialInterceptorsProxy is used) on:
  • after loading a credential from the persistent store
  • after authenticating a user
  • before a new credential is saved to the persistent store
  • before a new password is save for the credential
  Jetspeed already provides a basic set of interceptors, ready to be used:
  • ValidatePasswordOnLoadInterceptor
    This interceptor can be used to validate (pre)set passwords in the persistent store and force a required change by the user if invalid. It uses the configured CredentialPasswordValidator of the PasswordCredentialProvider, the same as used when a password is changed.
  • EncodePasswordOnFirstLoadInterceptor
    This interceptor can be used if passwords needs to be preset in the persistent store or migrated unencoded from a different store. With this interceptor, these cleartext password will automatically be encoded the first time they are loaded from the database, using the CredentialPasswordEncoder from the PasswordCredentialProvider
  • PasswordExpirationInterceptor
    This interceptor can be used to enforce a maximum lifespan for passwords. It manages the expiration_date and is_expired members of the InternalCredential and sets the expired flag when on authentication of a user its (valid) password is expired. The authentication will then fail.
    Note: A Jetspeed pipeline Valve, the PasswordCredentialValveImpl can be used to request or even enforce users to change their password in time to prevent a password expiration (described further below).
  • MaxPasswordAuthenticationFailuresInterceptor
    This interceptor can be used to prevent password hacking by enforcing a maximum number of invalid password attempts in a row. Once this number of authentication failures is reached, the credential will be disabled. On a successful authentication though, this count will automatically be reset to zero again by the DefaultCredentialHandler.
  • PasswordHistoryInterceptor
    This interceptor can be used to enforce usage of unique new passwords in respect to a certain number of previous used passwords. When a new password is set, the current password is saved in a FIFO stack of used passwords. When a user itself changes its password, it must be different from all the onces thus saved, otherwise a PasswordAlreadyUsedException will be thrown. But setting a new password through the administrative interface still allows any password (when otherwise valid) to be set.

  The DefaultCredentialHandler only supports one interceptor to be configured. But, with the InternalPasswordCredentialInterceptorsProxy, a list of interceptors can be configured which then will be invoked sequentially.

  Jetspeed comes out of the box with several of these interceptors configured, and its very easy to change and extend.See the security-spi-atn.xml section in the Security Services Configuration document for a description of the default configuration. Also provided there is an example how to setup the interceptors to restore the "old" (and much more restrict) configuration provided with the 2.0-M3 release and earlier.

Credentials Management Implementation

The class diagram below describes the components used for the DefaultCredentialHandler implementation.

The OJB mappings for the default credentials implementation are described in security_repository.xml:

• InternalCredential: Maps to the SECURITY_CREDENTIAL table.