Re: Creating an authentication support bundle
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 boole
Re: Creating an authentication support bundle
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
Re: Creating an authentication support bundle
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 Auth
Re: Creating an authentication support bundle
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
Re: Creating an authentication support bundle
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.
Re: Creating an authentication support bundle
On Tue 05 Jan 2010 01:47, Carsten Ziegeler 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
J Aaron Farr wrote: > On Sun 03 Jan 2010 11:27, Felix Meschberger 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 cziege...@apache.org
Re: Creating an authentication support bundle
On Sun 03 Jan 2010 11:27, Felix Meschberger 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
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 cziege...@apache.org
RE: Creating an authentication support bundle
> > 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
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
>>> 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
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
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 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.4070...@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
Re: Creating an authentication support bundle
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.4070...@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 credentials) if credentals are > present and getAnonymousResourceProvider(Map 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 cl
Re: Creating an authentication support bundle
> 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 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.4070...@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
RE: Creating an authentication support bundle
> 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.4070...@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 credentials) if credentals are present and getAnonymousResourceProvider(Map 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 Re
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.4070...@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 ResourceResol
Re: Creating an authentication support bundle
On Thu, Dec 31, 2009 at 14:49, Mike Müller 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.klimetsc...@day.com
RE: Creating an authentication support bundle
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.4070...@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
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.4070...@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
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.4070...@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 cziege...@apache.org
Re: Creating an authentication support bundle
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
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
Hi,
On 21.12.2009 19:34, Justin Edelson wrote:
> On Fri, Dec 18, 2009 at 2:20 AM, 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
>>
>
> 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 i
Re: Creating an authentication support bundle
On Fri, Dec 18, 2009 at 2:20 AM, 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
>
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
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 cziege...@apache.org
Re: Creating an authentication support bundle
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
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
Felix Meschberger wrote:
> Hi all,
>
> Currently Sling (the SlingMainServlet) is registered with the OSGi
> HttpService using an OSGi HttpContext whose handleSecurity method is
> implemented by means of the SlingAuthenticator class. This all is
> implemented in the Sling Engine bundle. See the code [1] and the
> documentation [2] for full details.
>
> This has a number of drawbacks:
>
> * Evolution of authentication provision and implementation
> is tied to the relatively unrelated Sling core implementation
>
> * The SlingAuthenticator class can only be used by servlets
> registered with Sling itself. Servlets registered directly
> with the OSGi HttpService have to implement the
> HttpContext.handleSecurity themselves, thus causing code
> duplication
>
> * The interaction between the SlingAuthenticator logging into
> the repository (Putting the session in a request attribute)
> and the SlingMainServlet using that session and logging it
> out after request termination is somewhat asynchronous.
>
> To remedy this situation, I propose to create a new bundle with the
> authentication stuff in the Engine bundle: The o.a.s.engine.auth and
> o.a.s.engine.impl.auth packages.
>
> This allows for re-use of the authentication mechanisms by other servlets.
>
> To enable authentication support a new Service interface is defined
> which allows to implement the handleSecurity method and which allows for
> proper cleanup at the end of the request.
>
> There are some options to consider, though, and an optimal solution
> escapes my mind right now...
>
>
> Option 1: Provide clean up API in the authentication service interface
>
> The service interface is defined as:
>
>public interface AuthenticationSupport {
> public boolean handleSecurity(
> HttpServletRequest, HttpServletResponse);
> public void endRequest(HttpServletRequest);
>}
>
> The handleSecurity method is meant to implement the
> HttpService.handleSecurity method. It is speced accordingly -- also
> requiring the request attributes to be set. Additionally, the method
> must set a ResourceResolver attribute (not a JCR session) for use by the
> client.
>
> The endRequest method must be called by the client when request
> processing has terminated. The intent is for the AuthenticationSupport
> service to cleanup -- namely logout an JCR session.
>
> The drawback of this option is, that it is assymmetric: HttpContext has
> to call handleSecurity, the registered Servlet has to call endRequest.
>
> Option 2: Implement ServletRequestListener
>
> The service interface is defined as:
>
>public interface AuthenticationSupport {
> public boolean handleSecurity(
> HttpServletRequest, HttpServletResponse);
>}
>
> The handleSecurity method is meant to implement the
> HttpService.handleSecurity method. It is speced accordingly -- also
> requiring the request attributes to be set. Additionally, the method
> must set a ResourceResolver attribute (not a JCR session) for use by the
> client.
>
> In addition the SlingAuthenticator registers itself as a
> ServletRequestListener handling the requestDestroyed method to cleanup
> any setups from the handleSecurity method, namely logging out JCR
> Session(s).
>
> The drawback of this option is, that it requires support to register a
> ServletRequestListener. This is something which is not supported by the
> HttpService spec and thus may only be supported by extended
> implementation (or any future HttpService or similar spec).
>
>
> WDYT ?
>
I think creating an own bundle makes definitly sense - as you outlined
both options (API or listener) have pros and cons; from a developer
perspective a favour the API way as it is easier to forget a
configuration of a listener than to call the api. In the end we could
provide both ways by having the api with the endRequest(...) method and
providing a listener which just calls this method.
For the package name o.a.s.engine.auth I'm not sure :) wouldn't this be
something which has common character? And maybe might be used by the
Felix web console as well? So I would favour something like
o.a.s.commons.auth.
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
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
