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 2010/01/02 13:46:39 UTC
Re: Creating an authentication support bundle
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 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