jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: Session.impersonate vs Credentials
Date Thu, 15 Mar 2007 15:52:33 GMT
hi julian,

On 3/14/07, Julian Reschke <julian.reschke@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.


> Best regards, Julian

View raw message