This post summarizes the white paper
'Identity Governance Framework' by Oracle.
IGF initiative was first announced in November 2006 by Oracle and in November 2007 it was submitted to Liberty Alliance.
Identity Governance Framework (IGF) helps enterprises easily determine and control how identity related information, including Personally Identifiable Information (PII), access entitlements, attributes, etc. are used, stored (in multiple sources), and propagated between their systems.
It enables organizations to define enterprise level policies to securely and confidently share sensitive personal information between applications that need such data, without having to compromise on business agility or efficiency.
In other words IGF allows to define a set of business rules around usage of identity-related data.
For example user's SSN should only be used in an application that works on behalf of the user - where in all the other cases no application should have access to that specific piece of data.
Further,IGF focuses on following attributes:
- Decouple applications from deployment infrastructure
- Include identity-related data stored inside and outside classic enterprise directory
- Access to user attributes and entitlement data
- Policy-driven to support management and governance
In other words, IGF defines a set of declarative contracts between suppliers and consumers of identity-related information based on two standards - CARML and APPML.
The Identity Governance Framework (IGF) is designed to allow:
1. Application developers to build applications that access identity-related data from a wide range of sources
2. Administrators and deployers to define, enforce, and audit policies concerning the use of identity-related data.
IGF has four components:
1. Identity attribute service - a service that supports access to many different identity sources and enforces administrative policy
2. CARML: declarative syntax using which clients may specify their attribute requirements
3. AAPML: declarative syntax which enables providers of identity-related data to express policy on the usage of information,
4. Multi-language API (Java, .NET, Perl) for reading and writing identity-related attributes.
Client Attributes Requirements Markup Language (CARML) is a specification built by the developer during the development process (much like WSDL is to a web service).
In other words CARML is targeted towards the developers who develop applications which consume identity-related data.
This specification indicates the required and optional attributes, operations, and indexes the application will use when deployed.
Attribute Authority Policy Markup Language (AAPML) is a contract between an attribute authority and an attribute service.
AAPML is targeted towards the identity providers and defines the constraints under which identity data is released.
In other words, it specifies the rules and constraints to access attributes brokered by the service.
These rules are expressed using a form of XACML specifically focused on attributes, based on XACML 2.0.
For example, following rules/obligations will be considered by the identity provider to release identity-related data.
- Subject – characteristics of application, user, strength of authentication
- Resources – attribute names
- Actions – read or write
- Environment – Internet/Intranet/VPN/..
- Consent – availability of specific consent records
- Relationship between Subject and requested identity information
- Whether data can be cached or propagated further
The developer builds their application with minimal or no regard for how or where identity-related data comes from or is stored.
The application developer uses the CARML API to both declare the attribute data needed for the application and the operations needed to support the application.
The declaration is then used to either extract a CARML XML document (for manual configuration), or is automatically asserted when the application connects to the attribute service.
As far as the application developer is concerned, the attribute service manages how and where all identity-related data is processed.
The attribute authority works with attribute service administrator to decide under what conditions specific data may be released.
Together, they work together to define an AAPML document which specifies how and when the attribute services provide access to the authorities information and what operations are enabled.
Attribute service administrators take CARML requirements from applications and reconcile those requirements with available attribute data and existing policies.
They may be required to define mappings to handle differences between client applications and attribute sources.
For example, a client application might have an attribute SsnLast4Digits. While this doesn’t exist in any data store, they could create a mapping that simply allows matching against the last four digits of SSN in an appropriate attribute authority.
This allows for both schema conversion and enhancing usage of minimal information.
With IGF, enterprises will benefit in following ways:
- Rapid deployment of applications without change to identity infrastructures
- Meet legal, regulatory and enterprise policies on managing identity data
