Jackrabbit Oak covers different authentication requirements by providing default implementations and extension points for different setup scenarios.
See the corresponding documentation.
Jackrabbit Oak covers the following login requirements and provides dedicated LoginModule implementation(s) for each scenario:
The proper way to obtain an guest session as of Oak is as specified by JSR 283:
String wspName = null; Session anonymous = repository.login(new GuestCredentials(), wspName);
As of Oak 1.0 Repository#login() and Repository#login(null, wspName) is no longer treated as guest login. This behavior of Jackrabbit-core is violating the specification, which defines that null-login should be used for those cases where the authentication process is handled outside of the repository (see Pre-Authentication).
Similarly, any special treatment that Jackrabbit core applied for the guest (anonymous) user has been omitted altogether from the default LoginModuleImpl. In the default setup the built-in anonymous user will be created without any password. Therefore explicitly uid/pw login using the anonymous userId will no longer work. This behavior is now consistent with the default login of any other user which doesn’t have a password set.
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
Phase 2: Commit
Oak 1.0 comes with 2 different login module implementations that can handle SimpleCredentials:
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:
This login module implementations behaves as follows:
Phase 1: Login
Phase 2: Commit
The LoginModuleImpl uses a configured Authentication-implementation for performing the login step. Which implementation to use is determined by the UserAuthenticationFactory obtained by the given UserConfiguration. It is expected to provides an Authentication implementation if the given UserConfiguration is accepted.
In case multiple implementations of the UserAuthenticationFactory are available, the precedence depends on its OSGi service ranking property. The default factory implementation has a ranking of 0 (OSGi default). Services with the highest ranking will take precedence.
See also section user management.
Another flavor of the Oak authentication implementation is covered by javax.jcr.Session#impersonate(Credentials), which allows to obtain an new Session for a user identified by the specified credentials. As of JSR 333 this method can also be used in order to clone the existing session (i.e. self-impersonation of the user that holds the session.
With Oak 1.0 impersonation is implemented as follows:
Whether or not impersonation succeeds consequently both depends on the authentication setup and on some implementation specific validation that make sure the editing session is allowed to impersonate the user identified by the credentials passed to the impersonate call.
With Oak 1.0 only the default login module (LoginModuleImpl) is able to deal with ImpersonationCredentials and applies the following logic:
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 refactor after migration to Oak.
Applications that wish to use a custom authentication setup need to ensure the following steps in order to get JCR impersonation working:
See section Token Authentication for details regarding token based authentication.
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.
Oak provides two different mechanisms to create pre-authentication that doesn’t involve the repositories internal authentication mechanism for credentials validation.
See section Pre-Authentication Login for further details and examples.
While the default setup in Oak is solely relying on repository functionality to ensure proper authentication it quite common to authenticate against different systems (e.g. LDAP). For those setups that wish to combine initial authentication against a third party system with repository functionality, Oak provides a default implementation with extension points:
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.