Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
Auth Core 1.0.6
-
None
Description
If Sling Authentication is configured to force authentication (thus anonymous access is not allowed), Sling calls the AuthenticationHandler.requestCredentials method on all authentication handlers applicable to the request path. This works perfectly and as intended and designed for browser clients.
For non-browser clients such as for example WebDAV clients or Apache Http Client based applications, the fully Sling authentication mechanism by for example providing a login form does not work or makes no sense. For these situations we should implement functionality in the Sling Authenticator to force authentication.
There are multiple options which are not all exclusive of each other:
(1) each AuthenticationHandler is responsible itself for deciding whether to handle non-browser requests or not.
(2) an AuthenticationHandler can register a service registration property indicating support or non-support for non-browser requests.
(3) add a utility method for AuthenticationHandlers to check whether a request should be considered a browser or non-browser request.
(4) Change the behavior of the built-in HTTP Basic Authentication handler: Currently we strictly follow configuration: If anonymous access is forbidden and the built-in HTTP Basic Authentication handler is disables or enabled for preemptive action, it may be that the Sling Authenticator replies 403/FORBIDDEN for a request for which no other authentication handler assumed responsibility. The change would be to ignore the HTTP Basic Authentication handler configuration and force it enabled if anonymous access is not allowed.
(1) is how it is designed today. (2) is an extension and the default for this property (if absent) would be to assume (1), i.e. the AuthenticationHandler decides. This extension would allow to off-load the decision to the Sling Authentication mechanism. For example the Sling Login Selector, Form, and OpenID selector handlers are candidates for setting such a property. (3) would have to be done to support (2) anyway, so it could just as well be a side-effect of it. Number (4) provides a fallback for situations where authentication is required (due to not allowing anonymous access) without just sending back 403/FORBIDDEN.
Thinking about this options, I think I am going to implement the following:
(a) Add a new Util class to the o.a.s.auth.core exported package providing a new boolean isBrowserRequest(HttpServletRequest) method. (3)
(b) increasing the export version of o.a.s.auth.core package to 1.1 (for the new class). This has no influence on backwards compatibility because the existing interface is implemented by the Auth Core bundle itself.
(c) Change the configuration behavior of the HTTP Basic Authentication Handler: force it fully enabled if anonymous access is disabled (4)
(d) Add support for a new service registration property for authentication handlers to indicate support for non-browser request authentication (2)