Re: [higgins-dev] AuthN for an open context

[Nataraj Nagaratnam <natarajn@xxxxxxxxxx>]

Answer to this depends on what we end
up defining 'open' to mean (ref to your other post).  If open would
mean that authn has taken place, and connection established (your #2 in
that mail..which I am leaning towards), then .. I am not sure if we would
or even could use a different authn cred on a given authenticated connection
and what would it mean. 

If there is a requirement to open a
context with another credential, why not use open() again and it may end
up being a different connection instance. Are you thinking about optimizing
open operation, or something else. One possible approach that may help
is to supply cred for a given connection, during that query, as optional.
 i.e., a connection is either long living session or one time request.
If it is long-living-session, then one would 'open' a context with credential
and release it later (upon end of queries, interaction,..).  for one
time request, cred is part of the operation.

btw,.. you said: one
needs to login to the back-end data store as the identity being read
I am not sure about this assumption/requirement.  I don't think this
is the case (most of the time?).


thanks
raj

"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

07/21/2006 07:32 PM

Please respond to
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	"'Higgins (Trust Framework) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
cc
Subject	[higgins-dev] AuthN for an open context

We've provided a way to authenticate when opening/creating
a context. Currently, this only happens when we open the context. There's
no provision to change the AuthN identity after it's open.
 
There may be cases where a context is used to read DigitalSubject
information and in order to read the proper information, the AuthN materials
must be that of the DigitalSubject being read.
 
In other words, one needs to login to the back-end data
store as the identity being read -- there is no super-user or analog. We
don't want to require that a context is opened/closed for each DS read
in this scenario.
 
Have we talked about a way to change AuthN materials on
an open context?
 
Jim_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev