| Re: [higgins-dev] [IdAS] Context open/close semantics |
|
Greg, I agree, we need to state these open/close semantics. Playing devil's advocate...
Re: #1. I think we do need to add a way to determine the identity which was used to open a context. For some CP's, we will need to pass something equivalent to a set of identities to authN as. For example: An LDAP server is configured such that the only authN mechanism supported is SASL EXTERNAL. A keystore is passed to the IContext (presumably via addMetadata). The keystore contains a number of public keys. While the IContext instance establishes the TLS layer, one of those keys is used to perform mutual authN. IContext.open() is called with an Identity object which does nothing more than specify SASL EXTERNAL. Now I have an open context and I may have a use case where I need to know who authenticated. So I think we need some kind of whoami operation.
Also Re:#1: The wording implies that an authN step takes place, but doesn't actually say that. I'm not sure if that was intentional or not, but either way I see issues:
If open means authN: Assume a provider which accesses data from a number of sources. In order to authN, this provider will need to authN to all sources. This may be seen as a performance bottleneck and/or even an availability problem. For example, say the provider is configured to potentially access data from 20 or so sources. It seems natural to delay the authN step for any one source until the time at which data must be accessed, because in fact, all 20 sources may never in practice be accessed. Forcing authN may cause open to always fail, where lazy authN may never cause a failure.
If open doesn't mean authN: Then there's no straightforward way to perform an authN for an identity. Performing authN for an identity tends to be a common use case for certain types of applications we've been exposed to.
Ideally, we allow authN materials to be conveyed, and alternately authN to be invoked.
Re: #2: There are Contexts which don't require an authN step, nor have the notion of an authN or authZ identity. Must these providers require open to be called prior to calling these other apis?
Re: #3: The only thing I don't like there is that IContext now takes on a bit of the role of an IContextFactory (it instantiates a new IContext). Well ok, one other thing is that it doesn't allow the consumer to decide when the "close/open" semantics versus the "open new" semantics are followed. What if we said it always does close/open, and then we add a clone(). If the consumer wants "open new" semantics they call clone() and then open() on the result of the clone. Or not add clone and just make them get a new context from the factory. The factory can be smart enough to re-use whatever is re-usable.
>>> Greg Byrd <gbyrd@xxxxxxxx> 8/9/06 2:22 PM >>> Based on previous discussions, we need to clarify what it means to open and close a Context. Here's a whack at it. (1) An open Context represents a binding between a client (specified by the identity in the open() call) and the data published by the Context. There is no API for determining the identity of the client that opened a Context. (2) The following Context methods require a Context to be open: getSubject, getSubjects, createSubject, removeSubject, verifySubjectAttributes, updateSubject, exportData, importData. Calls to these methods on a non-open Context will result in a IdASContextNotOpenException. An implementation may choose to verify that the calling entity is authorized (e.g., by using JAAS getSubject on the executing thread). (3) I propose that open return an IContext, rather than void. If a Context is not open, then open may return that same Context object. If the Context is already open, a new IContext may be returned that represents this new association between another client and the data. Alternatively, an implementation may choose to return the same object if multiple bindings are not supported. (This effectively performs a close, then an open on the same object.) (4) The close operation returns the Context instance to an unopened state, as if the Context were newly-created. _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |