Page History

...

Status: DRAFT NOT IMPLEMENTED
Created: 14. March 2010
Author: fmeschbe
JIRA: –
References: Merging Sling API and Commons Auth API
Update: – fmeschbe/27. September 2013

Update

This concept is not being implemented because in the meantime ResourceProviderFactory services have been introduced which can be flagged as being mandatory and thus validate credentials from authentication handlers. One such implementation is the JCR Resource Provider which does exactly that and internally validates the credentials by create a JCR Session.

Introduction

With the recent introduction of the Commons Auth Bundle and the current approach to break apart the dependency on JCR API from the Commons Auth Bundle we are faced with an issue of how to authenticate an HTTP request user while at the same time not binding the authentication mechanism to any data repository.

...

The JCR based ResourceResolverFactory.getResourceResolver(Map) knows about the CredentialValidator implementation and can make use of the Session object in the map to reuse the existing session.

Complete Steps Authenticating HTTP Requests

Requests are authenticated as follows:

1. Client makes HTTP Request
2. OSGi HTTP Service selects Sling to handle request and calls HttpContext.handleSecurity
3. Sling's handleSecurity method calls SlingAuthenticator.handleSecurity
4. SlingAuthenticator extractes AuthenticationInfo by calling AuthenticationHandler.extractCredentials
5. SlingAuthenticator passes AuthenticationInfo to CredentialValidator.validate
6. (JCR based) CredentialValidator builds JCR Credentials from AuthenticationInfo and calls Repository.login
7. CredentialValidator creates new AuthenticationInfo object copying all properties from input (except password) and setting the JCR Session as another property and returns
8. SlingAuthenticator sets new AuthenticationInfo as request attribute and sets remaining required request attributes and returns
9. Sling's handleSecurity returns successfully
10. OSGi HTTP Service passes control to SlingMainServlet
11. SlingMainServlet extracts AuthenticationInfo from request attribute and calls ResourceResolverFactory.getResourceResolver with this AuthenticationInfo (which actually extends Map)
12. (JCR based) ResourceResolverFactory recognizes the existing JCR Session and creates and returns a ResourceResolver based on this session
13. SlingMainServlet continues request processing
14. Finally SlingMainServlet closes the ResourceResolver at the end of request processing

Issues

The JCR based CredentialValidator implementation creates a session, which may or may not be used and closed by users of the Sling Commons Auth AuthenticationSupport service. A mechanism must be implemented to ensure Sessions placed into the AuthenticationInfo by CredentialValidator implementations are not left open and thus needlessly consume system resources.