[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] [IdAS] Context open/close semantics
|
Considering your earlier point about multiple back-end data stores, what
does "authenticate against IdAS" mean in general? In delegate mode,
this is pretty obvious. But in passthrough mode (which your examples
seem to imply), does this mean "force an authentication to all backing
stores for a particular IContext"?
I could see a testAccess method or something to force authentication
using the identity passed in during the open call, if that seems
useful. (But I'd still want to know what "force authentication" means
with respect to a particular Context that's fronting other Contexts or
multiple data stores in different authentication domains.)
I'm not yet in favor of the whoami call. I guess I'm worried about
someone random querying a Context and getting my identity object, which
might contain private credentials. But, if we don't allow re-opening of
Contexts, and if Factory.getContexts returns ContextRefs instead of
Contexts, then I guess there's no easy way for someone random to get a
reference to "my" Context object unless I give it to them.
Other opinions?
...Greg
Jim Sermersheim wrote:
>>> 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.
------------------------------------------------------------------------
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
