SlingAuthenticator with multiple Handlers for same path prefix

[Rory Douglas <ro...@oracle.com>]

When multiple AuthenticationHandlers are registered for a given path 
prefix, the SlingAuthenticator tries each one in turn until one returns 
an AuthenticationInfo object.  There is no way to control the order in 
which the handlers are tried.

I suggest the AuthenticationHandler interface be extended to include 
additional properties for controlling the order in which authentication 
is attempted.  I've implemented this with 2 new properties, Auth 
Priority and Auth Challenge Priority.  The first one controls the order 
in which handlers are called for the authenticate() method.  The second 
controls the order for the requestAuthentication() method.

Using 2 properties allows you to register both the HTTP Auth handler and 
another (more interactive) handler simultaneously for the same set of 
paths.  The HTTP Auth handler is then assigned the highest "Auth 
Priority".  The interactive handler is assigned the highest "Auth 
Challenge Priority".  If a request is received containing BASIC Auth 
credentials (i.e. from cURL/WebDAV), it is authenticated & the 
interactive handler is not tried.  If, however, there are no BASIC auth 
credentials, the other handler is tried.  If it too can't authenticate 
the current request, the SlingAuthenticator will then attempt the 
challenge process by calling requestAuthentication().  Here now, the 
interactive handler is called first, which can then show a login form, 
redirect to an SSO provider etc.

I think this gives the behavior one would expect: cURL stills works fine 
if you provide credentials, and users accessing Sling via the browser 
get the custom login forms etc. 

Another alternative would be to register Handlers with a Path and a 
HostName.  That way interactive handlers could be enabled only on 
certain hostnames, so they wouldn't interfere with cURL or WebDAV.

Thoughts?

Regards,
Rory

Re: SlingAuthenticator with multiple Handlers for same path prefix

[Felix Meschberger <fm...@gmail.com>]

Hi Rory,

Rory Douglas schrieb:
> When multiple AuthenticationHandlers are registered for a given path
> prefix, the SlingAuthenticator tries each one in turn until one returns
> an AuthenticationInfo object.  There is no way to control the order in
> which the handlers are tried.

Yes, this is true. We deliberately did not add such a functionality yet,
in the intent to solve this problem as soon as it surfaces -- which
seems to be the case now ;-)

> 
> I suggest the AuthenticationHandler interface be extended to include
> additional properties for controlling the order in which authentication
> is attempted.  I've implemented this with 2 new properties, Auth
> Priority and Auth Challenge Priority.  The first one controls the order
> in which handlers are called for the authenticate() method.  The second
> controls the order for the requestAuthentication() method.
> 
> Using 2 properties allows you to register both the HTTP Auth handler and
> another (more interactive) handler simultaneously for the same set of
> paths.  The HTTP Auth handler is then assigned the highest "Auth
> Priority".  The interactive handler is assigned the highest "Auth
> Challenge Priority".  If a request is received containing BASIC Auth
> credentials (i.e. from cURL/WebDAV), it is authenticated & the
> interactive handler is not tried.  If, however, there are no BASIC auth
> credentials, the other handler is tried.  If it too can't authenticate
> the current request, the SlingAuthenticator will then attempt the
> challenge process by calling requestAuthentication().  Here now, the
> interactive handler is called first, which can then show a login form,
> redirect to an SSO provider etc.

This sounds reasonable to me.

There is just one glitch if the client (cURL or WebDAV) is not
preemptively sending the HTTP Basic credentials but is waiting for the
challenge... Would need to be investigated, probably. What do you think ?

> 
> I think this gives the behavior one would expect: cURL stills works fine
> if you provide credentials, and users accessing Sling via the browser
> get the custom login forms etc.
> Another alternative would be to register Handlers with a Path and a
> HostName.  That way interactive handlers could be enabled only on
> certain hostnames, so they wouldn't interfere with cURL or WebDAV.

In fact, this is an interesting proposal in its own right with respect
to the Virtual Host support we recently built into the ResourceResolver:
You might argue, that I want to have different authentication methods
for different virtual hosts.

> 
> Thoughts?

+1 ;-)

Regards
Felix

Re: SlingAuthenticator with multiple Handlers for same path prefix

