You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Mike Müller (JIRA)" <ji...@apache.org> on 2010/07/09 09:15:54 UTC
[jira] Created: (SLING-1593) Decouple authentication mechanism from
JCR
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
Reporter: Mike Müller
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.
[jira] Updated: (SLING-1593) Decouple authentication mechanism from
JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Müller updated SLING-1593:
-------------------------------
Fix Version/s: Commons Auth 1.0.0
> 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
>
>
> 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.
[jira] Updated: (SLING-1593) Decouple authentication mechanism from
JCR
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-1593:
-------------------------------------
Component/s: Authentication
(was: API)
(was: JCR)
(was: Commons)
> Decouple authentication mechanism from JCR
> ------------------------------------------
>
> Key: SLING-1593
> URL: https://issues.apache.org/jira/browse/SLING-1593
> Project: Sling
> Issue Type: Improvement
> Components: Authentication
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Commons Auth 1.0.0
>
> Attachments: SLING-1593-fmeschbe.patch, sling-1593.patch, sling-1593b.patch, sling-1593c.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.
RE: [jira] Commented: (SLING-1593) Decouple authentication
mechanism from JCR
Posted by Mike Müller <mi...@mysign.ch>.
> I must be missing something here. Is the use case for this
> non-JCR ResourceResolverFactory implementations? Because for
> a JCR-backed ResourceResolverFactory, you still need to log
> into the repository with credentials. In the case of an
> external data source, this means writing a LoginModulePlugin, no?
Yes, the use case is exactly what you mentioned: It only makes
sense in conjunction with a non-JCR-backed ResourceResolverFactory
implementation. That's why this only makes sense with SLING-1262
in the release.
best regards
mike
Re: [jira] Commented: (SLING-1593) Decouple authentication mechanism from JCR
Posted by Justin Edelson <ju...@gmail.com>.
I must be missing something here. Is the use case for this non-JCR ResourceResolverFactory implementations? Because for a JCR-backed ResourceResolverFactory, you still need to log into the repository with credentials. In the case of an external data source, this means writing a LoginModulePlugin, no?
On Jul 9, 2010, at 8:37 AM, Mike Müller (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886707#action_12886707 ]
>
> Mike Müller commented on SLING-1593:
> ------------------------------------
>
> I try to be more clear:
> The new CredentialValidator interface makes it possible to validate the credentials (extracted by one of the AuthenticationHandler implementations) against any data respository. By now this is a SlingAuthenticator built-in task. So on one hand you can argue that a Sling applications just can make it's own Authenticator implementation - which is true - and therefore Sling is already decoupled from the JCR. But on the other hand, if the goal is only to validate the credentials against another data respoitory the CredentialValidator interface is much more advantageous. Probably the CredentialValidator interface should be placed in the commons.auth.spi package to retain the API as clean as possible. So what the proposal really is about, is to let an application use a SPI to validate the credentials.
> And also, as Ian mentioned, there's no need to add a LoginModulePlugin anymore.
> It is also clear that this change only makes sense in conjunction with SLING-1262.
>
>> 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
>> Reporter: Mike Müller
>>
>> 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.
>
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886707#action_12886707 ]
Mike Müller commented on SLING-1593:
------------------------------------
I try to be more clear:
The new CredentialValidator interface makes it possible to validate the credentials (extracted by one of the AuthenticationHandler implementations) against any data respository. By now this is a SlingAuthenticator built-in task. So on one hand you can argue that a Sling applications just can make it's own Authenticator implementation - which is true - and therefore Sling is already decoupled from the JCR. But on the other hand, if the goal is only to validate the credentials against another data respoitory the CredentialValidator interface is much more advantageous. Probably the CredentialValidator interface should be placed in the commons.auth.spi package to retain the API as clean as possible. So what the proposal really is about, is to let an application use a SPI to validate the credentials.
And also, as Ian mentioned, there's no need to add a LoginModulePlugin anymore.
It is also clear that this change only makes sense in conjunction with SLING-1262.
> 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
> Reporter: Mike Müller
>
> 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.
[jira] Closed: (SLING-1593) Decouple authentication mechanism from
JCR
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed SLING-1593.
------------------------------------
Close after release
> Decouple authentication mechanism from JCR
> ------------------------------------------
>
> Key: SLING-1593
> URL: https://issues.apache.org/jira/browse/SLING-1593
> Project: Sling
> Issue Type: Improvement
> Components: Authentication
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Auth Core 1.0.0
>
> Attachments: SLING-1593-fmeschbe.patch, SLING-1593-postprocess-mykee.patch, sling-1593.patch, SLING-1593b-postprocess-mykee.patch, sling-1593b.patch, sling-1593c.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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898669#action_12898669 ]
Felix Meschberger commented on SLING-1593:
------------------------------------------
Thinking about it, here is a compromise:
We have the CredentialsValidator interface which allows services to validate/modify the credentials before hitting the ResourceResolverFactory.
The JcrResourceResolverFactoryImpl does not implement the interface, though, and operates as now: logging in if required etc.
> 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.
[jira] Updated: (SLING-1593) Decouple authentication mechanism from
JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Müller updated SLING-1593:
-------------------------------
Attachment: sling-1593c.patch
Okay, that sounds good to me. In this case we don't need to change JcrResourceResolverFactoryImpl.
I changed the patch as discussed.
AuthenticationFeedbackHandler#authenticationSucceeded is not called after successful CredentialsValidator#validate, it is called (as before) after successful getting the ResourceResolver from the ResourceResolverFactory. I think that's correct because ResourceResolverFactory can throw a LoginException as well.
AuthenticationFeedbackHandler#authenticationFailed is called after CredentialsValidator#validate if a LoginException is thrown.
Can you have another look at the patch before I commit?
> 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, sling-1593c.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.
[jira] Resolved: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Müller resolved SLING-1593.
--------------------------------
Resolution: Fixed
> Decouple authentication mechanism from JCR
> ------------------------------------------
>
> Key: SLING-1593
> URL: https://issues.apache.org/jira/browse/SLING-1593
> Project: Sling
> Issue Type: Improvement
> Components: Authentication
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Auth Core 1.0.0
>
> Attachments: SLING-1593-fmeschbe.patch, SLING-1593-postprocess-mykee.patch, sling-1593.patch, SLING-1593b-postprocess-mykee.patch, sling-1593b.patch, sling-1593c.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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886658#action_12886658 ]
Ian Boston commented on SLING-1593:
-----------------------------------
IIUC this removes the need to add a LoginModulePlugin with each new form of external authentication since the authentication is provided by the Credentials.validate interface.
Although this wil work, I am not certain how it will impact other areas which have some fundamental bindings.
1. If you want to talk about the user in any ACL's the principal must be resolvable from userID <=> Principal since thats the way the AccessContronProvider works both during resolution and when modifying an ACE.
2. If the user is going to take part in any Group membership, then they have to be a JCR User managed by the Jackrabbit UserManager since membership is defined as jcr references and bound to UserImpl and GroupImpl.
So even if we do remove the AuthN to JCR Binding for Slng, if JCR in the form of Jackrabbit is present the binding is still there if the user is going to do anything related to AuthZ.
Having said that, the change looks like a step in the right direction.
> 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
> Reporter: Mike Müller
>
> 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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898728#action_12898728 ]
Felix Meschberger commented on SLING-1593:
------------------------------------------
Thanks. I will look at it tomorrow in the morning.
> 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, sling-1593c.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.
[jira] Updated: (SLING-1593) Decouple authentication mechanism from
JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Müller updated SLING-1593:
-------------------------------
Component/s: JCR
> 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
> Attachments: sling-1593.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.
[jira] Updated: (SLING-1593) Decouple authentication mechanism from
JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Müller updated SLING-1593:
-------------------------------
Attachment: sling-1593.patch
First patch to be verified
> 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
> Reporter: Mike Müller
> Assignee: Mike Müller
> Attachments: sling-1593.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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898673#action_12898673 ]
Mike Müller commented on SLING-1593:
------------------------------------
If I get you right, you mean that it's optional to implement the interface. If a service implements it and throws a LoginException the ResourceResolverFactory is not called. Did I get you right?
But why you like to choose not to implement the interface in the case of the JcrResourceResolverFactoryImpl?
One use case is to have a custom CredentialsValidator which validates the user against an external API and creates an AuthenticationInfo with a complementary user from the JCR. This could be done also with a custom LoginModulePlugin, but the goal is to be independent from jackrabbit internals. The same could be reached by implementing AuthenticationHandler#extractCredentials in a way to return the desired credentials but this would be rather a hack.
> 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.
[jira] Issue Comment Edited: (SLING-1593) Decouple authentication
mechanism from JCR
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898134#action_12898134 ]
Felix Meschberger edited comment on SLING-1593 at 8/13/10 4:51 AM:
-------------------------------------------------------------------
Now that the Sling Authenticator is using the ResourceResolverFactory to create a ResourceResolver using the extracted credentials (or AuthenticationInfo) I would prefer to no apply this patch.
If we want to add more functionality to the validation of credentials, I think we need a different ResourceResolverFactory implementing this.
Now, currently the ResourceResolverFactory is implemented by the jcr/resource bundle, which contains both the ResourceResovlerFactory implementation as well as the JcrResourceProvider. To solve this we should probably separate the ResourceResolverFactory and ResourceResolver implementations into a separate bundle and just keep the JcrResourceProvider in the jcr/resource bundle.
As it is described in https://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
Having said this, I would say https://cwiki.apache.org/SLING/user-authentication.html has been superceded with the ResourceResolverFactory interface in the Sling API (as a partial implementation of add-resourceresolverfactory-service-interface.html)
was (Author: fmeschbe):
Now that the Sling Authenticator is using the ResourceResolverFactory to create a ResourceResolver using the extracted credentials (or AuthenticationInfo) I would prefer to no apply this patch.
If we want to add more functionality to the validation of credentials, I think we need a different ResourceResolverFactory implementing this.
Now, currently the ResourceResolverFactory is implemented by the jcr/resource bundle, which contains both the ResourceResovlerFactory implementation as well as the JcrResourceProvider. To solve this we should probably separate the ResourceResolverFactory and ResourceResolver implementations into a separate bundle and just keep the JcrResourceProvider in the jcr/resource bundle.
As it is described in https://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
> 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
>
>
> 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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898282#action_12898282 ]
Mike Müller commented on SLING-1593:
------------------------------------
I'm not very happy that the validation of credentials should be done in the ResourceResolverFactory. The ResourceResolverFactory should stick to what it's name makes us believe it is doing: create a ResourceResolver (Single Responsibility Principle). Furthermore I can't see any disadvantages in applying the CredentialsValidator here as long as the interface is in the spi package and not part of the Sling API.
In this patch there's also the change to the JcrSessionCollector which collects old JCR sessions (with the help of the SlingRequestListener) to logout them if needed. I think this is a much cleaner approach than 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
>
>
> 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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898134#action_12898134 ]
Felix Meschberger commented on SLING-1593:
------------------------------------------
Now that the Sling Authenticator is using the ResourceResolverFactory to create a ResourceResolver using the extracted credentials (or AuthenticationInfo) I would prefer to no apply this patch.
If we want to add more functionality to the validation of credentials, I think we need a different ResourceResolverFactory implementing this.
Now, currently the ResourceResolverFactory is implemented by the jcr/resource bundle, which contains both the ResourceResovlerFactory implementation as well as the JcrResourceProvider. To solve this we should probably separate the ResourceResolverFactory and ResourceResolver implementations into a separate bundle and just keep the JcrResourceProvider in the jcr/resource bundle.
As it is described in https://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
> 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
>
>
> 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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900202#action_12900202 ]
Felix Meschberger commented on SLING-1593:
------------------------------------------
This last patch looks good to me. Thanks.
One minor note: I would add SlingException with a @throws tag to JavaDoc (may the tag is just missing ?) and remove it from the throws declaration (Java code style says to only list checked Exceptions in the throws declaration).
> Decouple authentication mechanism from JCR
> ------------------------------------------
>
> Key: SLING-1593
> URL: https://issues.apache.org/jira/browse/SLING-1593
> Project: Sling
> Issue Type: Improvement
> Components: Authentication
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Auth Core 1.0.0
>
> Attachments: SLING-1593-fmeschbe.patch, SLING-1593-postprocess-mykee.patch, sling-1593.patch, SLING-1593b-postprocess-mykee.patch, sling-1593b.patch, sling-1593c.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.
[jira] Updated: (SLING-1593) Decouple authentication mechanism from
JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Müller updated SLING-1593:
-------------------------------
Attachment: SLING-1593b-postprocess-mykee.patch
New patch as discussed on the maling list [1]
[1] http://markmail.org/thread/o37eenrnb3skkx5k
> Decouple authentication mechanism from JCR
> ------------------------------------------
>
> Key: SLING-1593
> URL: https://issues.apache.org/jira/browse/SLING-1593
> Project: Sling
> Issue Type: Improvement
> Components: Authentication
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Auth Core 1.0.0
>
> Attachments: SLING-1593-fmeschbe.patch, SLING-1593-postprocess-mykee.patch, sling-1593.patch, SLING-1593b-postprocess-mykee.patch, sling-1593b.patch, sling-1593c.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.
[jira] Updated: (SLING-1593) Decouple authentication mechanism from
JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Müller updated SLING-1593:
-------------------------------
Attachment: SLING-1593-postprocess-mykee.patch
As discussed on the mailing list we abandon the idea of the CredentialsValdiator in favour of an extension to the existing AuthenticationInfoPostProcessor.
I applied a patch.
Unfortunately the exception has to be caught in handleSecurity, so we're not sure if the exception really comes from the post processing of AuthenticationInfo. Maybe we should at least check if a status code is set in the response and set it if missing?
> Decouple authentication mechanism from JCR
> ------------------------------------------
>
> Key: SLING-1593
> URL: https://issues.apache.org/jira/browse/SLING-1593
> Project: Sling
> Issue Type: Improvement
> Components: Authentication
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Auth Core 1.0.0
>
> Attachments: SLING-1593-fmeschbe.patch, SLING-1593-postprocess-mykee.patch, sling-1593.patch, sling-1593b.patch, sling-1593c.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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889082#action_12889082 ]
Mike Müller commented on SLING-1593:
------------------------------------
Please have a look at the patch.
There are several questions open to this issue:
* DefaultAuthenticationFeedbackHandler.handleRedirect is called after CredentialValidator#validate, but impersonation is now done after validation before getting the resource resolver. Before this was done after getting the resource resolver because validation and getting the resource resolver was one step. I'm not sure if this could lead to any compatibility issues?
* Is the old mechanism to close the JCR sessions still needed? JcrSessionCollector implements the SlingRequestListener interface and collects all JCR sessions after getting EVENT_DESTROY.
* Should we call CredentialValidator#validate even if we use an anonymous user?
> 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
> Attachments: sling-1593.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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Justin Edelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886693#action_12886693 ]
Justin Edelson commented on SLING-1593:
---------------------------------------
To be clear, auth is already decoupled from JCR from an API standpoint. It is coupled to ResourceResolverFactory.
> 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
> Reporter: Mike Müller
>
> 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.
[jira] Assigned: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Müller reassigned SLING-1593:
----------------------------------
Assignee: Mike Müller
> 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
> Reporter: Mike Müller
> Assignee: Mike Müller
>
> 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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900237#action_12900237 ]
Mike Müller commented on SLING-1593:
------------------------------------
Inserted the @throws tag, removed the throws declaration.
commited in r987110
> Decouple authentication mechanism from JCR
> ------------------------------------------
>
> Key: SLING-1593
> URL: https://issues.apache.org/jira/browse/SLING-1593
> Project: Sling
> Issue Type: Improvement
> Components: Authentication
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Auth Core 1.0.0
>
> Attachments: SLING-1593-fmeschbe.patch, SLING-1593-postprocess-mykee.patch, sling-1593.patch, SLING-1593b-postprocess-mykee.patch, sling-1593b.patch, sling-1593c.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.
[jira] Updated: (SLING-1593) Decouple authentication mechanism from
JCR
Posted by "Mike Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Müller updated SLING-1593:
-------------------------------
Attachment: sling-1593b.patch
I modified the patch to match the recent commited changes in the code base to make it easier to verify the patch.
> 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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Justin Edelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886692#action_12886692 ]
Justin Edelson commented on SLING-1593:
---------------------------------------
Ian - I don't think that's the case. All this would do is add a new interface. In the default case (using a JCR repository), that interface would still be implemented by calling respository.login().
> 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
> Reporter: Mike Müller
>
> 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.
[jira] Commented: (SLING-1593) Decouple authentication mechanism
from JCR
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (SLING-1593) Decouple authentication mechanism from
JCR
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-1593:
-------------------------------------
Attachment: SLING-1593-fmeschbe.patch
Modified patch:
-- Adapted to refactored auth/core bundle
-- Refactored service maintenance to leverage Declarative Services and to support service ranking
-- Integrated credential validation call with getResolver method simplifying exception handling
Before applying, please wait for discussion regarding credential validator vs. credential postprocessing [1]. Thanks.
[1] http://markmail.org/message/o37eenrnb3skkx5k
> Decouple authentication mechanism from JCR
> ------------------------------------------
>
> Key: SLING-1593
> URL: https://issues.apache.org/jira/browse/SLING-1593
> Project: Sling
> Issue Type: Improvement
> Components: Authentication
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Commons Auth 1.0.0
>
> Attachments: SLING-1593-fmeschbe.patch, sling-1593.patch, sling-1593b.patch, sling-1593c.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.