[
https://issues.apache.org/jira/browse/SLING-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-319:
------------------------------------
Component/s: (was: JCR Resource)
> Streamlining authentication and access control
> ----------------------------------------------
>
> Key: SLING-319
> URL: https://issues.apache.org/jira/browse/SLING-319
> Project: Sling
> Issue Type: Improvement
> Components: Engine
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 3
>
>
> 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.
