1 / 30

Identity Governance Framework (“IGF”) Overview and Status

Identity Governance Framework (“IGF”) Overview and Status. Phil Hunt and Prateek Mishra. Agenda. Introduction Use Cases Standardization Path Q&A. Liberty Alliance. Standards development organization focused around enterprise use-cases enable a networked world based on open standards

hamal
Télécharger la présentation

Identity Governance Framework (“IGF”) Overview and Status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Identity Governance Framework (“IGF”) Overview and Status Phil Hunt and Prateek Mishra

  2. Agenda • Introduction • Use Cases • Standardization Path • Q&A

  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 • Q&A

  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 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?

  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 .NET Perl Java API Applications Applications API Applications API Existing Applications Client Apps Optional:LDAP, legacy protocolsWS-Trust STS Query ProtocolSAML / ID-WSF /SPML CARML :Attribute Requirements CARML :Attribute Requirements CARML :Attribute Requirements CARML :Attribute Requirements View A View B Identity PolicyEngine Identity Service Admins reconcile sources and policies with client CARML requirements to create “views” Delivery/Gateway/Enforcement AAPML :Attribute Use Policy AAPML :Attribute Use Policy AAPML :Attribute Use Policy LDAP, ODBC, SAML Query, SAML Assertions, … Authority1 End-User(s) Authority2 ExternalPartners Authority3 HR Systems Authority4 Departmental Systems Authority5 EnterpriseDirectory Identity Sources 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 • Q&A

  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 • 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

  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 • In parallel with creation of Liberty final specification drafts • Draft of CARML-compliant Attribute Services API available today

  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@oracle.com & prateek.mishra@oracle.com • Blog: blogs.oracle.com/identityprivacy

  30. Q &A

More Related