[
https://issues.apache.org/jira/browse/SLING-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-2280:
-------------------------------------
Attachment: SLING-2280.patch
Proposed patch introducing two new classes: AuthConstants with constants and
AuthUtil with utility methods.
PS: The intent is to consolidate a pile of constants distributed amongst
interfaces and classes in the auth/core bundle into to the AuthConstants class
and to consolidate a number of helper methods (particularly from the
AbstractAuthenticationHandler) into the AuthUtil class. With these classes we
have easier control of evolution in terms of versioning when we add constants
and methods with respect to client's compatibility.
> Add support for non-browser authentication
> ------------------------------------------
>
> Key: SLING-2280
> URL: https://issues.apache.org/jira/browse/SLING-2280
> Project: Sling
> Issue Type: New Feature
> Components: Authentication
> Affects Versions: Auth Core 1.0.6
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Attachments: SLING-2280.patch
>
>
> 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)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