[Carsten Ziegeler <cz...@apache.org>]

Currently the sling authenticator sorts handlers by path, I think we
should also enhance this and sort the handlers by the service.ranking
property which is usually used in OSGi to define an order of several
components providing the same service.


Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: SlingAuthenticator with multiple Handlers for same path prefix

[Rory Douglas <ro...@oracle.com>]

I've been using the priority ordering method locally for a while and it 
works OK, but I agree that it might not always be flexible enough to 
handle corner cases.  The more I think about it, the more I feel the 
authentication handlers should be registered with applicable virtual 
hosts (as Felix suggested earlier).  I'm not sure that multiple handlers 
for a given virtual host & path would be a very common scenario - more 
common would be the following (assuming an appropriately secured 
network/DMZ):

http://public.my.site.com -> requires some kind of SSO, OpenID etc
http://admin.my.site.com -> uses only HTTP Basic auth, for content 
updates via cURL etc, perhaps only visible to local network

It would be nice to hook into the existing Virtual Host support, by just 
registering the appropriate handlers for the mapped virtual paths (e.g 
http://public.my.site.com -> /content/public/site), but I think request 
authentication is performed only on the originally requested URL, not 
any translations/mapping internal to Sling, correct?

In that case, perhaps we could just modify the AuthenticationHandler 
PATH property handling in SlingAuthenticator to allow including the 
virtual hostname and even the protocol for matching purposes? So the 
following would apply:

Path=/                                
Applies to:  all URLs across all virtual hosts (1)

Path=//public.my.site.com/
Applies to: all URLs on the public.my.site.com host (2)

Path=//public.my.site.com/protected
Applies to: URLs starting with /protected on public.my.site.com host (3)

Path=https://public.my.site.com/protected/personalinfo/
Applies to: URLs starting with /protected/personalinfo on  
public.my.site.com host under SSL (4)

The priority ordering would work from most specific to most general, so 
above (4) would have priority over (3), (3) over (2) etc.  This could be 
implemented by changing getAuthenticationHandlers() method to return a 
Map<String, Map<String, AuthenticationHandlerInfo[]>> - the first lookup 
is by protocol, the second by hostname, the last by path.

How does that sound?

Regards,
Rory

Alexander Klimetschek wrote:
> On Sun, Feb 1, 2009 at 2:27 AM, Rory Douglas <ro...@oracle.com> wrote:
>   
>> When multiple AuthenticationHandlers are registered for a given path prefix,
>> the SlingAuthenticator tries each one in turn until one returns an
>> AuthenticationInfo object.  There is no way to control the order in which
>> the handlers are tried.
>>     
>
> A solution that is sub-optimal, but at least gives you full control
> and works with current Sling, is simply to write your custom
> authentication handler that handles all cases in the correct order.
> For example, if you want to handle OpenID and fall back to HTTP Basic
> Auth if no OpenID is available, you could subclass from the existing
> basic auth handler; in there you call/check for OpenID auth first and
> call the super implementation if no OpenID is available.
>
> This way you can also handle corner-cases where two authentication
> schemes might overlap in some way. But I would still opt for re-use of
> existing classes through simple configuration, most cases are probably
> rather simple and just require the proper order.
>
> Regards,
> Alex
>
>   

Re: SlingAuthenticator with multiple Handlers for same path prefix

[Alexander Klimetschek <ak...@day.com>]

On Sun, Feb 1, 2009 at 2:27 AM, Rory Douglas <ro...@oracle.com> wrote:
> When multiple AuthenticationHandlers are registered for a given path prefix,
> the SlingAuthenticator tries each one in turn until one returns an
> AuthenticationInfo object.  There is no way to control the order in which
> the handlers are tried.

A solution that is sub-optimal, but at least gives you full control
and works with current Sling, is simply to write your custom
authentication handler that handles all cases in the correct order.
For example, if you want to handle OpenID and fall back to HTTP Basic
Auth if no OpenID is available, you could subclass from the existing
basic auth handler; in there you call/check for OpenID auth first and
call the super implementation if no OpenID is available.

This way you can also handle corner-cases where two authentication
schemes might overlap in some way. But I would still opt for re-use of
existing classes through simple configuration, most cases are probably
rather simple and just require the proper order.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com