Felix, Were there recent releases of the bundles in question before this change was made. I am < 1 week away from cutting a release and we have some major bits of work in the AuthN area, including container and CAS authn modules. I suspect that the porting effort is going to be minimal but the guys who did our CAS authn code have been moved off the project.
Ian On 6 Jan 2010, at 10:49, Felix Meschberger wrote: > 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 >>>
