Hi all, I have now committed the changes required for SLING-966 [1].
So, if you upgrade the Sling Engine to the latest trunk, you should also install the new Commons Auth bundle. Your existing AuthenticationHandler implementations will still be working. I have upgraded our own HTTP Basic and OpenID Authentication Handler implementations to make use of the new API from Commons Auth. I now will turn to documentation and try to clarify what has been written in [2]. Regards Felix [1] https://issues.apache.org/jira/browse/SLING-966 [2] http://sling.apache.org/site/authentication.html On 02.01.2010 16:29, Felix Meschberger wrote: > Hi, > > I have now implemented a prototype and attached the patch (againt Sling > trunk) to SLING-966 [1]. > > This patch relies on ServletRequestListener support (and a finalize() > method) for Session clean up. We could also (readd) the Sessio.logout > call in the Engine's SlingMainServlet for now... (though I would really > prefer pure ServletRequestListener support). > > This patch does not yet require the ResourceResolver[Factory] stuff but > of course would probably benefit from it as been pointed out on this thread. > > WDYT ? > > Regards > Felix > > [1] https://issues.apache.org/jira/browse/SLING-966 > > On 18.12.2009 08:20, Felix Meschberger wrote: >> Hi all, >> >> Currently Sling (the SlingMainServlet) is registered with the OSGi >> HttpService using an OSGi HttpContext whose handleSecurity method is >> implemented by means of the SlingAuthenticator class. This all is >> implemented in the Sling Engine bundle. See the code [1] and the >> documentation [2] for full details. >> >> This has a number of drawbacks: >> >> * Evolution of authentication provision and implementation >> is tied to the relatively unrelated Sling core implementation >> >> * The SlingAuthenticator class can only be used by servlets >> registered with Sling itself. Servlets registered directly >> with the OSGi HttpService have to implement the >> HttpContext.handleSecurity themselves, thus causing code >> duplication >> >> * The interaction between the SlingAuthenticator logging into >> the repository (Putting the session in a request attribute) >> and the SlingMainServlet using that session and logging it >> out after request termination is somewhat asynchronous. >> >> To remedy this situation, I propose to create a new bundle with the >> authentication stuff in the Engine bundle: The o.a.s.engine.auth and >> o.a.s.engine.impl.auth packages. >> >> This allows for re-use of the authentication mechanisms by other servlets. >> >> To enable authentication support a new Service interface is defined >> which allows to implement the handleSecurity method and which allows for >> proper cleanup at the end of the request. >> >> There are some options to consider, though, and an optimal solution >> escapes my mind right now... >> >> >> Option 1: Provide clean up API in the authentication service interface >> >> The service interface is defined as: >> >> public interface AuthenticationSupport { >> public boolean handleSecurity( >> HttpServletRequest, HttpServletResponse); >> public void endRequest(HttpServletRequest); >> } >> >> The handleSecurity method is meant to implement the >> HttpService.handleSecurity method. It is speced accordingly -- also >> requiring the request attributes to be set. Additionally, the method >> must set a ResourceResolver attribute (not a JCR session) for use by the >> client. >> >> The endRequest method must be called by the client when request >> processing has terminated. The intent is for the AuthenticationSupport >> service to cleanup -- namely logout an JCR session. >> >> The drawback of this option is, that it is assymmetric: HttpContext has >> to call handleSecurity, the registered Servlet has to call endRequest. >> >> Option 2: Implement ServletRequestListener >> >> The service interface is defined as: >> >> public interface AuthenticationSupport { >> public boolean handleSecurity( >> HttpServletRequest, HttpServletResponse); >> } >> >> The handleSecurity method is meant to implement the >> HttpService.handleSecurity method. It is speced accordingly -- also >> requiring the request attributes to be set. Additionally, the method >> must set a ResourceResolver attribute (not a JCR session) for use by the >> client. >> >> In addition the SlingAuthenticator registers itself as a >> ServletRequestListener handling the requestDestroyed method to cleanup >> any setups from the handleSecurity method, namely logging out JCR >> Session(s). >> >> The drawback of this option is, that it requires support to register a >> ServletRequestListener. This is something which is not supported by the >> HttpService spec and thus may only be supported by extended >> implementation (or any future HttpService or similar spec). >> >> >> WDYT ? >> >> Regards >> Felix >> >> >> [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/engine >> [2] http://sling.apache.org/site/authentication.html >>
