Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of stefan.guggisberg@gmail.com
 designates 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=cnPadQqNGlvykesXkCTL/+0BrzOBcN9wk1O4V2TPqyeMFaNdoxSL7Ozda4BrK/cTMYsSZrxPgnAKNfEnxVmH09MWTY4goWbbfUESth4IJElMPCSV2b2M/Okpd3o6hefGXEMxZucWfEb/+4xW73CFi1LPcsHq+S9aV+FnsRhSn24=
Message-ID: <90a8d1c00703150852s15ec654eu43c1299d5af8a709@mail.gmail.com>
Date: Thu, 15 Mar 2007 16:52:33 +0100
From: "Stefan Guggisberg" <stefan.guggisberg@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: Session.impersonate vs Credentials
In-Reply-To: <45F80EB8.4050804@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45F80EB8.4050804@gmx.de>

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.

cheers
stefan

>
>
> Best regards, Julian
>