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 <[email protected]> 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
