[
https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898682#action_12898682
]
Felix Meschberger commented on SLING-1593:
------------------------------------------
The operation sequence would be :
1. get credentials form the request
AuthenticationInfo info = extractCredentials(...) // using auth handlers
2. run credential validators
for each Validator v {
info = v.validate(info);
}
3. call resource resolver factory
ResourceResolver resolver = factory.getResourceResolver(info)
So, yes, the validators may throw LoginException and thus abort this processing
at step 2 without ever reaching step 3
The ResourceResovlerFactory will always have to implement some sort of
credential validation because it is a public API and may be used independently
of the authentication handler and its validator services. Thus having the
factory depend on the Validators will be breaking these use cases.
Still, I agree, that there might be use cases, where a different party is
willing to validate and preprocess the credentials during request
authentication before the credentials get into the resource resolver factory.
For this reason I would like to keep the JcrResourceResolverFactoryImpl keep
working as is:
* if a Session is in the authInfo map, use that
* else If a JCR Credentials is in the authInfo map, use that to create a
session
* else If user/password properties are set, use those to create a
SimpleCredentials to create a Session
So the (optional) Credential Validator may in fact take properties from the map
and create a session in advance (if suitable) or set different properties or
whatever. Note, however, that the ResourceResolver.close method will only log
out the underlying session if it is created by the factory. A session used by
the resource resolver taken from authInfo map will not be logged out.
Thus you still can validate the info against the external API, if you need and
have a validator for it. But still, the JcrResourceResolverFactoryImpl will
create (or use) a JCR Session as before.
> Decouple authentication mechanism from JCR
> ------------------------------------------
>
> Key: SLING-1593
> URL: https://issues.apache.org/jira/browse/SLING-1593
> Project: Sling
> Issue Type: Improvement
> Components: API, Commons, JCR
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Commons Auth 1.0.0
>
> Attachments: sling-1593.patch, sling-1593b.patch
>
>
> Felix made a good proposal how to decouple the authentication mechanism from
> JCR at [1] after the discussion at [2]. The remaining issue there was how to
> ensure JCR sessions which are placed into AuthenticationInfo be closed. To
> solve that issue we now can use the new SlingRequestListener [3].
> [1] https://cwiki.apache.org/SLING/user-authentication.html
> [2] http://markmail.org/message/aovh7lll4w6uwepv
> [3] https://issues.apache.org/jira/browse/SLING-1576
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
