Hi, On 06.01.2010 14:30, Ian Boston wrote: > > On 6 Jan 2010, at 12:51, Felix Meschberger wrote: > >> Hi Ian, >> >> There was an Engine 2.0.6 release, which still contains the old >> authentication API. > > Ok cool, thanks we will give that a go. > >> >> The combo Engine trunk plus Commons Auth trunk is basically an extended >> situation of the Engine 2.0.6 release and all the 2.0.6 authentication >> functionality still works. > > I am getting reports of existing authn not working after r896344 (we have a > bunch of Ruby tests that do integration tests over http, and they are all > failing with authn issues.)
Ok, this is definitely not something which is expected and wanted. So we should definitely look into this. If you could provide Sling issues, I could help. > However we should probably investigate as all the Sling unit tests are > passing ok. Well, there are a few integration tests failing, too. So I am also investigating this area. Regards Felix > Ian > > >> >> Hope this helps. >> >> Regards >> Felix >> >> On 06.01.2010 12:07, Ian Boston wrote: >>> 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 >>>>>> >>> >>> > >
