| 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 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
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 |