Identity Governance Framework IGF Overview and Status

1
Identity Governance Framework (IGF) Overview
and Status

• Phil Hunt and Prateek Mishra

2
Agenda

• Introduction
• Use Cases
• Standardization Path
• QA

3
Liberty Alliance

• Standards development organization focused around
  enterprise use-cases
• enable a networked world based on open standards
• Range of activitiies around assurance,
  federation, privacy
• Standards developed include ID-FF (precursor to
  SAML 2.0), ID-WSF, Identity Assurance frameworks
• http//www.projectliberty.org

4
Observations about Identity Data

• Names, home addresses, phone numbers, social
  security number, rank, e-mail address,
• Essential to enterprises and web sites providing
  services to customers
• Business applications cannot function without
  identity information
• Multiple sources of data (attribute authorities)
• Enterprise View HR, CRM, Partners, IT Directory,
  Departmental Systems,
• Internet View Portals, users, banks, employers,
  governments, retail, identity processors
  (background and credit checks)

5
Concerns about identity data

• Increasing legal and regulatory focus
• Privacy concerns HIPAA, SB 1386, theft
• Compliance SOX, GLB, EU legislation
• Industry vertical regulations credit bureaus,
  credit-card processors (PCI standard)
• With each new heist or problem, new regulation or
  best practice model
• There are going to be more issues in the future
• How can the enterprise reduce risk associated
  with storing and using identity data?
• Lock it all up!
• With each new regulation conduct forensic
  scanning and analysis of systems
• Invest in an architecture that supports a
  governance model for identity

6
Identity Governance Framework

• Open architecture that addresses governance of
  identity related information within the
  enterprise
• Standards development ongoing at the Liberty
  Alliance
• Open source implementation being created at
  http//www.openliberty.org
• Addresses gap between high-level assurance and
  regulatory requirements and lower-level protocols
  and architecture
• Privacy aware architecture that can express many
  different constraints and requirements
• Overlays on existing infrastructure at
  enterprises

7
impacts
impacts
8
IGF Focus

• How to reduce the risk associated with creation,
  maintenance and use of identity data?
• Who has access to my social security number or
  account number, and, under what conditions?
• Declarative statements (aka policies) published
  by consumers (applications, services) and sources
  of identity data (attribute authorities)
• Enterprises can audit and implement governance
  against these policies

9
Observations on Key Roles

• Users
• Capture what agreements the user accepted
• Reflect consent and purpose of data use
• But IGF does not directly address interactions
  with users
• Application developers are not identity experts
• How can they express application identity
  requirements?
• Tools and frameworks for developers are a key
  focus for IGF
• Identity Administrators
• Identity-related data is distributed web based
• User consent must be supported and enforced
• Enable owners of identity data to express use
  constraints

10
Agenda

• Introduction
• Components and Use Cases
• Standardization Path
• QA

11
IGF Components

• CARML Defines application identity requirements
• what identity information an application needs
  and how the application will use it.
• AAPML Defines identity use policies (XACML)
• Constraints on user and application access to
  personal data
• obligations and conditions under which data is
  to be released
• Attribute Service Links applications to
  identity data
• Developer APIs/Tools Developers can express
  identity requirements at a business level at
  development time
• Key to IGF adoption/use

12
Components

• CARML (kaar-mull) Client Attribute
  Requirements Markup Language
• Declarative model for consumption of attributes
  by applications
• List of required/optional attributes and types,
  other properties
• Developers focus on app business requirements for
  identity-related data
• Developers and deployers express privacy rules
  followed by application
• Will the data be stored by the app? For how long?
• What purpose is it being used for?

13
CARML Use-Case

• Application developer lists their identity
  requirements in CARML file
• Last four digits of user social security number
• User home address
• Office location in which user is employed
• None of this data is stored or forwarded to other
  applications
• Application is delivered to customers
• WidgetFactory, Inc. uses AD for employment level
  and office location, Oracle database for social
  security numbers
• AcmeCo uses MySQL database for office location,
  employment level, proprietary application for
  social security number.
• Administrators review CARML file and connect to
  appropriate back-end resources
• Ensure that enterprise privacy constraints are
  met by applications

14
Components

• Attribute Authorities
• AAPML (aap-mull) Attribute Authority Policy
  Markup Language
• Describes constraints on use of attribute data
• Declarative policy model for authorities that
  provide attributes
• Contextual rule support who is asking for the
  data? On whose behalf? For what purpose?
• User-consent support
• Direct enforcement policy
• Obligations declarations
• Proposed as XACML Profile

