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