| Re: [higgins-dev] [IdAS] Context open/close semantics |
|
>>> Greg Byrd <gbyrd@xxxxxxxx> 8/9/06 8:47 PM >>>
>Jim Sermersheim wrote: <snip> >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. Yes, correct. I don't have a specific example which illustrates an IdAS consumer's need to know which identity it's being represented as. Maybe it needs to read the DigitalSubject corresponding to the identity used to authenticate. I assume the use cases are similar to those which caused the inclusion of the Unix whoami and RFC 4532.
>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?) Consider an application which wants to consume IdAS. This is application gathers a user's name and password. Sometimes this application simply needs to authenticate the user. If the user-supplied name/pw can be used to successfully authenticate against IdAS, then it is the policy of this application to allow that user to perform some actions. Other times, this application needs to authenticate the user, and as that user, read some attributes from that user's object.
I guess I just hit on the example requiring the whoami capability. An application uses authenticates using SASL EXTERNAL as described earlier, then needs to read the authenticated identity's DS in order to do some form-fill work.
Let me know if the example of the "application just needing to authenticate the use in order to do its own authZ" makes sense. If so, then we could move on to talking about the best way to do it. Sure we could tell the application to just perform a IContext.getSubject even though it doesn't need to read it, but that seems kludgy.
<snip> >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. As long as we come away with a way that an application can do the equivalent of: connect, authN, authN, authN... I'm happy.
|