15
Sample AAPML Rules

• Users can update only their own contact
  information and personal data
• List of attributes telephone number, contact
  information, mailing address, emergency
  information
• Authorized Subjects Application SelfService,
  authenticated user
• Target Records must match the authenticated user
  context.
• Auth Requirements Proof of application
  authentication required
• Rights Read Write
• Consent Not required
• Marketing applications can access certain user
  attributes provided explicit user-consent is
  available
• List of attributes name, address, e-mail
• Authorized Subjects Any authenticated user with
  attribute employee, Any application in
  marketing
• Auth Requirements None
• Target Records any
• Rights Read
• Consent consent record based on agreement of Dec
  10, 2006 must be available

16
Components

• Identity Service
• Many possible realizations or implementations
• Could be client integrated, middleware server, or
  source-server integrated based service
• Read/Write attributes from many different sources
  using various protocols

17
Sample Architecture
Legend
StandardComponents
Run-Time Interactions
Admin Deploy Time Interactions
Existing or non-specified
Admin Deploy Run-Time Interactions
18
IGF Part 1 Foundations
Multi-protocol (LDAP, SQL, SAML, ID-WSF,
..)Focus on producers and consumers of identity
data
19
IGF Part 2 AAPML
Many distributed authorities, each capable of
expressing constraints on use of identity data
20
IGF Part 3 Declarative Applications
Applications publish requirements for identity
data
21
IGF Part 4 App Developer and Enterprise
Administrators

• Application Developer
• Identity needs of business applications expressed
  at a high-level
• Application developers lack identity middleware
  expertise
• Declarative model is preferred
• Ability to express identity requirements at a
  business-level without regard to sources
• Enterprise Administrators
• Support for deployment-time binding to specific
  identity architectures which vary over time and
  between enterprises
• Declarative approach simplifies compliance and
  configuration

22
IGF Lifecycle
23
Agenda

• Introduction
• Use Cases
• Standardization Path
• QA

24
Nov 2006 Oracle Announces IGF

• Open-vendor initiative to address handling of
  identity related information within enterprise
  lead by Oracle
• Released key draft specifications
• CARML and AAPML
• Sample CARML API
• Announced intention to submit to a standards org
• Key vendors supported initiative
• CA, Layer 7, HP, Novell, Ping Identity, Securent,
  Sun Microsystems

25
1H2007 Liberty Alliance

• Start of broader review on gathering expanded
  use-cases and market requirements
• Oracle makes IGF straw-man specifications
  available royalty-free
• Participation from
• Computer Associates, France Telecom/Orange,
  Fugen, HP, Intel, NEC, New Zealand, NTT, Oracle
• IGF Market Requirements Document Released July
  2007
• Use-cases, Scenarios, End-to-End Examples
• www.projectliberty.org/index.php/liberty/strategic
  _initiatives/identity_governance

26
Next Steps (2007-2008)

• Two parts -
• Development of open source components at
  www.openliberty.org
• Technical work specifications and profiles to
  continue at Liberty Alliance and complete in
  2H-2008
• Follows successful completion and publication of
  IGF Market Requirements Document within Liberty
  Alliance
• Supported by HP, CA, NEC, NTT, Novell, SUN and
  other partners

27
Open Source

• Hosted at www.openLiberty.com
• Based upon Apache 2.0 license
• Create software libraries aimed at developers
• Aligned with open source ecosystem (Higgins,
  Bandit)
• Re-use existing components wherever possible
• Simultaneous with creation of Liberty final
  specification drafts
• Based on Liberty IGF MRD and original Oracle IGF
  technical materials
• www.oracle.com/goto/igf
• www.projectliberty.org/index.php/liberty/strategic
  _initiatives/identity_governance
• Update to final Liberty drafts when available

28
Summary

• Identity Governance Framework
• Open initiative for identity governance across
  enterprise systems
• Key draft specifications provide initial policy
  components
• CARML, AAPML
• Intent to ratify as full standards at an existing
  standards body
• Under Liberty Alliance Leadership
• Broad input and support in an open standards
  process
• Legal community review
• IP clearances - open standards for everyone to use

29
Learn More

• www.projectliberty.org/index.php/liberty/strategic
  _initiatives/identity_governance
• IGF Overview Whitepaper
• FAQ
• Use Cases (MRD)
• Links to Oracle draft specifications CARML,
  AAPML, Client API
• Inquiries to
• Mail phil.hunt_at_oracle.com prateek.mishra_at_oracle
  .com
• Blog blogs.oracle.com/identityprivacy

30
Q A