| RE: [higgins-dev] [IdAS] registered Contexts |
|
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? |