The authentication process involves a number of actors contributing to the concepts, the API and the particular implementations.
The main support for authentication is defined by the OSGi Http Service specification. This specification defines how an OSGi application can register servlets and resources to build web applications. As part of the servlet and/or resource registration a
HttpContext may be provided, which allows for additional support.
The main method of interest to the authentication process is the
handleSecurity method. This is called by the OSGi Http Service implementation before the registered servlet is called. Its intent is to authenticate the request and to provide authentication information for the request object: the authentication type and the remote user name.
The Sling Auth Core bundle provides the
AuthenticationSupport service which may be used to the implement the
The Sling Engine implements the main entry point into the Sling system by means of the
SlingMainServlet. This servlet is registered with the OSGi Http Service and provides a custom
handleSecurity method is implemented by the
When the request hits the
service method of the Sling Main Servlet, the resource resolver provided by the
AuthenticationSupport service is retrieved from the request attributes and used as the resource resolver for the request.
That's all there is for the Sling Engine to do with respect to authentication.
The support for authenticating client requests is implemented in the Sling Auth Core bundle. As such this bundle provides three areas of support
AuthenticationHandlerservice interface. This is implemented by services providing functionality to extract credentials from HTTP requests.
Authenticatorservice interface. This is implemented by the
SlingAuthenticatorclass in the Sling Auth Core bundle and provides applications with entry points to login and logout.
AuthenticationSupportservice interface. This is implemented by the
SlingAuthenticatorclass in the Sling Auth Core bundle and allows applications registering with the OSGi HTTP Service to make use of the Sling authentication infrastructure.
The actual process of logging into the repository and provided a
Session is implementation dependent. In the case of Jackrabbit extensibility is provided by configuration of the Jackrabbit repository by means of an interface and two helper classes:
LoginModule-- The interface to be implemented to provide login processing plugins
AbstractLoginModule-- A an abstract base class implementation of the
DefaultLoginModule-- The default implementation of the
AbstractLoginModuleprovided by Jackabbit. This login module takes
SimpleCredentialsand uses the repository to lookup the users, validate the credentials and providing the
Principalrepresenting the user towards the repository.
The Sling Jackrabbit Embedded Repository bundle provides additional plugin interfaces to extend the login process dynamically using OSGi services. To this avail the bundle configures a
LoginModule with the provided default Jackrabbit configuration supporting these plugins:
LoginModulePlugin-- The main service interface. Plugins must implement this interface to be able to extend the login process.
AuthenticationPlugin-- Helper interface for the
Sling Applications requiring authenticated requests should not care about how authentication is implemented. To support such functionality the
Authenticator service is provided with two methods:
login -- allows the application to ensure requests are authenticated. This involves selecting an
AuthenticationHandler to request credentials for authentication.
logout -- allows the application to forget about any authentication. This involves selecting an
AuthenticationHandler to forget about credentials in the request.
Sling Applications should never directly use any knowledge of any authentication handler or directly call into an authentication handler. This will certainly break the application and cause unexpected behaviour.
HttpServletRequest.getAuthTypemethod: If this method returns
nullthe request is not authenticated.