Phil Hunt and Prateek Mishra
Introduction
Use Cases
Standardization Path
Q&A
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
Names, home addresses, phone numbers, social security number, rank, email 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)
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
• 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
Assurance
Liberty IAF,
PCI,
Privacy Legislation
Best Practices
Requirements that an enterprise or group of enterprises should meet to obtain certification.
impacts
Governance
IGF
XACML
Audit Standard?
Policy creation and update, policy enforcement, audit, decision explanation impacts
Run-time
Protocols
SQL, SAML 2.0
WS-*, LDAP
Run-time protocols and wire representations.
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
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
Introduction
Components and Use Cases
Standardization Path
Q&A
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
CARML (“kaar-mull”): Client Attribute Requirements
Markup Language
Declarative model for identity interactions by applications
List of required/optional attributes and types, other properties
Includes some support for update of identity data
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?
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
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
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 userconsent 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
Identity Service:
Many possible realizations or implementations
Could be client integrated, middleware server, or sourceserver integrated based service
Read/Write attributes from many different sources using various protocols
Client Apps
Java
Applications
.NET
Perl
API Applications API Applications API Existing Applications
CARML :
Attribute
Requirements
Requirements
Requirements
Requirements
View A
Query Protocol
SAML / ID-WSF /SPML
View B
Optional:
LDAP, legacy protocols
WS-Trust STS
Delivery/Gateway/
Enforcement
AAPML :
Attribute Use
Policy
Policy
Identity Policy
Engine
Identity Service
LDAP, ODBC, SAML Query, SAML Assertions, …
Admins reconcile sources and policies with client CARML requirements to create “views”
Identity Sources Authority1
End-User(s)
Authority2
External
Partners
Authority3
HR
Systems
Authority4
Departmental
Systems
Authority5
Enterprise
Directory
Legend
Run-Time Interactions
Admin Deploy Time Interactions
Admin Deploy & Run-Time Interactions
Standard
Components
Existing or non-specified
Multi-protocol (LDAP, SQL, SAML, ID-WSF, ..)
Focus on producers and consumers of identity data
Many distributed authorities, each capable of expressing constraints on use of identity data
Applications publish requirements for identity data
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 businesslevel 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
Introduction
Use Cases
Standardization Path
Q&A
1.
Open-vendor initiative to address handling of identity related information within enterprise lead by Oracle
2.
Released key draft specifications
CARML and AAPML
Sample CARML API
Announced intention to submit to a standards org
3.
Key vendors supported initiative
CA, Layer 7, HP, Novell, Ping Identity, Securent, Sun
Microsystems
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_initiativ es/identity_governance
Two parts -
Development of open source components at www.openliberty.org
Anticipate release of some components in 1H08
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
Anticipate release of some working drafts in 1H08
Supported by HP, CA, NEC, NTT, Novell, SUN and other partners
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
In parallel with creation of Liberty final specification drafts
Draft of CARML-compliant Attribute Services API available today
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
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@oracle.com & prateek.mishra@oracle.com
Blog: blogs.oracle.com/identityprivacy