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 ?
>
I think creating an own bundle makes definitly sense - as you outlined
both options (API or listener) have pros and cons; from a developer
perspective a favour the API way as it is easier to forget a
configuration of a listener than to call the api. In the end we could
provide both ways by having the api with the endRequest(...) method and
providing a listener which just calls this method.
For the package name o.a.s.engine.auth I'm not sure :) wouldn't this be
something which has common character? And maybe might be used by the
Felix web console as well? So I would favour something like
o.a.s.commons.auth.
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
