Project Aristotle (and the ArisID api) is about creating a high-level general purpose application programming interface that enables application developers to access, update, and use Identity information in a privacy respectful, secure, and multi-protocol capable set of application program interfaces.
ArisID uses the IGF CARML specification to allow developers to create an identity data model. This model then allows other layers of the application server container to provide services to the application in a way the fulfills the developers requirements. The model based approach to identity services is not unlike the model for database services provided in TopLink, "a powerful and flexible framework for storing Java objects in a relational database or for converting Java objects to XML documents".
This approach releases the developer from deciding which information is to be stored locally and which information is to be based on enterprise identity. The API creates flexibility by not forcing application design decisions based on a few specific protocols or service definitions. In short, it de-couples the application from infrastructure dependencies and assumptions.
Contemplating the nature of identity has been a challenge for the identity services industry for some time. In the same vein, Aristotle was one of the first philosophers to contemplate the notions of identity, going on to invent the law of identity.
Project Aristotle's objective is to create a general, open API that can be widely adopted that at the same time is able to leverage existing proven identity middleware technology from the identity services industry. By using the Aristotle Identity API, developers are freed from having to become experts in protocols such as LDAP or federated identity service protocols such as SAML, ID-WSF, OpenID, or WS-Trust. They are able to create their own identity "silo", while still enjoying the benefits of integration in standards based identity services.
Project Aristotle and IGF
Project Aristotle grew out of the Identity Governance Framework (IGF) standards the Liberty Alliance Project has published and is still working on. The objective was to demonstrate a methodology for using CARML (Client Attribute Requirements Markup Language) and WS-Policy Privacy Constraints in connection with popular identity protocols such as LDAP, SAML, WS-Trust, ID-WSF, and others.
The Identity Governance Framework is about enabling the secure and appropriate exchange of identity-related information between users and applications and service providers (both internal and external) is the basis of providing deeper and richer functionality for services oriented architecture. IGF V1.0 Specification
Sensitive identity-related data such as addresses, social security numbers, bank account numbers and employment details are increasingly the target of legal, regulatory and enterprise policy. These include,but are not limited to: the European Data Protection Initiative, Sarbanes-Oxley, and Gramm-Leach-Bliley as examples.
The Id Governance initiative assists entities managing identity data by increasing transparency and demonstrable with regards to defining what identity information applications consume and use, and what transactions are performed against the identity information used by those applications.
Introducing Declarative Identity Services
In traditional programming approaches, a developer using web services would expect to look up a service definition (WSDL) and generate client code that complies with the service definitions. In the case of LDAP, the developer would be expected to understand the protocol and know how to query the target directory server for schema and other valuable information. While this works well for specific instance or non-standard systems, it rarely occurs that applications will interact with only one web or identity service. Prior to web services, LDAP was the popular identity service protocol. It had the advantage of a standard protocol and commonly accepted standards for data definitions or schema. The combination of a standard protocol and a standard schema had promised easy integration for applications. In practice, this turned out not to be true. There were still enough data and protocol mis-matches that application developers were forced to accommodate differences between vendors and between specific enterprise deployments. An LDAP application that worked well with many different enterprises required the talent and skills of an experienced LDAP developer to handle all of the required interoperability and data variation use cases that occur in every deployment. While LDAP was relatively lightweight and simple to understand, its effective use was difficult.
The faulty assumption here was that application requirements and identity services infrastructure follow standards. And therefore interoperability is assured.
Project Aristotle assumes that there will never be a situation where all identity systems are identical or an identity system that meets the needs of every application. Even if this were true, today's requirements for privacy and consent further increase the chances that there will be increased variability of information schema from one user to the next. While developers may follow best practices and choose common standard schema for their application, we must assume that there will always be some level of mis-match between developed applications and deployed identity systems.
While the majority of deployments may in fact be incredibly simple, Project Aristotle assumes that for any given application there may be multiple valid sources of identity information that must be accessed one of many identity service protocols. Instead of assuming that all identity schema (attributes, roles, predicates) are standards based, Project Aristotle assumes that there will be at least some non-standard data that the application developer wishes to use that is particular to their application. The assumption in the API is that there will be some protocol and data mis-matches that will require some form of mapping.
Instead of applications having to adapt to many different identity repositories and services, the tables are turned. By assuming there is intelligent technology out there, the developer can assume that instead identity services will adapt to meet the needs of the application. One proven example of this is virtual directory technology. A technology that is able to map and transform existing LDAP systems to conform to the needs of specific LDAP clients.
The key differentiator in the Project Aristotle approach is to have applications using identity services declare the identity information data types the application will actually use, and most importantly declare the transactions to be performed around that information. By doing this a number of things are achieved:
- The identity API is actually simplified. Because transactions are predeclared, less information needs to be specified when invoking a particular operation.
- In a multi-layered API and network, it now becomes possible for identity services to become more intelligent. Because the services know what the application needs, in what form, and what the transactions will be, the identity service can be configured to respond exactly to an applications requirements.
- Client code may be automatically generated (e.g. Identity Beans) based on a Client Attribute Requirements Markup Language (CARML) declaration created by the developer - further freeing the developer from having to write code.
Project Aristotle is composed of several sub-projects focusing on major areas of interest.
ArisID API - A transactional API implementing CARML enabling access to identity information through multiple protocols through "Provider Stacks" which do the hard work of protocol conversion, virtualization/mapping, and routing (we expect to have implementations eventually from Higgins, Oracle, Symlabs, Novell in the near future).
ArisID Beans - ArisID Beans work by allowing the developer to use an editor to create a CARML declaration that represents properties and transactions around a particular object entity type. Once the CARML is declared, an Ant tool executes a generator (using Apache Velocity) to generate Java Bean code representing those entity objects declared in CARML. ArisID Beans is a demonstration of how using CARML declaration can both help the infrastructure layers figure out how to virtualize information for the application, and it also shows how it brings value to the developers by generating all of the java code the developer needs to manage those identity entities.
While much of this work is done elsewhere, there is significant effort underway to work with other open source projects and vendors to develop providers based on proven technology that can work with the ArisID API as an information provider.
- To be announced
- The European Identity Award for the category Best new or improved standard 2009.
- Presentation on IGF Attribute Services January 2008.
- Applying IGF as a developer. Given by Phil Hunt of Oracle at DIDW 2008.
- 0. Standard Specification - IGF 1.0
- 1. Id Governance - Identity Privacy and Access Policy MRD
- COMMENT: The key material is in section 1.4 and 1.5. The rest of the document works thru this material in much more detail with concrete scenarios.
- COMMENT: This is an informal summary of the MRD (aka "MRD-lite"). It is made up of exactly Sections 1.4 and 1.5 from the MRD with additional explanatory material.
- COMMENT: Provides a concrete example of a "Client Attribute Requirements Markup Language".
- COMMENT: Provides a concrete example of a "Attribute Authority Policy Markup Language"
- COMMENT: The focus of this work is on the relationship between browser-equipped end users and web sites. This is quite distinct from the IGF focus area. However, Section 3, Policy Syntax and Semantics has relevance to IGF and should probably be referenced going forward.
- 1. P3P Policy Attributes for LDAP, Mark Wahl
- 2. Information Accountability, Daniel J. Weitzner, Harold Abelson, Tim Berners-Lee, Joan Feigenbaum, James Hendler, and Gerald Jay Sussman, MIT-CSAIL-TR-2007-034
- SUMMARY: Argues that privacy is closely linked to accountability, and that establishing accountability mechanisms for entities that handle personal data provides an appropriate privacy model for the web.
- 3. (WS-XACML) Version 1.0 Working Draft 10, 10 August 2007
- SUMMARY: Proposes the use of WS-Policy and P3P privacy statements to model privacy constraints for web services.
- SUMMARY: The *Identity Attribute Service* (IdAS) component provides a virtualized, unified view and a common means of access to identity information from multiple heterogeneous data sources
Related Open Source Projects
- Apache Software Foundation – the IGF Project will favor components and libraries available under the Apache 2.0 license. This is to enable maximum use by the developer community without providing restrictions on use or forking. Any use of identity services is to be encouraged!
- Higgins & Bandit Projects – the IGF Project proposes to share much of the architecture established by the Higgins and Bandit Projects and will use the Higgins Identity Attribute Services code for the initial Java implementation. Because Higgins IdAS is available only under EPL this may require separate downloads of both Higgins project code and IGF Project code due to the dual-license status for this first implementation. It is our hope to simplify this arrangement as the project progresses.
All events and calls are also available on the IGF Online Calendar.
- October 23, 2007 - RSA Europe 2007 - SOL-108 - The Identity Governance Framework: Liberty Alliance's Privacy Initiative presented by John Aisien of Oracle
Note: the October 25th IGF Project call is cancelled due to the Liberty Plenary Meeting October 22-26 in Tokyo.
Conference calls are held periodically and announced on the igf-dev mailing list.
Join the mailing lists.
To contribute code, you will need to agree to the Apache 2.0 CLA and you will need a SourceForge Id. After creating your sourceforge id, please provide your background and sourceforge id via email to igfman at users.sourceforge.net to join the IGF SourceForge project.
- Frequently Asked Questions
- ArisID Architecture
- ArisID Transactional API
- ArisID Beans
- Protocol Profiles
- Mailing List
- Aristotle Project Tracker (Planning & Bugs)
- ArisID 1.1 Release Notes
- Oracle - OVD Provider for ArisID
Related External Information
- Liberty Alliance Project - IGF Strategic Initiative site
- Oracle Technology Network - IGF site
- Blogs -