Oak Documentation

GuestLoginModule

The aim of the GuestLoginModule implementation is to provide backwards compatibility with Jackrabbit 2.x with respect to the guest (anonymous) login: the GuestLoginModule can be added as optional entry to the chain of login modules in the JAAS (or corresponding OSGi) configuration.

Example JAAS Configuration:

jackrabbit.oak {
   org.apache.jackrabbit.oak.spi.security.authentication.GuestLoginModule  optional;
   org.apache.jackrabbit.oak.security.authentication.user.LoginModuleImpl required;
};

The behavior of the GuestLoginModule is as follows:

Phase 1: Login

• tries to retrieve JCR credentials from the [CallbackHandler] using the [CredentialsCallback]
• in case no credentials could be obtained it pushes a new instance of GuestCredentials to the shared stated and returns true
• otherwise it returns false

Phase 2: Commit

• if the phase 1 succeeded it will add the GuestCredentials created above and EveryonePrincipal the Subject in phase 2 of the login process and returns true
• otherwise it returns false

LoginModuleImpl

The LoginModuleImpl defines a regular userId/password login and requires a repository setup that supports User Management and is designed to supports the following Credentials:

• SimpleCredentials
• GuestCredentials (see above)
• ImpersonationCredentials (see below)

This login module implementations behaves as follows:

Phase 1: Login

• if a user does not exist in the repository (i.e. cannot be provided by the user manager) it returns false.
• if an authorizable with the respective userId exists but is a group or a disabled users, it throws LoginException
• if a user exists in the repository and the credentials don't match, it throws LoginException
• if a user exists in the repository and the credentials match, it returns true
  • also, it adds the credentials to the shared state
  • also, it adds the login name to the shared state
  • also, it calculates the principals and adds them to the private state
  • also, it adds the credentials to the private state

Phase 2: Commit

• if the private state contains the credentials and principals, it adds them (both) to the subject and returns true
• if the private state does not contain credentials and principals, it clears the state and returns false

ImpersonationCredentials

Since the implementation of Session.impersonate no longer uses SimpleCredentials to transport the original Subject but rather performs the login with dedicated ImpersonationCredentials, impersonation is no longer restricted to SimpleCredentials being passed to Session#impersonate call. Instead, the specified credentials are passed to a new instance of ImpersonationCredentials delegating the evaluation and validation of the specified Credentials to the configured login module(s).

This modification will not affect applications that used JCR API to impersonate a given session. Note however that applications relying on the Jackrabbit implementation and manually creating SimpleCredentials with a SecurityConstants.IMPERSONATOR_ATTRIBUTE, would need to be refactored after migration to Oak.

Impersonation with Custom Authentication Setup

Applications that wish to use a custom authentication setup need to ensure the following steps in order to get JCR impersonation working:

• Respect ImpersonationCredentials in the authentication setup.
• Identify the impersonated from ImpersonationCredentials.getBaseCredentials and verify if it can be authenticated.
• Validate that the editing session is allowed to impersonate: The user associated with the editing session can be identified by the AuthInfo obtained from from ImpersonationCredentials.getImpersonatorInfo().

TokenLoginModule

The TokenLoginModule is in charge of creating new login tokens and validate repository logins with TokenCredentials. The exact behavior of this login module is described in section Token Authentication.

ExternalLoginModule

The [ExternalLoginModule] is a base implementation that allows easy integration of 3rd party authentication and identity systems, such as LDAP. The general mode of the external login module is to use the external system as authentication source and as a provider for users and groups that may also be synchronized into the repository.

This login module implementation requires an valid SyncHandler and IdentityProvider to be present. The detailed behavior of the ExternalLoginModule is described in section External Authentication.