| Re: [higgins-dev] [IdAS] registered Contexts |
|
It's useful when the delegate-authN model is used. Assume all contexts are opened as the same user (the application's identity). Then all may be returned. In this case the application is responsible to restrict access.
It's also useful in the passthrough-authN model is used but many people are presenting anonymous identities.
I can't see where it's ever safe to return a context which has been open as a different person. That's like logging into one's workstation and allowing someone else to take over. I think the sharing of open contexts between trusted parties as being beyond the purview of IdAS.
Jim
>>> Greg Byrd <gbyrd@xxxxxxxx> 8/15/06 3:05 PM >>> My problem is with the following phrase: "the registry would not return any contextRefs for contexts not open as that user." If getting a list of Contexts is useful for discovery, then this policy is not very helpful. If I've already opened the Context, then I probably don't need to discover it. Jim Sermersheim wrote: > So for the case where a web-service/middle-tier service which is > performing passthrough authN needs to protect against the viewing of > other people's contextRefs, it seems reasonable that the API > IdASRegistry.getContexts (and whatever related APIs there are) would > require (or at least allow) an authN identity to be passed (just like > IContext.open() does). and the registry would not return any > contextRefs for contexts not open as that user. > > Ok, I just thought about that, and I don't like it. authN identities > may be complex -- too complex to compare without actually performing > an open (may entail multi-part handshakes, key stores, etc.). Maybe > the registry needs to allow for the notion of a session? > > Jim > > >>> "Mary Ruddy" <mary@xxxxxxxxxxxxxxxxx> 8/15/06 2:36 PM >>> > > Jim Sermersheim wrote: > > > > >The issue with public versus private contexts makes me realize we > likely have different deployment scenarios in mind. > > > > > >- Some use cases have Higgins deployed on a user's workstation. I > assume these use cases don't get into the privacy issues you mention > below. > > >- Some have Higgins deployed as a web-service or middle tier service. > > > - Of those using passthrough authN, I assume those applications > would never expose any context not opened by a given user. Should this > restriction be built >into the registry? Does the release of even a > ContextRef expose too much? Maybe so... > > ***Yes it depends - There will be contexts that people want to > lock down very tightly. On the other hand, some of our original use > cases were to support of very open contexts that were public > (discoverable) and had an open privacy policy - anyone could see and > add data. > > > - Of those using delegate authN, I assume those applications have > some out-of-band authZ mechanism to restrict which users are allowed > access. > > > > In terms of the "sharability of contexts" are there other scenarios > where private/public contexts become important? > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 |