Marco Casassa Mont HP Labs, Trusted Systems Laboratory Hewlett Packard

Phil Hunt Identity Management Standards Oracle

Many governments have enacted, or are in the process of enacting, legislation or best practices regarding the appropriate use of personal information by service providers and businesses on the Internet. Examples include the Privacy Act of 1974, the Gramm-Leach-Bliley Act of 1999, and the Sarbanes Oxley Act of 2002. While these acts affect different industries, organizations, and jurisdictions, they all have common requirements to establish controls that ensure the confidentiality, security, accuracy and attestative quality of information through the use of information technology controls and audit systems. 

Many information technology systems are comprised of numerous data “silos” containing personal information of customers, employees and partners. Information is often duplicated between these silos to varying degrees of accuracy and quality. Since management procedures are often specific to each silo, inconsistencies in the care and control and use of this information are inevitable. With the possibility of inconsistent identity information, demonstrating operational stability and control as required by SOX becomes challenging.

As an example, consider that Human Resource systems have high quality personal and corporate information that may be of great value to enterprise control systems needing to determine privileges, roles, or rights of employees as they use key enterprise applications. HR information in particular is critical to enabling role-based systems that ensure the separation of duties required by SOX. However the re-use of information outside of the HR silo presents some challenging privacy, trust, and control questions. In order to use HR information to support other control systems, there must be controls on how private personal information is used, propagated, and relied upon outside of the human resources silo.

Increasing business service outsourcing also introduces another dimension to the information control and privacy problem. Globalization and outsourcing has increased distribution of information across departmental, organizational, and jurisdictional boundaries. This further complicates the challenges of SOX compliance and suggests a growing need for information technology standards.

While there are many proprietary or ad-hoc solutions to these requirements that work well within defined business environments or silos, the requirements of distributed systems and business models may stretch today’s solutions beyond the breaking point. Enterprises will be faced with growing forensic-like auditing requirements as consultants pour over many differing complex custom or proprietary systems, source-code, and architectures to determine an enterprise’s level of compliance with SOX and other GRC relevant requirements.

Identity Governance Framework
The Identity Governance Framework (IGF) is an initiative founded by Oracle, CA, HP, Novell, Sun and others in November of 2006 when the growing number of protocols and federated architectures began to indicate a common need for a standards based identity governance framework that would work in today’s ever-more distributed business environments. Soon after it’s founding, IGF became a strategic initiative of the Liberty Alliance Project (www.projectliberty.org) to provide a policy foundation for identity protocols such as LDAP, SAML, WS-TRUST, Liberty ID-WSF and other emerging protocols to ensure that organizations are meeting the terms and conditions for identity data as agreed to with their users and the governing regulatory requirements.

The intent of the IGF is to: (1) take into account legislation, business rules, guidelines and users’ requirements; (2) map these aspects into operational environments by adding declaration and policy to systems that produce and consume identity data; (3) use these declarations and policies to help all parties manage the risks and to provide a level of assurance to users that privacy and operational controls are being appropriately maintained and secured by the parties to whom they are entrusting with their information or who otherwise have access to this information.

The use of information from systems such as HR (e.g. to enable enterprise roles), or the sharing of personal consumer information, can lead to conflicts around privacy when information is shared with an external business partner. This can expose an organization to unwanted scrutiny if controls are not met or privacy is breached. To address this concern, IGF provides a standard way by which consumer consent and privacy settings can be maintained and observed by the systems exchanging information with service partners.

How IGF Works
IGF uses a layered approach to identity governance. It uses declarative requirements and policy that can be applied on top of standard protocols used to exchange identity-related information. This declarative layer describes the expected behavior of applications and systems when handling personal data. These declarations are influenced by legislation and organizational/business requirements. 

Instead of simplistic transfer of identity-related data between systems based on attribute lists and simple access controls, IGF adds privacy properties, consent data, and business agreement meta-data to allow control systems to better audit, track, and make policy decisions about whether the use of information is appropriate and trustable. Privacy properties include information such as how long data is to be persisted, whether data can be accessed or processed based on users’ consent for stated purposes or whether data can be propagated to other service providers.

The above diagram shows 3 possible parties in an identity information exchange. The User-Agent represents the user and may be a specialized client such as a web browser or other client. The Attribute Authority is any database, application, identity provider, or system that can be considered a provider of identity related information. Examples of Attribute Authorities are HR Systems, CRM Systems, corporate directories, or federated provider such as SAML assertion providers. Finally, the requestor of identity information is typically a web application. Depending on the interaction scenario, it is possible for a web application to obtain personal information via the User-Agent, or directly from an Attribute Authority. The path for information exchange will often vary based upon the demands of the protocol being used, and the privacy and attestation requirements behind the exchange.

In IGF-enabled exchanges there is an initial negotiation between attribute authorities and web application (the Identity “Client”). This process may be automatic or manual. Whether formally negotiated, or unilaterally asserted, it is assumed that parties will have a legal agreement defined for sharing information, and the terms for sharing a programmatically defined in advance. During this process, the Client Attributes Requirements Markup Language (CARML) declaration is provided to an attribute authority. The authority then determines if the requested transactions are acceptable and supportable. If necessary, the attribute authority may then define or modify its attribute authority policy (AAPML) authorizing the web application to make future requests to retrieve information. The attribute authority may also have to define schema mappings that fulfill the client application’s request. For example, a client may wish to have an assertion of “FirstClassEligible”. In response, the authority may need to evaluate the HR information (e.g. management level) to determine if the role of “FirstClassEligible” can be asserted.

Once the declarations and policy are in place, information can be exchanged between systems. On each exchange of information, “consent” rules can also be verified to that particular consent obligations collected on behalf of individuals represented by data records are observed. Each transaction request documents the legal context under which the request is made and also documents the promises being made by the requestor and the obligations the attribute authority has on the use of the data.

