[ 
https://issues.apache.org/jira/browse/SLING-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149574#comment-13149574
 ] 

Carsten Ziegeler commented on SLING-2280:
-----------------------------------------

Sounds good to me
                
> 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

        

Reply via email to