Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] can Higgins help me with that?

>>> Fabian Weisensee fabian@xxxxxxxxxxxxx> 3/20/07 8:56 AM >>

>And there are some other questions:
>Jim mentioned an identity store. I thought this would be called context
>provider? Where's the difference?
A Context Provider is only an implementation of a set of interfaces (prescribed by the IdAS component).  Any one Context Provider is capable of producing a number of Contexts.  Conceptually, a Context is a set of Digital Subjects.  A Context Provider produces an instance of the IContext interface. This is what allows the IdAS consumer to access the Digital Subjects in that Context.  Often, there is some backing data store which is being exposed as a Context by a Context Provider.  So the difference between an identity store and a Context Provider is that the identity store consists of identity data in some (typically non-Higgins) form (like an LDAP directory or a PeopleSoft database), and a Context Provider is capable of presenting that identity data in an abstract way.
 
>What about access policies? It would be absolutely crucial to limit
>access to authorized persons.
In terms of IdAS currently, it is the responsibility of either the backing data store, or the Context Provider itself to enforce access controls.  We have not overlaid an access control model on the existing Higgins data model.

>Jim wrote:
>> - No one has built connectors yet such that different identity readers
>> (address books, IM lists, etc.) can all read the same identity store.
>> It'd be cool if they were able to use IdAS as their interface.
>
>What prevents them from using the IdAS API? Is it the API itself or the
>missing plugins for these programs?
>As i explained above, this is exactly what i want...
We're only lacking the plugins (Context Providers) at this point.  This is where Mary was welcoming you to help us identify and build the plugins for the relevant programs :)
 
Even if you don't have time to implement Context Providers, it would be good to identify interesting identity stores and the mechanisms (APIs, protocols) by which their data is accessed.  Once this is known, it may be fairly easy to write the Context Provider (it may also be difficult if the data models are extremely different)
 
Jim
 

Back to the top