Common Identity Architecture
From Bandit-project.org
Identity Store Abstractions
The Common Identity model or framework provides an abstract data model and access interfaces for disparate identity stores.
Contents |
Model
Within the components provided by Open Identity Systems there is a need to construct, compare, query, and authenticate digital identities. Because those identities do not share common naming, access protocols or data models there exists a requirement to consume some type of abstraction which can attempt to deal with the rich identity diversity that exists.
While this might be perceived as an opportunity to write a new framework, evaluation of existing abstractions reveals that there are several which provide sufficient functionality to serve as a starting point.
The Higgins project provides "a framework that will enable users and enterprises to integrate identity, profile, and relationship information across multiple systems. Using context providers, existing and new systems such as directories, collaboration spaces, and communications technologies (e.g. Microsoft/IBM WS-*, LDAP, email, IM, etc.) can be plugged into the Higgins framework. Applications written to the Higgins API can virtually integrate the identity, profile, and relationship information across these heterogeneous systems. A design goal is that Higgins be useful in the development of applications accessed through browsers, rich clients, and web services. Our intent is to define the Higgins framework in terms of service descriptions, messages and port types consistent with an SOA model and to develop a Java binding and implementation as an initial reference."
The image below shows how the Higgins project is considering interacting with identity repositories, the orange shaded figures are part of the EPL Higgins framework, and the blue boxes are provided as plugins from individual contributors. The context providers licensing will be determined by the contributors.
The notion of a Higgins context provider and Bandit's Common Identity are completely compatible, in the future Bandit will support joining with IDAS compliant Context Providers.
<TODO: Update this to reflect current reality>
The Bandit Common Identity contains a number of smaller functional components. The image below shows how they might fit into a Higgins context provider. The orange shaded figures are part of the Higgins framework, and the blue box is Bandit Common Identity, packaged as a Higgins Context Provider. The pale yellow boxes are pieces provided as part of the Bandit architecture, and the darker blue boxes below the Identity Store Connectors could be provided by anyone.
Component Descriptions
The following descriptions characterize the components of the Bandit Common Identity as shown above, and illustrate what will be required to create a Higgins Context provider.
Many of the components and methods described below will not be part of the initial implementation. It is anticipated we will implement only sufficient for our needs, expect sparse support for query joining, complex queries, transformation, mapping, schema projection, scripting, transactions, caching, authorization, and updating.
- Identity Store Interface : This is the main interface for authorization and role calculation, and permits those components to interact with all identities in a common manner. It consists of a JNDI service provider driven by configuration to do any mapping, transformation, and joining required while interacting with the connector JNDI providers which in turn actually communicate with the individual identity stores.
- Identity Store Connectors : Using information configured on the realm we will create JNDI contexts and call functions from the identity store connectors which in turn will use their respective SDKs to perform the requested action against the physical data store.
Sample Request Flow
Assuming an already authenticated Identity exists and the client is attempting to retrieve the roles associated with the authenticated Identity
- The role engine uses a Common Identity context to request a read of the roles key on the authenticated identity, passing any required environment variables.
- The Identity Store Service provider finds the read action specific policy and determines what actions will be taken. Generally this will involve locacting realms and either chaining to a single realm or joining the results from multiple realms.
- For each realm
- Based on the realm definition schema perform any input mappings on the data.
- Based on the realm definition perform any input mappings on the names.
- Decompose the request and determine based on the configured realm schema how each of the attributes or keys in the request should be handled, some may pass through directly others may be virtual, requiring execution of policy or scripting.
- Contact realm using Identity Store Connector - this may be multiple requests depending on the nature of the keys requested.
- Join any virtual keys/data with the real data if required.
- Based on the realm definition perform any output mappings on the names.
- Based on the realm definition schema perform any output mappings on the data.
- Join objects, eliminating duplicates if requested.
Data Definition
Reusing existing flexible components to implement the protocols and access of the identity stores will require a great deal of configuration. That configuration will be include static configuration, administrator defined policy and scripting. Using an evolutionary approach we plan to define only what is required for now extend or replace the definitions as consumers require
Functional Specification
See the Higgins IdAS Page for IdAS related information.
<TODO: link to specific provider doc here>
