| Re: [higgins-dev] [IdAS] Context open/close semantics |
Jim Sermersheim wrote:
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.
I don't really understand the use case, probably because I'm not sure about SASL EXTERNAL. The SSL stack chooses one of the certificates in the key store to do client authentication, but you don't know which. And the identity associated with that certificate is the one that used for authorization. (Is that correct?) I'm still not sure why the client (or IdAS) needs to know which was used for authorization.
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.
I agree that lazy authentication would be a legitimate implementation. I wasn't trying to imply or force eager authentication, but I admit that I hadn't really considered the lazy approach.
_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.
I'm not convinced of the need for an explicit authentication, separate from opening and accessing Context data. Sorry to be so dense, but could you an example? If doing lazy authentication, why not wait until the data is actually needed? (In your multiple source example, the client is not aware of the multiple sources, correct? So how would it know that it's time to authenticate to source X?)
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?
I would think so, yes. Even without authentication, there still might be some operation required to establish some sort of initialization to access the data (e.g., opening a file). I would prefer all Contexts to be accessed in the same way.
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.
I agree that the either/or semantics is not a good idea. I'm comfortable with creating a new one -- so we should say that opening a Context that's already open throws an exception. I'm just not fond of the "reopening = identity change" option.
>>> 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 bythe 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 aContext. (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 thatrepresents this new association between another client and the data. Alternatively, an implementation may choose to return the same object ifmultiple 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 ------------------------------------------------------------------------ _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev