You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Felix Meschberger <fm...@adobe.com> on 2011/02/21 11:07:34 UTC
Enhancement to the TokenBasedAuthentication
Hi all,
JCR-2851 introduced token based authentication support which allows for
password-less access if only a known token is available.
On creation of the token all SimpleCredentials attributes are copied to
the token node. These attributes must be matched on subsequent requests
with attributes from the TokenCredentials object supplied.
I propose to extend the attribute support as follows:
* Attributes are either optional or mandatory. Optional attributes
present in the SimpleCredentials object are just stored in the
token node but are not matched on subsequent requests. Mandatory
attributes must be existing as secondary validation mechanisms
in subsequent requests.
* When creating the Session from the SimpleCredentials (on first
access creating the token) only the optional attributes (plus the
token value of course) are copied to the Session attributes. The
mandatory attributes are not copied.
* When creating the Session from the TokenCredentials (on subsequent
access validating the supplied token and mandatory attributes) the
optional attributes stored in the token node are copied to the
Session attributes while (again) the mandatory attributes are not
copied.
This allows for preventing to leak mandatory attributes into the Session
but also allows for using the token node as a temporary store for
informational attributes.
WDYT ?
Regards
Felix
Re: Enhancement to the TokenBasedAuthentication
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 22.02.2011, 11:32 +0100 schrieb Angela Schreiber:
> >> * When creating the Session from the SimpleCredentials [...]
> >> * When creating the Session from the TokenCredentials [...]
>
> btw. the same applies for the token itself, which i never liked anyway.
> it should only obtained that from the credentials [quick investigation
> showed that this works for you and you don't need to rely on the
> session attributes... let me know if in case we are proven wrong here
> and you still need it...]
I completely agree. And looking at our use case it looks like it really
works. Thanks.
Regards
Felix
Re: Enhancement to the TokenBasedAuthentication
Posted by Angela Schreiber <an...@adobe.com>.
>> * When creating the Session from the SimpleCredentials [...]
>> * When creating the Session from the TokenCredentials [...]
btw. the same applies for the token itself, which i never liked anyway.
it should only obtained that from the credentials [quick investigation
showed that this works for you and you don't need to rely on the
session attributes... let me know if in case we are proven wrong here
and you still need it...]
angela
Re: Enhancement to the TokenBasedAuthentication
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 23.02.2011, 08:57 +0100 schrieb Angela Schreiber:
> hi felix
>
> > It would be nice if it would be possible to update the optional
> > properties by supplying new/changed ones in subsequent logins using
> > TokenCredentials.
>
> that should be feasible... although i am a bit concerned about
> the updating as additional write operations upon login should from
> my point of view be as limited as possible.... anyway... will give
> it a try and write some information output into the log that
> allows us to track those updates for reconsideration later on.
Cool thanks.
Regards
Felix
>
> regards
> angela
> > For example:
> >
> > TokenCredentials t = new TokenCredentials(token);
> > t.setAttribute(attr2, attr2Value);
> > Session s = repository.login(t);
> > assert(attr2Value.equals(s.getAttribute(attr2)));
> > s.logout();
> >
> > TokenCredentials t2 = new TokenCredentials(token);
> > Session s2 = repository.login(t2);
> > assert(attr2Value.equals(s2.getAttribute(attr2)));
> > s2.logout();
> >
> >
> > Regards
> > Felix
> >
> > Am Dienstag, den 22.02.2011, 10:51 +0100 schrieb Angela Schreiber:
> >> hi felix
> >>
> >>> On creation of the token all SimpleCredentials attributes are copied to
> >>> the token node. These attributes must be matched on subsequent requests
> >>> with attributes from the TokenCredentials object supplied.
> >>
> >> not quite... all attributes are stored in the node but only those
> >> marked as required attributes (having a leading '.token' will be
> >> used for validation upon a subsequent login.
> >>
> >>> * Attributes are either optional or mandatory. Optional attributes
> >>> present in the SimpleCredentials object are just stored in the
> >>> token node but are not matched on subsequent requests. Mandatory
> >>> attributes must be existing as secondary validation mechanisms
> >>> in subsequent requests.
> >>
> >> see above
> >>
> >>> * When creating the Session from the SimpleCredentials (on first
> >>> access creating the token) only the optional attributes (plus the
> >>> token value of course) are copied to the Session attributes. The
> >>> mandatory attributes are not copied.
> >>
> >> makes sense... i will add that.
> >>
> >>> * When creating the Session from the TokenCredentials (on subsequent
> >>> access validating the supplied token and mandatory attributes) the
> >>> optional attributes stored in the token node are copied to the
> >>> Session attributes while (again) the mandatory attributes are not
> >>> copied.
> >>
> >> same here.
> >>
> >>> This allows for preventing to leak mandatory attributes into the Session
> >>> but also allows for using the token node as a temporary store for
> >>> informational attributes.
> >>
> >> thanks for the review!
> >> angela
> >>
> >
> >
Re: Enhancement to the TokenBasedAuthentication
Posted by Angela Schreiber <an...@adobe.com>.
hi felix
> It would be nice if it would be possible to update the optional
> properties by supplying new/changed ones in subsequent logins using
> TokenCredentials.
that should be feasible... although i am a bit concerned about
the updating as additional write operations upon login should from
my point of view be as limited as possible.... anyway... will give
it a try and write some information output into the log that
allows us to track those updates for reconsideration later on.
regards
angela
> For example:
>
> TokenCredentials t = new TokenCredentials(token);
> t.setAttribute(attr2, attr2Value);
> Session s = repository.login(t);
> assert(attr2Value.equals(s.getAttribute(attr2)));
> s.logout();
>
> TokenCredentials t2 = new TokenCredentials(token);
> Session s2 = repository.login(t2);
> assert(attr2Value.equals(s2.getAttribute(attr2)));
> s2.logout();
>
>
> Regards
> Felix
>
> Am Dienstag, den 22.02.2011, 10:51 +0100 schrieb Angela Schreiber:
>> hi felix
>>
>>> On creation of the token all SimpleCredentials attributes are copied to
>>> the token node. These attributes must be matched on subsequent requests
>>> with attributes from the TokenCredentials object supplied.
>>
>> not quite... all attributes are stored in the node but only those
>> marked as required attributes (having a leading '.token' will be
>> used for validation upon a subsequent login.
>>
>>> * Attributes are either optional or mandatory. Optional attributes
>>> present in the SimpleCredentials object are just stored in the
>>> token node but are not matched on subsequent requests. Mandatory
>>> attributes must be existing as secondary validation mechanisms
>>> in subsequent requests.
>>
>> see above
>>
>>> * When creating the Session from the SimpleCredentials (on first
>>> access creating the token) only the optional attributes (plus the
>>> token value of course) are copied to the Session attributes. The
>>> mandatory attributes are not copied.
>>
>> makes sense... i will add that.
>>
>>> * When creating the Session from the TokenCredentials (on subsequent
>>> access validating the supplied token and mandatory attributes) the
>>> optional attributes stored in the token node are copied to the
>>> Session attributes while (again) the mandatory attributes are not
>>> copied.
>>
>> same here.
>>
>>> This allows for preventing to leak mandatory attributes into the Session
>>> but also allows for using the token node as a temporary store for
>>> informational attributes.
>>
>> thanks for the review!
>> angela
>>
>
>
Re: Enhancement to the TokenBasedAuthentication
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Thanks alot. One other use case just occurred to me today:
It would be nice if it would be possible to update the optional
properties by supplying new/changed ones in subsequent logins using
TokenCredentials.
For example:
TokenCredentials t = new TokenCredentials(token);
t.setAttribute(attr2, attr2Value);
Session s = repository.login(t);
assert(attr2Value.equals(s.getAttribute(attr2)));
s.logout();
TokenCredentials t2 = new TokenCredentials(token);
Session s2 = repository.login(t2);
assert(attr2Value.equals(s2.getAttribute(attr2)));
s2.logout();
Regards
Felix
Am Dienstag, den 22.02.2011, 10:51 +0100 schrieb Angela Schreiber:
> hi felix
>
> > On creation of the token all SimpleCredentials attributes are copied to
> > the token node. These attributes must be matched on subsequent requests
> > with attributes from the TokenCredentials object supplied.
>
> not quite... all attributes are stored in the node but only those
> marked as required attributes (having a leading '.token' will be
> used for validation upon a subsequent login.
>
> > * Attributes are either optional or mandatory. Optional attributes
> > present in the SimpleCredentials object are just stored in the
> > token node but are not matched on subsequent requests. Mandatory
> > attributes must be existing as secondary validation mechanisms
> > in subsequent requests.
>
> see above
>
> > * When creating the Session from the SimpleCredentials (on first
> > access creating the token) only the optional attributes (plus the
> > token value of course) are copied to the Session attributes. The
> > mandatory attributes are not copied.
>
> makes sense... i will add that.
>
> > * When creating the Session from the TokenCredentials (on subsequent
> > access validating the supplied token and mandatory attributes) the
> > optional attributes stored in the token node are copied to the
> > Session attributes while (again) the mandatory attributes are not
> > copied.
>
> same here.
>
> > This allows for preventing to leak mandatory attributes into the Session
> > but also allows for using the token node as a temporary store for
> > informational attributes.
>
> thanks for the review!
> angela
>
Re: Enhancement to the TokenBasedAuthentication
Posted by Angela Schreiber <an...@adobe.com>.
hi felix
> On creation of the token all SimpleCredentials attributes are copied to
> the token node. These attributes must be matched on subsequent requests
> with attributes from the TokenCredentials object supplied.
not quite... all attributes are stored in the node but only those
marked as required attributes (having a leading '.token' will be
used for validation upon a subsequent login.
> * Attributes are either optional or mandatory. Optional attributes
> present in the SimpleCredentials object are just stored in the
> token node but are not matched on subsequent requests. Mandatory
> attributes must be existing as secondary validation mechanisms
> in subsequent requests.
see above
> * When creating the Session from the SimpleCredentials (on first
> access creating the token) only the optional attributes (plus the
> token value of course) are copied to the Session attributes. The
> mandatory attributes are not copied.
makes sense... i will add that.
> * When creating the Session from the TokenCredentials (on subsequent
> access validating the supplied token and mandatory attributes) the
> optional attributes stored in the token node are copied to the
> Session attributes while (again) the mandatory attributes are not
> copied.
same here.
> This allows for preventing to leak mandatory attributes into the Session
> but also allows for using the token node as a temporary store for
> informational attributes.
thanks for the review!
angela