[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Digital Identity and IContext open() method
|
Hi Greg,
Greg Byrd wrote:
It's not that we want users to create/use identities in the Higgins
Framework. It's more that
we want to allow other standard representations -- those typically
used to perform authentication
and authorization -- to be passed in. An example would be an X.509
certificate or a SAML token
with username and password.
Sure...but they do have to be created in process at some point...and
it's the creation that typically ends up doing the authentication and
association of credentials...in a extensible/provider-specific way. No?
In our case, it's the Context (or more specifically, the underlying
data repository) that determines the policy for accessing the data.
It's not the provider. The provider knows what to do with the data
once it's available.
For example, an LDAP ContextFactory knows how to access an LDAP
directory in order to get the attributes that it needs. But different
LDAP directories might have different authentication requirements, so
the provider would not know at implementation time what types of ID
tokens will be needed for the Contexts that it will manage.
So by 'provider' I was just referring to the extension that implements
the Namespace extension point...simply a provider for creating ID
instances of arbitrary type. I have to admit I'm still a little
confused by the current use of the term 'provider' WRT the Higgins
model. Given the recent discussions it's not at all clear to me what
the sequence of operations is for creating/using an IContext with a real
use case. Could someone point me to example and/or junit test code that
uses the API in current expected/proscribed manner?
Thanks,
Scott