On receipt of an identity request, the attribute authority uses policy (AAPML – Attribute Authority Policy Markup Language) to determine if the action requested, the requestor, and the intended use meets policy. The attribute authority checks the context of the request including the requestor, the application making the request, the data requested, and checks if there are any consent conditions that must be met. An example of this might be confirming that the customer has indicated that sharing information with marketing partners is acceptable.

After processing the policy and consent rules, the attribute authority provides an identity response that includes the requested assertions and also includes any transactional exceptions (e.g. consent failures). The response will also include any “obligations” that the attribute authority may wish to have imposed on the data. Obligations can be things like “do not cache” or “do not propagate” or “delete data after a predefined period of time”.  Obligations may also be programmatic terms defined by the legal context that dictate other actions that the client must agree to.

Example Scenarios and Use Cases
Enterprise Identity Systems – Increasingly, enterprise web access policy systems need access not only corporate directory (LDAP) based information, but also human resource systems for access to dynamic role assertions to drive security systems. While LDAP has been a great tool for access to enterprise-wide information about individuals, it has become problematic when considering more confidential information such as management level, signing authority, or other information that might drive role based control and separation-of-duty systems due to corporate directories typically open access models. The use of AAPML addresses this problem by tightly controlling the context under which this information may be used. Enterprise security is improved because access decisions can be based on higher value information from sources like human resources rather than the more generic information from the enterprise directory.

Application Service Providers – An enterprise wishes to use the service of an outside travel booking agency over the web for corporate travel. The enterprise is able to assert information about its employees such as who is eligible to book first class tickets, or who is able to book travel on short notice. In this case a CARML declaration is provided by the travel booking service application to the federated enterprise attribute authority. The CARML declaration describes the travel service’s requirements for assertion about whether business travelers are eligible to book first class tickets (e.g. “FirstClassEligible”) or book travel on short notice (e.g. “LastMinuteTravel”). The enterprise attribute authority determines how “FirstClassEligible” and “LastMinuteTravel” maps to employee profiles in the enterprise’s HR systems and then defines an AAPML access policy enabling this assertion to be generated. To fulfill the request for a “FirstClassEligible” assertion, the HR attribute authority may choose to map this to an employee’s management level determining that anyone above management level “5” is eligible. Instead of passing the confidential management level to the travel service, the attribute authority simply confirms whether the employee is “FirstClassEligible”.

Consent Processing – An online travel agency customer has managed their online profile with the travel agency and with various airline frequent flier web sites. In the travel agency profile, the traveler sets personal preferences on frequent flier affiliations as well as setting consent preferences on which marketing partners the travel agency may share specific customer information with. Similarly, the frequent flier sites may have collected similar consent preferences controlling the propagation of information between partners. When booking a ticket, the travel web site queries the traveler’s frequent flier attribute authority to verify status and offer them a complimentary upgrade. To enable this, the traveler may have set consent policy authorizing the frequent flier program to allow access from travel agencies to check member status information.

IGF Progress
This past summer, the Liberty Alliance and Oracle announced the completion of an important milestone in the process for the development of a new standard known as the Identity Governance Framework. The Liberty Alliance has now referred IGF to the Liberty Technical Expert Group to complete the definition of IGF standards. It is expected the standards recommendations will be defined in a protocol neutral way with support for both existing protocols (LDAP) as well as newer federation protocols such as SAML. A formal draft standard is expected in 2008.

This past summer a multi-vendor initiative was also created to build an open source reference implementation of the IGF specifications under the openLiberty project (www.openliberty.org).  This work is based on the initial royalty free Oracle submission but will be revised as the draft standard is published. Because IGF is meant to work with multiple protocols, the openLiberty IGF project also aims to build a single API that developers can use that will be a mash-up implementation of many of today’s popular identity protocols such as ID-WSF, WS-*, and LDAP. An anticipated key benefit of this initiative is the protection of developers from the complex and variable protocol and deployment scenarios that will arise in the future.

Summary
Enterprise systems are becoming increasingly distributed across internal and external service providers. As we look at this from a SOX and a general governance, risk and compliance perspective, the importance of good quality, accurate, personal and private information becomes a larger issue for enterprises as existing technology solutions become too complex to support.

As enterprises consider their formal written policies for the consumption and use of personal information, they should look towards IGF as the best open, standards-based approach to programmatic enforcement of these written policies in the future. IGF provides declarative, request/response metadata (promises and obligations), and policy enforcement that documents and governs the use of identity-related information in networked systems and applications. IGF supports the evolving federation and user-centric protocols, as well as new and evolving governance and privacy legislation. While IGF is still in development, enterprises and software developers are encouraged to get involved and learn more about IGF and its benefits.

References

Identity Governance Overview, Liberty Alliance

IGF Privacy and Access Policy Market Requirements Document, Liberty Alliance

Information Accountability, Daniel J. Weitzner, Harold Abelson, Tim Berners-Lee, Joan Feigenbaum, James Hendler, and Gerald Jay Sussman, MIT-CSAIL-TR-2007-034

Oracle Identity Management: Governance, Risk, and Compliance Architecture, Marlin Pohlman, Osborne Oracle Press (to be published January 2008)

HP Labs: R&D on Identity Management and Privacy 

Definitions:

IGF – Identity Governance Framework 

LDAP – Lightweight Directory Access Protocol, Wikipedia

SAML – Security Assertion Markup Language, Wikipedia

GRC – Governance, Risk Management, & Compliance, Wikipedia

WS-Trust – OASIS Specification for issuing, renewing, and validation of security tokens

ID-WSF – Protocol for querying and modifying attributes in a web services framework, Liberty Alliance