Page History

...

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 I: 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.