Session.impersonate vs Credentials

[Julian Reschke <ju...@gmx.de>]

Hi,

I noticed that the Session implementations both in Jackrabbit and 
JCR2SPI require that the Credentials object passed into the 
impersonate() method actually is a SimpleCredentials object. The purpose 
seems to be that the "impersonating session" can be remembered in an 
attribute on the credentials.

JSR-170 however doesn't mention anything about that.

So...:

- is this just plainly unimportant? (such as in "nobody uses impersonate 
anyway, it's simple enough to do a regular login)

- is this a TODO? (the code in JCR2SPI's SessionImpl seems to indicate 
that...) - if it is, should we define an extension to SimpleCredentials 
that can hold the required information, so that we don't rely on a 
specific impl class?


Best regards, Julian

Re: Session.impersonate vs Credentials

[Angela Schreiber <an...@day.com>]

Stefan Guggisberg wrote:
> On 3/14/07, Julian Reschke <ju...@gmx.de> wrote:

>> - is this a TODO? (the code in JCR2SPI's SessionImpl seems to indicate
>> that...) - if it is, should we define an extension to SimpleCredentials
>> that can hold the required information, so that we don't rely on a
>> specific impl class?

> since we've left the specifics of the 'impersonate' mechanism up to the
> implementation we don't know what is required to identify an impersonating
> session. an extension to SimpleCredentials would therefore not help since
> it implies username/password credentials.

based on this 'impersonating' has simply be added to the SPI
(RepositoryService), since the jcr2spi is obviously not able to
know how a particular implementation handles the impersonation.

bref, shouldn't be an issue any more

regards
angela

Re: Session.impersonate vs Credentials

[Stefan Guggisberg <st...@gmail.com>]

hi julian,

On 3/14/07, Julian Reschke <ju...@gmx.de> wrote:
> Hi,
>
> I noticed that the Session implementations both in Jackrabbit and
> JCR2SPI require that the Credentials object passed into the
> impersonate() method actually is a SimpleCredentials object. The purpose
> seems to be that the "impersonating session" can be remembered in an
> attribute on the credentials.

wrt the jackrabbit implementation:

yes, that's correct.

>
> JSR-170 however doesn't mention anything about that.

correct too. the specifics of the impersonating mechanism was considered
an implementation detail.

>
> So...:
>
> - is this just plainly unimportant? (such as in "nobody uses impersonate
> anyway, it's simple enough to do a regular login)

no, that's certainly not the intention. the reference implementation (and
therefore jackrabbit) had chosen a quite simple approach to implement
this feature: the impersonator (i.e. the authenticated Subject) is stored
in a Credentials attribute. Authorizing an 'impersonate' request is delegated
to the pluggable LoginModule. here's the relevant piece of code in
SimpleLoginModule (a dummy implementation):

    Object attr = sc.getAttribute(SecurityConstants.IMPERSONATOR_ATTRIBUTE);
    if (attr != null && attr instanceof Subject) {
            // Subject impersonator = (Subject) attr;
            // @todo check privileges to 'impersonate' the user
represented by the supplied credentials
    } else {
    ...

>
> - is this a TODO? (the code in JCR2SPI's SessionImpl seems to indicate
> that...) - if it is, should we define an extension to SimpleCredentials
> that can hold the required information, so that we don't rely on a
> specific impl class?

again, wrt jackrabbit/jsr-170:

since we've left the specifics of the 'impersonate' mechanism up to the
implementation we don't know what is required to identify an impersonating
session. an extension to SimpleCredentials would therefore not help since
it implies username/password credentials.

cheers
stefan

>
>
> Best regards, Julian
>