hi julian,
On 3/14/07, Julian Reschke <[EMAIL PROTECTED]> 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
