[jira] Closed: (SLING-319) Streamlining authentication and access control

["Felix Meschberger (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger closed SLING-319.
-----------------------------------

    Resolution: Fixed

Everything has now been implemented, so this issue may be closed.

> Streamlining authentication and access control
> ----------------------------------------------
>
>                 Key: SLING-319
>                 URL: https://issues.apache.org/jira/browse/SLING-319
>             Project: Sling
>          Issue Type: Improvement
>          Components: Core, Resource
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: 2.0.0
>
>
> Sling handles authentication and access control using the JCR repository on which it is running:
> Authentication:
>   * The SlingAuthenticator uses one or AuthenticationHandler services to extract Credential instances from the request
>   * Next the Credential instance is used to authenticate agains the repository
>   * If there are no credentials in the request and the SlingAuthenticator is configured to allow anonymous acces, an anonymous request is assumed
> Access Control:
>    * JCR is specified to not throw AccessControlException on read acces. Rather the requested item is aassumed as if it would not be existing. To simulate access control, the JCR ResourceResolver implementation first checks for the existence with an administrative session, which is assumed to have full read-rights, and then checks read-rights using the request session.
>    * If access to the resource addressed by the request URI is denied, 401 is sent to request authentication if the request is not authenticated or 404 if the request is authenticated
>    * Any AccessControlException thrown during request processing (also read-access) results in a 404 being sent back.
> Now, this is somewhat problematic in various aspects:
>    * Authentication may be forced, when it should not be or when the user cannot authenticate anyway, because he has no knowledge
>    * The specification of JCR not to throw AccessControlException on read-access is by intent to not indicate whether an item exists (but cannot be accessed) or does not exist at all.
>    * Authentication is probably the task of the application and should not be enforced by Sling
>    * If no repository is available for authentication, the request is terminated with a 403/FORBIDDEN status
> Considering this situation, I propose to change this behaviour as follows:
> (1) The JCR ResourceResolver does not check for real item existence  and item read access any more. This makes the implementation simpler and somewhat faster, because each item is only checked once instead of once or twice and we do not need an administrative session for resource resolution. Missing read-access rights result in just not being able to find the item and thus may lead to 404/NOT FOUND.
> (2) Any AccessControlException thrown during request processing is returned as 403/FORBIDDEN. Most of the times, users may not be able to authenticate with different credentials anyway, so sending 401/UNAUTHORIZED just confuses.
> (3) Only if Sling is configured to not allow Anonymous access will a 401/UNAUTHORIZED response be sent (Anonymous access is currently allowed by default). Sending 401/UNAUTHORIZED is valid for HTTP Header authentication (BASIC, DIGEST, NTLM) only. Other authentication methods will handle authentication requests differently as implemented by the respective handler; other authentication mechanisms may use other status codes.
> (4) If a request is trying to authenticate but authentication fails, a 401/UNAUTHORIZED is sent back. Same as with (3) above, 401 is HTTP Header authentication specific, other protocols may use different status codes.
> (5) The authentication process is left to the application. Sling provides a simple Form-Based mechanism which uses XHR for HTTP authentication as a sample/default mechanism together with the HTTP Header Authenticator we have. This serves as a showcase for how to implement AuthenticationHandlers in Sling.
> (6) If the repository is not actually available to access 503/SERVICE UNAVAILABLE is sent back as is used if for some reason Sling is not ready to handle requests.
> (7) If we should ever integrate WebDAV access through the SlingMainServlet, we will have to investigated how to ensure 401 is sent  to allow the user to authenticate even if anonymous would actually be allowed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.