Hi,
On 14.03.2010 07:41, Mike Müller wrote:
>>> while working on the ResourceResolverFactory I noticed some
>> problems.
>>> We plan to let the SlingAuthenticator directly use the
>>> ResourceResolverFactory to authenticate. This removes all
>> dependencies
>>> to JCR from the authentication and gives us much more flexibility.
>>>
>>> However, currently the constants for things like user,
>>> password etc are
>>> defined in the AuthenticationInfo. In fact, these are constants that
>>> should be defined by the ResourceResovlerFactory because this is the
>>> service that is used for authentication.
>>>
>>> I briefly discussed this with Felix and we both came to the
>> conclusion
>>> that in fact the commons auth is not really commons :) It is more an
>>> auth api for Sling.
>>>
>>> Therefore it seems to make sense to move the api from commons
>>> auth into
>>> the Sling API. So we have one single API to deal with. The
>>> implementation of the auth would stay in a separate bundle (together
>>> with the compatibility stuff for the older engine auth).
>>>
>>> Before discussing the details like which packages to use
>> etc. what do
>>> you think in general about this?
>>>
>>> Carsten
>>
>>
>> +1 to move the commons auth into the Sling API in general.
>> But I would like to decouple the ResourceResolverFactory
>> completly from
>> Authentication. It seems that this coupling only exists because of
>> the circumstances of the JCR (to return a JcrResourceResolver the
>> ResourceResolverFactory needs to login into the JCR). From a more
>> abstract view Authentication has not certainly to be coupled with
>> the Factory which returns the ResourceResolver. I know there's the
>> problem with performance (depending on the implementation maybe
>> two logins and therefore two JCR sessions), but I think it would
>> be worth to stay two steps back and discuss the new Authentication and
>> the new ResourceResovlerFactory once again. We do have now the
>> possibility to do that, because both concepts are new and not
>> released.
>>
>> best regards
>> mike
>
> As you probably know, this is not the first time I come up with
> this [1]. At the risk of being a little bit cumbersome, I really
> think we could design a clean API where authentication and
> the getting of a resource resolver is completely decoupled without
> loosing performance. The API doesn't tell us how we have to
> implement it (but is has to give us the chance to implement it
> without loosing performance ;-). I would propose to first define
> how a "brave world" API would look like and go from there.
> WDYT?
>
> [1] http://markmail.org/message/bwgrbhwlsi5ekenn
My biggest concern with this was (and still is) loss of performance if
logging two login's would be required for each request. We can "fix"
this issue, if we defined an API to act as an intermediary, e.g.
something like:
public interface CredentialValidator {
public AuthenticationInfo validate(
AuthenticationInfo credentials)
throws LoginException;
}
This service interface would be implemented by a JCR based
implementation using Repository.login to valid and would be used by the
SlingAuthenitator to validate the credentials.
The AuthenticationInfo returned might contain the session acquired
during validation and be set as a request attribute. That request
attribute would be picked up by the SlingMainServlet to hand over to the
ResourceResolverFactory.getResourceResolver(Map) method.
One issue remains: disposal of the Session placed into the
AuthenticationInfo object by the validate method. But this can be
solved, I am sure ...
More details (aka words) at [1]
Regards
Felix
[1] http://cwiki.apache.org/SLING/user-authentication.html
>
> best regards
> mike
>
>
