You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2009/12/18 08:20:51 UTC
Creating an authentication support bundle
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
Re: Creating an authentication support bundle
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Dec 31, 2009 at 14:49, Mike Müller <mi...@mysign.ch> wrote:
> But what if the authentication
> process has nothing to do with the JCR, what if someone authenticate to a separate
> system.
The idea is that when JCR is the basis for the application (what Sling
is mostly about), the actual authentication must happen inside the
repository. That means, if you have a different, external login
mechanism like ldap, it should be handled by a (custom) LoginModule in
Jackrabbit. Therefore it makes sense to simplify Sling for this major
use case. And I also think that every resource resolver works based on
the authenticated user.
Do you have a counter-example?
> To solve the performance issue an AuthenticationSupport can put an context
> attribute with the ResourceResolver and the ResourceResolverFactory can
> pick up that ResourceResolver.
Agreed, that might be a solution if needed.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Yes, I know and (partly) agree with them. This is why the finalize()
method is only a second-level measure. The primary measure to ensure
sessions are logged out is the RequestEventListener which cleans up
after the request.
Regards
Felix
On 02.01.2010 15:55, Julian Sedding wrote:
>> In addition the AuthenticationSupport class has two safety nets to
>> ensure the ResourceResolver (and underlying repository connections such
>> as JCR Sessions or JDBC Connections) are released: (1) Implements and
>> registers ServletRequestListener (requires support by the Http Service
>> implementation, see FELIX-1962) and (2) implements a finalize() method
>> as a fallback if ServiceRequestListener mechanism is not readily available.
>
> I wonder if the second safety net doesn't cause more trouble then it
> is worth. In Java Concurrency In Practice, Brian Goetz recommends to
> avoid using finalizers[1] for several reasons, stating only a single
> exception: releasing resources acquired by native methods.
>
> Furthermore, both Brian Goetz and Kas Thomas in a blog post[2]
> mention that there is no guarantee that the finalize method gets
> called at all.
>
> Regards
> Julian
>
> [1] http://book.javanb.com/java-concurrency-in-Practice/ch07lev1sec4.html#title-IDAW44TX
> [2] http://asserttrue.blogspot.com/2008/11/finalization-is-evil.html
>
>
> On Sat, Jan 2, 2010 at 1:46 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> Hi,
>>
>> On 31.12.2009 14:49, Mike Müller wrote:
>>> Hi
>>>
>>>> On 28.12.2009 17:08, Carsten Ziegeler wrote:
>>>>> When we're doing changes in this area, we might also look
>>>> at the same
>>>>> time at one of the things which is on our todo list for a
>>>> long time :)
>>>>>
>>>>> The basic question: how to get a resource resolver?
>>>>>
>>>> (http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/
>>> 200811.mbox/%3C491727D7.4070804@gmail.com%3E)
>>>
>>>> Yes, we should definitely pick this up again ....
>>>
>>>>
>>>> >From a Sling perspective I guess after authentication happend, a
>>>>> resource resolver for the current user is available (somehow) - we
>>>>> shouldn't use the session approach like we have now. Therefore looking
>>>>> at how to create a resource resolver from some factory might be help here.
>>>
>>>> Agreed, regardless of the above the standalone authenticator will
>>>> provide a ResourceResolver and not a Session as a request attribute.
>>>
>>> At the risk of coming a little bit late into this discussion I nevertheless
>>> try to give my point of view. I really think while changing the authentication
>>> process we should consider of implementing what Felix proposes on [1] for
>>> an ResourceResolverFactory. I would like to have the authentication process
>>> even more decoupled from JCR and the ResourceResolver. The authentication
>>> process should authenticate the user and that's it. To force this process also
>>> to set an attribute with the ResourceResolver doesn't make sense in every
>>> case.
>>
>> Conceptionaally, this is correct, and I agree -- and from the bottom of
>> my conceptionally correct heart, we would have to do this, but ....
>>
>>> To be honest I think the only reason to do this is to get a better
>>> performance because the JCR session can be reused.
>>
>> Performance is one aspect in this equation (a very important one,
>> though). Another aspect is, that the authentication handlers extract
>> credentials from the request which are used (a) to validate the
>> requestor's identity and (b) to actually get access to the
>> system/repository.
>>
>> If we go conceptionally clean, we would have to extract credentials
>> twice (duplicate implementation ? multiple uses of the same
>> implementations ? how ?). So we would probably end with an even bigger
>> "mess".
>>
>>> But what if the authentication
>>> process has nothing to do with the JCR, what if someone authenticate to a separate
>>> system. It would be possible to use Sling in that case, but the implementation
>>> of the AuthenticationSupport has to allocate an ResourveResolver which should
>>> be the work of the new ResourceResolverFactory ([1]). That doesn't mean that
>>> the implementation AuthenticationSupport can not put a ResourceResolver or
>>> whatever as an attribute in the context, but it shouldn't forced to do so.
>>> AuthenticationSupport should only be responsible to put some basic information
>>> about the authentication into the context (like username, userid, authtype).
>>
>> Yes and/or now. Yet, Sling is centered around having a ResourceResolver
>> available to process requests. So it is IMHO ok for the
>> AuthenticationSupport class to not only handle credential extraction but
>> also provisioning of the ResourceResolver to be used for request handling.
>>
>> As such this is an extension to the HttpContext.handleSecurity
>> specification, which mandates the user name, authentication type and
>> (optionally) the OSGi Authorization object.
>>
>>>
>>> Maybe I haven't get the idea right: If we implement not only the
>>> AuthenticationSupport but also the ResourceResolverFactory [1], why should
>>> the implementation of AuthenticationSupport select and call the
>>> ResourceResolverFactory to get an ResourceResolver and put it into the
>>> context? Can't we decouple the authentication completely from the getting
>>> of a ResourceResolver? I think to couple these two things adds not necessary
>>> complexity without adding additional possabilities.
>>
>> Yes, while creating other problems ...
>>
>> Of course we could specify the AuthenticationSupport class to provide a
>> credentials map to be used with the new ResourceResolverFactory. But to
>> what avail ? Why not return the ResourceResolver directly ?
>>
>>> Wouldn't that also solve the problem with the unattractive endRequest, because
>>> in this case the Sling engine, which would get the ResourceResolver, would be
>>> in charge to call the close method which could logout the session or whatever.
>>
>> I already abandone the "endRequest" idea already ...
>>
>>>
>>> To solve the performance issue an AuthenticationSupport can put an context
>>> attribute with the ResourceResolver and the ResourceResolverFactory can
>>> pick up that ResourceResolver. In that case the getResourceResolver method
>>> on ResourceResolverFactory maybe should also get the HttpServletRequest.
>>> If the ResourceResolverFactory doesn't pick up the ResourceResolver we must
>>> find a way to logout the JCR session. Maybe by a ServletContextAttributeListener
>>> or the finalize() method.
>>
>> This is what is currently done: The AuthenticationSupport service places
>> the ResourceResolver to be used by the request as a request attribute
>> (replacing the Session which is currently set as a request attribute for
>> this purpose).
>>
>> In addition the AuthenticationSupport class has two safety nets to
>> ensure the ResourceResolver (and underlying repository connections such
>> as JCR Sessions or JDBC Connections) are released: (1) Implements and
>> registers ServletRequestListener (requires support by the Http Service
>> implementation, see FELIX-1962) and (2) implements a finalize() method
>> as a fallback if ServiceRequestListener mechanism is not readily available.
>>
>> Regards
>> Felix
>>
>>>
>>> best regards
>>> mike
>>>
>>> [1] http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
>>
>>
>
Re: Creating an authentication support bundle
Posted by Julian Sedding <js...@day.com>.
> In addition the AuthenticationSupport class has two safety nets to
> ensure the ResourceResolver (and underlying repository connections such
> as JCR Sessions or JDBC Connections) are released: (1) Implements and
> registers ServletRequestListener (requires support by the Http Service
> implementation, see FELIX-1962) and (2) implements a finalize() method
> as a fallback if ServiceRequestListener mechanism is not readily available.
I wonder if the second safety net doesn't cause more trouble then it
is worth. In Java Concurrency In Practice, Brian Goetz recommends to
avoid using finalizers[1] for several reasons, stating only a single
exception: releasing resources acquired by native methods.
Furthermore, both Brian Goetz and Kas Thomas in a blog post[2]
mention that there is no guarantee that the finalize method gets
called at all.
Regards
Julian
[1] http://book.javanb.com/java-concurrency-in-Practice/ch07lev1sec4.html#title-IDAW44TX
[2] http://asserttrue.blogspot.com/2008/11/finalization-is-evil.html
On Sat, Jan 2, 2010 at 1:46 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> On 31.12.2009 14:49, Mike Müller wrote:
>> Hi
>>
>>> On 28.12.2009 17:08, Carsten Ziegeler wrote:
>>>> When we're doing changes in this area, we might also look
>>> at the same
>>>> time at one of the things which is on our todo list for a
>>> long time :)
>>>>
>>>> The basic question: how to get a resource resolver?
>>>>
>>> (http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/
>> 200811.mbox/%3C491727D7.4070804@gmail.com%3E)
>>
>>> Yes, we should definitely pick this up again ....
>>
>>>
>>> >From a Sling perspective I guess after authentication happend, a
>>>> resource resolver for the current user is available (somehow) - we
>>>> shouldn't use the session approach like we have now. Therefore looking
>>>> at how to create a resource resolver from some factory might be help here.
>>
>>> Agreed, regardless of the above the standalone authenticator will
>>> provide a ResourceResolver and not a Session as a request attribute.
>>
>> At the risk of coming a little bit late into this discussion I nevertheless
>> try to give my point of view. I really think while changing the authentication
>> process we should consider of implementing what Felix proposes on [1] for
>> an ResourceResolverFactory. I would like to have the authentication process
>> even more decoupled from JCR and the ResourceResolver. The authentication
>> process should authenticate the user and that's it. To force this process also
>> to set an attribute with the ResourceResolver doesn't make sense in every
>> case.
>
> Conceptionaally, this is correct, and I agree -- and from the bottom of
> my conceptionally correct heart, we would have to do this, but ....
>
>> To be honest I think the only reason to do this is to get a better
>> performance because the JCR session can be reused.
>
> Performance is one aspect in this equation (a very important one,
> though). Another aspect is, that the authentication handlers extract
> credentials from the request which are used (a) to validate the
> requestor's identity and (b) to actually get access to the
> system/repository.
>
> If we go conceptionally clean, we would have to extract credentials
> twice (duplicate implementation ? multiple uses of the same
> implementations ? how ?). So we would probably end with an even bigger
> "mess".
>
>> But what if the authentication
>> process has nothing to do with the JCR, what if someone authenticate to a separate
>> system. It would be possible to use Sling in that case, but the implementation
>> of the AuthenticationSupport has to allocate an ResourveResolver which should
>> be the work of the new ResourceResolverFactory ([1]). That doesn't mean that
>> the implementation AuthenticationSupport can not put a ResourceResolver or
>> whatever as an attribute in the context, but it shouldn't forced to do so.
>> AuthenticationSupport should only be responsible to put some basic information
>> about the authentication into the context (like username, userid, authtype).
>
> Yes and/or now. Yet, Sling is centered around having a ResourceResolver
> available to process requests. So it is IMHO ok for the
> AuthenticationSupport class to not only handle credential extraction but
> also provisioning of the ResourceResolver to be used for request handling.
>
> As such this is an extension to the HttpContext.handleSecurity
> specification, which mandates the user name, authentication type and
> (optionally) the OSGi Authorization object.
>
>>
>> Maybe I haven't get the idea right: If we implement not only the
>> AuthenticationSupport but also the ResourceResolverFactory [1], why should
>> the implementation of AuthenticationSupport select and call the
>> ResourceResolverFactory to get an ResourceResolver and put it into the
>> context? Can't we decouple the authentication completely from the getting
>> of a ResourceResolver? I think to couple these two things adds not necessary
>> complexity without adding additional possabilities.
>
> Yes, while creating other problems ...
>
> Of course we could specify the AuthenticationSupport class to provide a
> credentials map to be used with the new ResourceResolverFactory. But to
> what avail ? Why not return the ResourceResolver directly ?
>
>> Wouldn't that also solve the problem with the unattractive endRequest, because
>> in this case the Sling engine, which would get the ResourceResolver, would be
>> in charge to call the close method which could logout the session or whatever.
>
> I already abandone the "endRequest" idea already ...
>
>>
>> To solve the performance issue an AuthenticationSupport can put an context
>> attribute with the ResourceResolver and the ResourceResolverFactory can
>> pick up that ResourceResolver. In that case the getResourceResolver method
>> on ResourceResolverFactory maybe should also get the HttpServletRequest.
>> If the ResourceResolverFactory doesn't pick up the ResourceResolver we must
>> find a way to logout the JCR session. Maybe by a ServletContextAttributeListener
>> or the finalize() method.
>
> This is what is currently done: The AuthenticationSupport service places
> the ResourceResolver to be used by the request as a request attribute
> (replacing the Session which is currently set as a request attribute for
> this purpose).
>
> In addition the AuthenticationSupport class has two safety nets to
> ensure the ResourceResolver (and underlying repository connections such
> as JCR Sessions or JDBC Connections) are released: (1) Implements and
> registers ServletRequestListener (requires support by the Http Service
> implementation, see FELIX-1962) and (2) implements a finalize() method
> as a fallback if ServiceRequestListener mechanism is not readily available.
>
> Regards
> Felix
>
>>
>> best regards
>> mike
>>
>> [1] http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
>
>
Re: Creating an authentication support bundle
Posted by J Aaron Farr <fa...@apache.org>.
On Tue 05 Jan 2010 01:47, Carsten Ziegeler <cz...@apache.org> wrote:
>
> I completly agree and actually this login sample bundle is on my todo
> list (for a long time now....), so if noone beats me, I'll try to add it
> in the next weeks.
Thanks, Carsten.
I wanted to figure it out myself, but I've run out of time trying. If
you can provide some code, I'll happily write up more documentation
around it.
--
J. Aaron Farr
馮傑仁
www.cubiclemuses.com
Re: Creating an authentication support bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
J Aaron Farr wrote:
> On Sun 03 Jan 2010 11:27, Felix Meschberger <fm...@gmail.com> wrote:
>> Its actually (almost) all there:
>> http://sling.apache.org/site/authentication.html
>>
>> ... granted, it may not all be completely understandable
>
> Can I emphasize this point?
>
> Over the holiday I was trying to figure out the correct way to build a
> simple login form. It stumped me for days and I'm still not sure if I
> have it right.
>
> Ideally, there would be a sample bundle that provides:
>
> - simple login form for an admin section of the website
> - user sign up
> - user profile page
> - user password update form
> - sample admin-only user manager site (add, remove users)
>
> Plenty of people are going to want to build something like this. Most
> everyone. The sample user bundle doesn't need to cover every case.
> It's just to illustrate the simplest way to get started.
>
> Having spent the last several years over in Ruby/Rails land, this sort
> of thing is easy, even if there wasn't a plugin that got you that far in
> just two simple steps. Sling would be much more approachable if the
> project had similar "getting started" bundles.
>
I completly agree and actually this login sample bundle is on my todo
list (for a long time now....), so if noone beats me, I'll try to add it
in the next weeks.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Creating an authentication support bundle
Posted by J Aaron Farr <fa...@apache.org>.
On Sun 03 Jan 2010 11:27, Felix Meschberger <fm...@gmail.com> wrote:
> Its actually (almost) all there:
> http://sling.apache.org/site/authentication.html
>
> ... granted, it may not all be completely understandable
Can I emphasize this point?
Over the holiday I was trying to figure out the correct way to build a
simple login form. It stumped me for days and I'm still not sure if I
have it right.
Ideally, there would be a sample bundle that provides:
- simple login form for an admin section of the website
- user sign up
- user profile page
- user password update form
- sample admin-only user manager site (add, remove users)
Plenty of people are going to want to build something like this. Most
everyone. The sample user bundle doesn't need to cover every case.
It's just to illustrate the simplest way to get started.
Having spent the last several years over in Ruby/Rails land, this sort
of thing is easy, even if there wasn't a plugin that got you that far in
just two simple steps. Sling would be much more approachable if the
project had similar "getting started" bundles.
--
J. Aaron Farr
馮傑仁
www.cubiclemuses.com
RE: Creating an authentication support bundle
Posted by Mike Müller <mi...@mysign.ch>.
> > Yes, thanks.
> > I definitively have to write a new docu page after all is committed.
> > Because all the authentication stuff is grown over time, it got
> > a bit confusing on the first sight.
>
> Its actually (almost) all there:
> http://sling.apache.org/site/authentication.html
>
> ... granted, it may not all be completely understandable
I promise I will update it, upon all your stuff is committed.
After beeing a little bit off the list (actually not from reading
only from writing to it ;-)) I hope I can do more in the near
future for Sling.
best regards
mike
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 02.01.2010 21:41, Mike Müller wrote:
>> No problems, and I hope my explanation above shows this directions ...
>
> Yes, thanks.
> I definitively have to write a new docu page after all is committed.
> Because all the authentication stuff is grown over time, it got
> a bit confusing on the first sight.
Its actually (almost) all there:
http://sling.apache.org/site/authentication.html
... granted, it may not all be completely understandable
Regards
Felix
RE: Creating an authentication support bundle
Posted by Mike Müller <mi...@mysign.ch>.
>>> snip snap
> > Just to make sure I understand it right I try to summarize:
> > An implementation of AuthenticationHandler should use the
> Sling service
> > ResourceResolverFactory and call
> getResourceResolver(credentials) on it
> > to get the ResourceResolver. The Sling
> ResourceResolverFactory itself
> > tries to get ResourceProviders via the one ore more
> ResourceProviderFactory
> > implementations providing the JCR session as an attribute
> in the credentials
> > map.
>
> This is wrong: An AuthenticationHandler returns an AuthenticationInfo
> object which provides the JCR credentials for login (plus the
> authentication type plus optionally a workspace to log in to).
>
> The SlingAuthenticator class uses this AuthenticationInfo to actually
> log into the repository -- or with the new concept -- to get a
> ResourceResolver from the factory.
That was a typo of me, sorry. I haven't meant the AuthenticationHandler but
the AuthenticationSupport which really does log in but uses the
AuthenticationHandler to get the AuthenticationInfo.
>
> > The Sling implementation of ResourceProviderFactory would
> assure that all
> > already existing ResourceProvider implementations (which
> are registered) will
> > get collected. With the new ResourceProviderFactory it
> would be possible
> > to bring some new ResourceProviders in, which aren't registered as
> > ResourceProvider implementations in OSGi but implement
> ResourceProvider.
> > Is that right?
>
> Ehrm .. not quite. See above for the full explanation.
>
> > Sorry if that sounds all weired, maybe I need some directions...
>
> No problems, and I hope my explanation above shows this directions ...
Yes, thanks.
I definitively have to write a new docu page after all is committed.
Because all the authentication stuff is grown over time, it got
a bit confusing on the first sight.
best regards
mike
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 02.01.2010 15:13, Mike Müller wrote:
>> On 31.12.2009 14:49, Mike Müller wrote:
>>> Hi
>>>
>>>> On 28.12.2009 17:08, Carsten Ziegeler wrote:
>>>>> When we're doing changes in this area, we might also look
>>>> at the same
>>>>> time at one of the things which is on our todo list for a
>>>> long time :)
>>>>>
>>>>> The basic question: how to get a resource resolver?
>>>>>
>>>> (http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/
>>> 200811.mbox/%3C491727D7.4070804@gmail.com%3E)
>>>
>>>> Yes, we should definitely pick this up again ....
>>>
>>>>
>>>> >From a Sling perspective I guess after authentication happend, a
>>>>> resource resolver for the current user is available (somehow) - we
>>>>> shouldn't use the session approach like we have now.
>> Therefore looking
>>>>> at how to create a resource resolver from some factory
>> might be help here.
>>>
>>>> Agreed, regardless of the above the standalone authenticator will
>>>> provide a ResourceResolver and not a Session as a request
>> attribute.
>>>
>>> At the risk of coming a little bit late into this
>> discussion I nevertheless
>>> try to give my point of view. I really think while changing
>> the authentication
>>> process we should consider of implementing what Felix
>> proposes on [1] for
>>> an ResourceResolverFactory. I would like to have the
>> authentication process
>>> even more decoupled from JCR and the ResourceResolver. The
>> authentication
>>> process should authenticate the user and that's it. To
>> force this process also
>>> to set an attribute with the ResourceResolver doesn't make
>> sense in every
>>> case.
>>
>> Conceptionaally, this is correct, and I agree -- and from the
>> bottom of
>> my conceptionally correct heart, we would have to do this, but ....
>>
>>> To be honest I think the only reason to do this is to get a better
>>> performance because the JCR session can be reused.
>>
>> Performance is one aspect in this equation (a very important one,
>> though). Another aspect is, that the authentication handlers extract
>> credentials from the request which are used (a) to validate the
>> requestor's identity and (b) to actually get access to the
>> system/repository.
>>
>> If we go conceptionally clean, we would have to extract credentials
>> twice (duplicate implementation ? multiple uses of the same
>> implementations ? how ?). So we would probably end with an even bigger
>> "mess".
>>
>>> But what if the authentication
>>> process has nothing to do with the JCR, what if someone
>> authenticate to a separate
>>> system. It would be possible to use Sling in that case, but
>> the implementation
>>> of the AuthenticationSupport has to allocate an
>> ResourveResolver which should
>>> be the work of the new ResourceResolverFactory ([1]). That
>> doesn't mean that
>>> the implementation AuthenticationSupport can not put a
>> ResourceResolver or
>>> whatever as an attribute in the context, but it shouldn't
>> forced to do so.
>>> AuthenticationSupport should only be responsible to put
>> some basic information
>>> about the authentication into the context (like username,
>> userid, authtype).
>>
>> Yes and/or now. Yet, Sling is centered around having a
>> ResourceResolver
>> available to process requests. So it is IMHO ok for the
>> AuthenticationSupport class to not only handle credential
>> extraction but
>> also provisioning of the ResourceResolver to be used for
>> request handling.
>>
>> As such this is an extension to the HttpContext.handleSecurity
>> specification, which mandates the user name, authentication type and
>> (optionally) the OSGi Authorization object.
>
> Ok, I agree on this. Sling in this case not only expects a logged in user,
> but also a ResourceResolver because Sling is very resource centric.
> Sounds reasonable.
;-)
> With that point of view the ResourceResolverFactory is just a convenience
> service from Sling to log into the JCR and get the JCRResourceResolver,
> via the Sling implementation of ResourceProviderFactory which tries
> getResourceProvider(Map<String, Object> credentials) if credentals are
> present and getAnonymousResourceProvider(Map<String, Object> credentials)
> if no credentials are present. I guess I didn't get that right, because
> in this case the paramter "credentials" is needless on that method?
> Or is it used to put the JCR session into the method?
Now, it gets a little more involved (and unrelated to the authentication
support per-se).
ResourceResolverFactory (in the new concept) is the factory, which hands
out ResourceResolver instances. The factory does this with the help of
ResourceProvider services and ResourceProviderFactory services.
As today a ResourceResolver does its work with the help of
ResourceProvider instances, which are collected into a virtual tree and
thus help implement the (virtual) resource tree.
The ResourceProviderFactory services are use to create "short-lived"
ResourceProvider instances, which are used only a for a single
ResourceProvider. If a ResourceProvider is closed, the ResourceProvider
instances created using a ResourceProviderFactory are also closed and
dropped.
The ResourceProviderFactory methods all get the credentials map to be
able to get more information such as a default workspace to use. This
latter information is very important for the
getAdministrativeResourceProvider and getAnonymousResourceProvider in
the JCR case to select to correct workspace.
For other ResourceProviderFactory methods, the credentials map may
provide different information...
>
> Just to make sure I understand it right I try to summarize:
> An implementation of AuthenticationHandler should use the Sling service
> ResourceResolverFactory and call getResourceResolver(credentials) on it
> to get the ResourceResolver. The Sling ResourceResolverFactory itself
> tries to get ResourceProviders via the one ore more ResourceProviderFactory
> implementations providing the JCR session as an attribute in the credentials
> map.
This is wrong: An AuthenticationHandler returns an AuthenticationInfo
object which provides the JCR credentials for login (plus the
authentication type plus optionally a workspace to log in to).
The SlingAuthenticator class uses this AuthenticationInfo to actually
log into the repository -- or with the new concept -- to get a
ResourceResolver from the factory.
> The Sling implementation of ResourceProviderFactory would assure that all
> already existing ResourceProvider implementations (which are registered) will
> get collected. With the new ResourceProviderFactory it would be possible
> to bring some new ResourceProviders in, which aren't registered as
> ResourceProvider implementations in OSGi but implement ResourceProvider.
> Is that right?
Ehrm .. not quite. See above for the full explanation.
> Sorry if that sounds all weired, maybe I need some directions...
No problems, and I hope my explanation above shows this directions ...
Regards
Felix
>
> best regards
> mike
RE: Creating an authentication support bundle
Posted by Mike Müller <mi...@mysign.ch>.
> On 31.12.2009 14:49, Mike Müller wrote:
> > Hi
> >
> >> On 28.12.2009 17:08, Carsten Ziegeler wrote:
> >>> When we're doing changes in this area, we might also look
> >> at the same
> >>> time at one of the things which is on our todo list for a
> >> long time :)
> >>>
> >>> The basic question: how to get a resource resolver?
> >>>
> >> (http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/
> > 200811.mbox/%3C491727D7.4070804@gmail.com%3E)
> >
> >> Yes, we should definitely pick this up again ....
> >
> >>
> >> >From a Sling perspective I guess after authentication happend, a
> >>> resource resolver for the current user is available (somehow) - we
> >>> shouldn't use the session approach like we have now.
> Therefore looking
> >>> at how to create a resource resolver from some factory
> might be help here.
> >
> >> Agreed, regardless of the above the standalone authenticator will
> >> provide a ResourceResolver and not a Session as a request
> attribute.
> >
> > At the risk of coming a little bit late into this
> discussion I nevertheless
> > try to give my point of view. I really think while changing
> the authentication
> > process we should consider of implementing what Felix
> proposes on [1] for
> > an ResourceResolverFactory. I would like to have the
> authentication process
> > even more decoupled from JCR and the ResourceResolver. The
> authentication
> > process should authenticate the user and that's it. To
> force this process also
> > to set an attribute with the ResourceResolver doesn't make
> sense in every
> > case.
>
> Conceptionaally, this is correct, and I agree -- and from the
> bottom of
> my conceptionally correct heart, we would have to do this, but ....
>
> > To be honest I think the only reason to do this is to get a better
> > performance because the JCR session can be reused.
>
> Performance is one aspect in this equation (a very important one,
> though). Another aspect is, that the authentication handlers extract
> credentials from the request which are used (a) to validate the
> requestor's identity and (b) to actually get access to the
> system/repository.
>
> If we go conceptionally clean, we would have to extract credentials
> twice (duplicate implementation ? multiple uses of the same
> implementations ? how ?). So we would probably end with an even bigger
> "mess".
>
> > But what if the authentication
> > process has nothing to do with the JCR, what if someone
> authenticate to a separate
> > system. It would be possible to use Sling in that case, but
> the implementation
> > of the AuthenticationSupport has to allocate an
> ResourveResolver which should
> > be the work of the new ResourceResolverFactory ([1]). That
> doesn't mean that
> > the implementation AuthenticationSupport can not put a
> ResourceResolver or
> > whatever as an attribute in the context, but it shouldn't
> forced to do so.
> > AuthenticationSupport should only be responsible to put
> some basic information
> > about the authentication into the context (like username,
> userid, authtype).
>
> Yes and/or now. Yet, Sling is centered around having a
> ResourceResolver
> available to process requests. So it is IMHO ok for the
> AuthenticationSupport class to not only handle credential
> extraction but
> also provisioning of the ResourceResolver to be used for
> request handling.
>
> As such this is an extension to the HttpContext.handleSecurity
> specification, which mandates the user name, authentication type and
> (optionally) the OSGi Authorization object.
Ok, I agree on this. Sling in this case not only expects a logged in user,
but also a ResourceResolver because Sling is very resource centric.
Sounds reasonable.
With that point of view the ResourceResolverFactory is just a convenience
service from Sling to log into the JCR and get the JCRResourceResolver,
via the Sling implementation of ResourceProviderFactory which tries
getResourceProvider(Map<String, Object> credentials) if credentals are
present and getAnonymousResourceProvider(Map<String, Object> credentials)
if no credentials are present. I guess I didn't get that right, because
in this case the paramter "credentials" is needless on that method?
Or is it used to put the JCR session into the method?
Just to make sure I understand it right I try to summarize:
An implementation of AuthenticationHandler should use the Sling service
ResourceResolverFactory and call getResourceResolver(credentials) on it
to get the ResourceResolver. The Sling ResourceResolverFactory itself
tries to get ResourceProviders via the one ore more ResourceProviderFactory
implementations providing the JCR session as an attribute in the credentials
map.
The Sling implementation of ResourceProviderFactory would assure that all
already existing ResourceProvider implementations (which are registered) will
get collected. With the new ResourceProviderFactory it would be possible
to bring some new ResourceProviders in, which aren't registered as
ResourceProvider implementations in OSGi but implement ResourceProvider.
Is that right?
Sorry if that sounds all weired, maybe I need some directions...
best regards
mike
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 31.12.2009 14:49, Mike Müller wrote:
> Hi
>
>> On 28.12.2009 17:08, Carsten Ziegeler wrote:
>>> When we're doing changes in this area, we might also look
>> at the same
>>> time at one of the things which is on our todo list for a
>> long time :)
>>>
>>> The basic question: how to get a resource resolver?
>>>
>> (http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/
> 200811.mbox/%3C491727D7.4070804@gmail.com%3E)
>
>> Yes, we should definitely pick this up again ....
>
>>
>> >From a Sling perspective I guess after authentication happend, a
>>> resource resolver for the current user is available (somehow) - we
>>> shouldn't use the session approach like we have now. Therefore looking
>>> at how to create a resource resolver from some factory might be help here.
>
>> Agreed, regardless of the above the standalone authenticator will
>> provide a ResourceResolver and not a Session as a request attribute.
>
> At the risk of coming a little bit late into this discussion I nevertheless
> try to give my point of view. I really think while changing the authentication
> process we should consider of implementing what Felix proposes on [1] for
> an ResourceResolverFactory. I would like to have the authentication process
> even more decoupled from JCR and the ResourceResolver. The authentication
> process should authenticate the user and that's it. To force this process also
> to set an attribute with the ResourceResolver doesn't make sense in every
> case.
Conceptionaally, this is correct, and I agree -- and from the bottom of
my conceptionally correct heart, we would have to do this, but ....
> To be honest I think the only reason to do this is to get a better
> performance because the JCR session can be reused.
Performance is one aspect in this equation (a very important one,
though). Another aspect is, that the authentication handlers extract
credentials from the request which are used (a) to validate the
requestor's identity and (b) to actually get access to the
system/repository.
If we go conceptionally clean, we would have to extract credentials
twice (duplicate implementation ? multiple uses of the same
implementations ? how ?). So we would probably end with an even bigger
"mess".
> But what if the authentication
> process has nothing to do with the JCR, what if someone authenticate to a separate
> system. It would be possible to use Sling in that case, but the implementation
> of the AuthenticationSupport has to allocate an ResourveResolver which should
> be the work of the new ResourceResolverFactory ([1]). That doesn't mean that
> the implementation AuthenticationSupport can not put a ResourceResolver or
> whatever as an attribute in the context, but it shouldn't forced to do so.
> AuthenticationSupport should only be responsible to put some basic information
> about the authentication into the context (like username, userid, authtype).
Yes and/or now. Yet, Sling is centered around having a ResourceResolver
available to process requests. So it is IMHO ok for the
AuthenticationSupport class to not only handle credential extraction but
also provisioning of the ResourceResolver to be used for request handling.
As such this is an extension to the HttpContext.handleSecurity
specification, which mandates the user name, authentication type and
(optionally) the OSGi Authorization object.
>
> Maybe I haven't get the idea right: If we implement not only the
> AuthenticationSupport but also the ResourceResolverFactory [1], why should
> the implementation of AuthenticationSupport select and call the
> ResourceResolverFactory to get an ResourceResolver and put it into the
> context? Can't we decouple the authentication completely from the getting
> of a ResourceResolver? I think to couple these two things adds not necessary
> complexity without adding additional possabilities.
Yes, while creating other problems ...
Of course we could specify the AuthenticationSupport class to provide a
credentials map to be used with the new ResourceResolverFactory. But to
what avail ? Why not return the ResourceResolver directly ?
> Wouldn't that also solve the problem with the unattractive endRequest, because
> in this case the Sling engine, which would get the ResourceResolver, would be
> in charge to call the close method which could logout the session or whatever.
I already abandone the "endRequest" idea already ...
>
> To solve the performance issue an AuthenticationSupport can put an context
> attribute with the ResourceResolver and the ResourceResolverFactory can
> pick up that ResourceResolver. In that case the getResourceResolver method
> on ResourceResolverFactory maybe should also get the HttpServletRequest.
> If the ResourceResolverFactory doesn't pick up the ResourceResolver we must
> find a way to logout the JCR session. Maybe by a ServletContextAttributeListener
> or the finalize() method.
This is what is currently done: The AuthenticationSupport service places
the ResourceResolver to be used by the request as a request attribute
(replacing the Session which is currently set as a request attribute for
this purpose).
In addition the AuthenticationSupport class has two safety nets to
ensure the ResourceResolver (and underlying repository connections such
as JCR Sessions or JDBC Connections) are released: (1) Implements and
registers ServletRequestListener (requires support by the Http Service
implementation, see FELIX-1962) and (2) implements a finalize() method
as a fallback if ServiceRequestListener mechanism is not readily available.
Regards
Felix
>
> best regards
> mike
>
> [1] http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
RE: Creating an authentication support bundle
Posted by Mike Müller <mi...@mysign.ch>.
Hi
> On 28.12.2009 17:08, Carsten Ziegeler wrote:
> > When we're doing changes in this area, we might also look
> at the same
> > time at one of the things which is on our todo list for a
> long time :)
> >
> > The basic question: how to get a resource resolver?
> >
> (http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/
200811.mbox/%3C491727D7.4070804@gmail.com%3E)
>Yes, we should definitely pick this up again ....
>
>>From a Sling perspective I guess after authentication happend, a
>> resource resolver for the current user is available (somehow) - we
>> shouldn't use the session approach like we have now. Therefore looking
>> at how to create a resource resolver from some factory might be help here.
>Agreed, regardless of the above the standalone authenticator will
>provide a ResourceResolver and not a Session as a request attribute.
At the risk of coming a little bit late into this discussion I nevertheless
try to give my point of view. I really think while changing the authentication
process we should consider of implementing what Felix proposes on [1] for
an ResourceResolverFactory. I would like to have the authentication process
even more decoupled from JCR and the ResourceResolver. The authentication
process should authenticate the user and that's it. To force this process also
to set an attribute with the ResourceResolver doesn't make sense in every
case. To be honest I think the only reason to do this is to get a better
performance because the JCR session can be reused. But what if the authentication
process has nothing to do with the JCR, what if someone authenticate to a separate
system. It would be possible to use Sling in that case, but the implementation
of the AuthenticationSupport has to allocate an ResourveResolver which should
be the work of the new ResourceResolverFactory ([1]). That doesn't mean that
the implementation AuthenticationSupport can not put a ResourceResolver or
whatever as an attribute in the context, but it shouldn't forced to do so.
AuthenticationSupport should only be responsible to put some basic information
about the authentication into the context (like username, userid, authtype).
Maybe I haven't get the idea right: If we implement not only the
AuthenticationSupport but also the ResourceResolverFactory [1], why should
the implementation of AuthenticationSupport select and call the
ResourceResolverFactory to get an ResourceResolver and put it into the
context? Can't we decouple the authentication completely from the getting
of a ResourceResolver? I think to couple these two things adds not necessary
complexity without adding additional possabilities.
Wouldn't that also solve the problem with the unattractive endRequest, because
in this case the Sling engine, which would get the ResourceResolver, would be
in charge to call the close method which could logout the session or whatever.
To solve the performance issue an AuthenticationSupport can put an context
attribute with the ResourceResolver and the ResourceResolverFactory can
pick up that ResourceResolver. In that case the getResourceResolver method
on ResourceResolverFactory maybe should also get the HttpServletRequest.
If the ResourceResolverFactory doesn't pick up the ResourceResolver we must
find a way to logout the JCR session. Maybe by a ServletContextAttributeListener
or the finalize() method.
best regards
mike
[1] http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 28.12.2009 17:08, Carsten Ziegeler wrote:
> When we're doing changes in this area, we might also look at the same
> time at one of the things which is on our todo list for a long time :)
>
> The basic question: how to get a resource resolver?
> (http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/200811.mbox/%3C491727D7.4070804@gmail.com%3E)
Yes, we should definitely pick this up again ....
>
>>>From a Sling perspective I guess after authentication happend, a
> resource resolver for the current user is available (somehow) - we
> shouldn't use the session approach like we have now. Therefore looking
> at how to create a resource resolver from some factory might be help here.
Agreed, regardless of the above the standalone authenticator will
provide a ResourceResolver and not a Session as a request attribute.
Regards
Felix
Re: Creating an authentication support bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
When we're doing changes in this area, we might also look at the same
time at one of the things which is on our todo list for a long time :)
The basic question: how to get a resource resolver?
(http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/200811.mbox/%3C491727D7.4070804@gmail.com%3E)
>From a Sling perspective I guess after authentication happend, a
resource resolver for the current user is available (somehow) - we
shouldn't use the session approach like we have now. Therefore looking
at how to create a resource resolver from some factory might be help here.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 22.12.2009 22:07, Justin Edelson wrote:
> On 12/22/09 9:52 AM, Felix Meschberger wrote:
>>> I'm a tad weary of introducing a dependency on a non-standard
>>> extension of
>>> HttpService in such a critical piece of functionality. I'm curious if
>>> there's a way to perform the authentication step *without* adding a
>>> ResourceResolver as a request attribute (and thus eliminating the
>>> need to do
>>> post-request cleanup) and then push the creation of the ResourceResolver
>>> down to happen inside SlingMainServlet (or thereabouts).
>>>
>> That's what we already do today: we login from within the
>> HttpContext.handleSecurity method and (currently) place the JCR Session
>> as a request attribute -- much like the HttpService spec expects the
>> user name, authentication type and (optionally) the UserAdmin
>> Authorization object as request attributes.
>>
> Right. I was asking about not placing the JCR Session as a request
> attribute yet still using the repository to authenticate. This seems
> like the easiest past for non-Sling servlets to deal with.
Yes. If we can "fix" the lifecycle issue of cleaning up the session (or
the resource resolver or whatever) it does not hurt to put it into the
servlet context for the servlet to consume and use it.
>>> I just don't think it's reasonable to expect that if I create a
>>> Servlet and
>>> register it with HttpService directly, that I get some special Sling
>>> goodness automagically.
>>>
>> Not really. If you register a servlet you have to provide an HttpContext
>> object. If you don't provide an object, a default implementation will be
>> used.
>>
>> For Sling, we provide a special HttpContext object (actually the
>> SlingMainServlet is also the HttpContext object) implementing the
>> handleSecurity method as described.
>>
>> So, servlets registered with the default context or with their own
>> implementations do not have to do any thing. Only servlets registered
>> with an HttpContext object whose handleSecurity method uses the new
>> authentication service will have to behave ...
>>
> But it's typically something *other than* the Servlet which does this
> registration, at least in my experience (like an Activator). In other
> words, the Servlet is not necessarily aware of the semantics of the
> HttpContext with which it has been registered. Nor, I would argue,
> should it be.
That's exactly a problem ... The longer I think of it, the longer I
doubt the API solution of explicit cleanup is a good idea ...
>> But yes, I agree, that this is not nice ... Being able to inject a
>> Servlet API 2.4 request listener would make lives easier since the
>> authentication service could register as such and cleanup up terminated
>> requests. (we had a thread on servlet API listeners once [1], maybe we
>> should pick this up again and think about to build an extension for the
>> HttpService spec to dynamically register servlet API listeners ....)
>>
> +1 to a) extending Felix's ExtHttpService to include request listeners
> and b) getting ExtHttpService to be the basis for HttpService v2 (or
> whatever).
Ok, I am working on a prototype to extend the new Felix HttpService
implementation to support Servlet API listeners using the whiteboard
pattern.
So here is my updated for cleanup solution:
* The authentication bundle registers a ServletRequestListener which
cleans up the session/resourceresolver/whatever when the request
terminates.
* As a safety net for environments where ServletRequestLister
whiteboard registration is not supported is implemented using the
Object.finalize() method.
WDYT ?
Regards
Felix
>
> Justin
>
Re: Creating an authentication support bundle
Posted by Justin Edelson <ju...@gmail.com>.
On 12/22/09 9:52 AM, Felix Meschberger wrote:
>> I'm a tad weary of introducing a dependency on a non-standard extension of
>> HttpService in such a critical piece of functionality. I'm curious if
>> there's a way to perform the authentication step *without* adding a
>> ResourceResolver as a request attribute (and thus eliminating the need to do
>> post-request cleanup) and then push the creation of the ResourceResolver
>> down to happen inside SlingMainServlet (or thereabouts).
>>
> That's what we already do today: we login from within the
> HttpContext.handleSecurity method and (currently) place the JCR Session
> as a request attribute -- much like the HttpService spec expects the
> user name, authentication type and (optionally) the UserAdmin
> Authorization object as request attributes.
>
Right. I was asking about not placing the JCR Session as a request
attribute yet still using the repository to authenticate. This seems
like the easiest past for non-Sling servlets to deal with.
>> I just don't think it's reasonable to expect that if I create a Servlet and
>> register it with HttpService directly, that I get some special Sling
>> goodness automagically.
>>
> Not really. If you register a servlet you have to provide an HttpContext
> object. If you don't provide an object, a default implementation will be
> used.
>
> For Sling, we provide a special HttpContext object (actually the
> SlingMainServlet is also the HttpContext object) implementing the
> handleSecurity method as described.
>
> So, servlets registered with the default context or with their own
> implementations do not have to do any thing. Only servlets registered
> with an HttpContext object whose handleSecurity method uses the new
> authentication service will have to behave ...
>
But it's typically something *other than* the Servlet which does this
registration, at least in my experience (like an Activator). In other
words, the Servlet is not necessarily aware of the semantics of the
HttpContext with which it has been registered. Nor, I would argue,
should it be.
> But yes, I agree, that this is not nice ... Being able to inject a
> Servlet API 2.4 request listener would make lives easier since the
> authentication service could register as such and cleanup up terminated
> requests. (we had a thread on servlet API listeners once [1], maybe we
> should pick this up again and think about to build an extension for the
> HttpService spec to dynamically register servlet API listeners ....)
>
+1 to a) extending Felix's ExtHttpService to include request listeners
and b) getting ExtHttpService to be the basis for HttpService v2 (or
whatever).
Justin
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 21.12.2009 19:34, Justin Edelson wrote:
> On Fri, Dec 18, 2009 at 2:20 AM, Felix Meschberger <fm...@gmail.com>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
>>
>
> I'm a tad weary of introducing a dependency on a non-standard extension of
> HttpService in such a critical piece of functionality. I'm curious if
> there's a way to perform the authentication step *without* adding a
> ResourceResolver as a request attribute (and thus eliminating the need to do
> post-request cleanup) and then push the creation of the ResourceResolver
> down to happen inside SlingMainServlet (or thereabouts).
That's what we already do today: we login from within the
HttpContext.handleSecurity method and (currently) place the JCR Session
as a request attribute -- much like the HttpService spec expects the
user name, authentication type and (optionally) the UserAdmin
Authorization object as request attributes.
And, yes, we do this because we use the repository to verify the
credentials and to prevent duplicate logins - for performance reasons.
At the price of having to somehow logout the session at the end of the
request.
>
> This may be problematic because you'd end up logging into the repository
> twice for a Sling request.
>
> I just don't think it's reasonable to expect that if I create a Servlet and
> register it with HttpService directly, that I get some special Sling
> goodness automagically.
Not really. If you register a servlet you have to provide an HttpContext
object. If you don't provide an object, a default implementation will be
used.
For Sling, we provide a special HttpContext object (actually the
SlingMainServlet is also the HttpContext object) implementing the
handleSecurity method as described.
So, servlets registered with the default context or with their own
implementations do not have to do any thing. Only servlets registered
with an HttpContext object whose handleSecurity method uses the new
authentication service will have to behave ...
But yes, I agree, that this is not nice ... Being able to inject a
Servlet API 2.4 request listener would make lives easier since the
authentication service could register as such and cleanup up terminated
requests. (we had a thread on servlet API listeners once [1], maybe we
should pick this up again and think about to build an extension for the
HttpService spec to dynamically register servlet API listeners ....)
Regards
Felix
[1] http://markmail.org/thread/cdhzd6ol7x3qg65m
>
> Justin
>
Re: Creating an authentication support bundle
Posted by Justin Edelson <ju...@gmail.com>.
On Fri, Dec 18, 2009 at 2:20 AM, Felix Meschberger <fm...@gmail.com>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
>
I'm a tad weary of introducing a dependency on a non-standard extension of
HttpService in such a critical piece of functionality. I'm curious if
there's a way to perform the authentication step *without* adding a
ResourceResolver as a request attribute (and thus eliminating the need to do
post-request cleanup) and then push the creation of the ResourceResolver
down to happen inside SlingMainServlet (or thereabouts).
This may be problematic because you'd end up logging into the repository
twice for a Sling request.
I just don't think it's reasonable to expect that if I create a Servlet and
register it with HttpService directly, that I get some special Sling
goodness automagically.
Justin
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
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
>>>>>>
>>>
>>>
>
>
Re: Creating an authentication support bundle
Posted by Ian Boston <ie...@tfd.co.uk>.
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.)
However we should probably investigate as all the Sling unit tests are passing ok.
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
>>>>>
>>
>>
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Ian,
There was an Engine 2.0.6 release, which still contains the old
authentication API.
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.
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
>>>>
>
>
Re: Creating an authentication support bundle
Posted by Ian Boston <ie...@tfd.co.uk>.
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
>>>
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
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
>>
Re: Creating an authentication support bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
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 ?
+1 for the patch
And +1 to continue the efforts here (wrt ResourceResolverFactory etc.
I hope this will remove the dependency to jcr from the new commons auth
module :)
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
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
>
Re: Creating an authentication support bundle
Posted by Ian Boston <ie...@tfd.co.uk>.
On 18 Dec 2009, at 07: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 ?
the endRequest(..) is starting to show the exposure of a request lifecycle. I would like to see this abstracted into something like a request lifecycle listener, so that listeners can register to perform start and end request operations, such as completing transactions or clearing request caches, not just clearing authentication.
At the moment we implement the above as servlet filters, which is Ok, and so some extents arguably better as it intercepts the call stack, however it hides the purpose of the filter.
Obviously implementation would have to guarentee that the endRequest was called, regardless of all else that happened, (although perhaps it should indicate failure) eg endRequest(boolean success)
----------
On the wider question of extracting the api and loosening the bindings, I agree.
Ian
>
> Regards
> Felix
>
>
> [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/engine
> [2] http://sling.apache.org/site/authentication.html
Re: Creating an authentication support bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Correct. My intent is to guarantee backwards compatibility -- mainly for
> the exported packages, where we have implementations
> (AuthenticationHandler) and users (Authenticator) out in the wild.
>
> Maybe we could move the package to the location (o.a.s.commons.auth
> sounds good) and provide the old API for backwards compatibility.
Yes, we could for examplee use a service tracker, tracking services with
the old api, wrap them and make them available through the wrapper using
the new api.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Creating an authentication support bundle
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 21.12.2009 08:47, Carsten Ziegeler wrote:
> 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.
Correct. My intent is to guarantee backwards compatibility -- mainly for
the exported packages, where we have implementations
(AuthenticationHandler) and users (Authenticator) out in the wild.
Maybe we could move the package to the location (o.a.s.commons.auth
sounds good) and provide the old API for backwards compatibility.
Regards
Felix
>
>
> Regards
> Carsten
>
Re: Creating an authentication support bundle
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org