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

[Nataraj Nagaratnam <natarajn@xxxxxxxxxx>]

I understand. Actually, I am not arguing
against the requirement. 

I am talking about semantics of operation/method/API
(which i thought was the core part of these discussions), and where we
may have to draw a line between (a) API needs to support it explicitly,
vs (b) optimization of implementation behind the API allows for optimized
execution.

My point below is ... if open() is to
deal with a logical connection using a new cred (your #2 in the other note),
then .. that is what we need to define as.  Then, if "physical
connections" can be reused  for improved performance, etc..,
then the provider can allow that. But a new requester/id needs to do a
new open() per semantics.. and API user should not assume how its implemented.


Now, another thing that may be an option
.... above may be more relevant to "API" used by requestor (aka
Context), and it may be different from "SPI" wrt what ContextProvider
may need to support? API maybe implicit (open called everytime but optimization
is implicit), whereas SPI maybe explicit about this?

thanks,
-Raj

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

07/25/2006 03:50 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	Re: [higgins-dev] AuthN for an open context

True, some context providers / backing data stores may
not allow any kind of re-authN to happen. An LDAP provider is an example
of one that could allow this functionality.
 
We have use-cases which require the functionality.  The
performance hit incurred by tearing down and rebuilding the connection
would be seen as a bad thing. The notion of calling open() repeatedly with
different AuthN materials may work fine in this case though.
 
To clarify the requirement, it's like this: A (middle-tier)
service is being consumed by a number of users. As each user performs some
action, the service must (ultimately) perform an LDAP bind operation as
that user, then read that user's attributes (this should be done using
a long-lived LDAP connection). That user's identity is the only one with
permissions to read the required attributes. We want to do this with Higgins.
You're right, this may not be the most common use-case, but it one we have.
Other use-cases requiring the functionality include things like switching
between superuser and anon on the same connection.
 
Jim

>>> Nataraj Nagaratnam <natarajn@xxxxxxxxxx> 7/25/06 3:23
AM >>>

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 wo uld '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
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev