Addressing Interoperability Challenges June 12 & 13, 2007

Addressing Interoperability ChallengesJune 12 & 13, 2007 Gerry Gebel VP & Service Director ggebel@burtongroup.com

Addressing Interoperability Challenges • Agenda • Introduction • User-centric identity • XACML policy • Q&A

Introduction • Why host interoperability demonstrations? • Catalyst is a neutral forum for vendors and other technology providers to collaborate on interoperability • It’s great to see competitors working toward common goals • Interoperability demonstrations provide an indication of technology maturity • Not as robust as formal interoperability and testing programs • Expose differences in interpretation of specifications • Challenge providers to address requirements of realistic scenarios

Introduction • Interop demonstrations for Catalyst 2007 • User-centric identity - June 27 6-9:30pm • Information cards, OpenID, etc • Johannes Ernst, NetMesh • Mike Jones, Microsoft • Paul Trevithick, Social Physics • XACML - June 28 6-9:30pm • Extensible Access Control Markup Language • Managed by OASIS • Hal Lockhart, BEA • Rich Levinson, Oracle • WS-I - June 28 6-9:30pm • Web services security profiles • Not discussed on the call today

User-Centric Identity • Addressing some key questions • Why is user-centric identity important? • Why is interoperability important for user-centric identity? • What impact does the Catalyst interoperability event have on the industry?

User-Centric Identity • The Big Idea: • Identity “Self-Service” by the User • Good for businesses: • Reduced cost • More business through reduced friction with customer • Single view of the customer • Good for the individual: • Perception of increased control (e.g. privacy) • Less hassle (one root credential for many sites) • Higher-value products / services

User-Centric Identity Identifiers / URLs Example: http://netmesh.info/jernst Key standards: How it works Users sign up with an OpenID provider Issued URL becomes universal account name Diffie-Hellman-based Information Cards Example: Key standards: WS-Trust How it works User obtains card from business or provider “Identity Agent” installed on PC (e.g. Vista CardSpace) or hosted (e.g. Higgins H1)

User-Centric Identity • Participants and process • A combination of vendors, open source projects, and individual contributors • Microsoft, IBM, CA, BMC Software, Oracle, VeriSign, Ping Identity, Higgins, Bandit, NetMesh, WSO2, PamelaWare, XMLDAP.org, Internet2 Shibboleth Project, and Ian Brown • OSIS Project (“Open-Source Identity System”) • Process • Weekly conference calls • Face to face testing at recent IIW conference • Wiki used to collaborate and host documentation • http://osis.netmesh.org/

User-Centric Identity Expected Interop Outcomes Many vendors participating in interop Demonstrated multi-vendor interoperability Multiple protocols Interop scenarios Why it matters User-Centric Identity is here to stay User-centric identity can be expected to work No more protocol fights Glimpse of disruptive business potential

XACML Policy • XACML 2.0 overview • XML language for fine-grained access control • Extremely powerful evaluation logic • Ability to use any available information • Superset of permissions, ACLs, RBAC • Scales from Internet to PDA • Federated policy administration • OASIS and ITU-T Standard

XACML Policy • Burton Catalyst Conference • San Francisco, June 28, 2007, 6-9:30 pm • Tentative participants • BEA, CA, IBM, Jericho Systems, Oracle, Redhat, Securent, and Symlabs • Approach under discussion • Two Use cases (Policy Exchange, Decision) • Four Stock Trading Scenarios • Weekly concalls

XACML Policy • Policy exchange scenario PDP PAP Policy Policy Policy Policy Policy Repository

XACML Policy • Decision request scenario PDP PEP

XACML Policy • Interop challenges • Minimize extraneous components • Agree on items unspecified by XACML • Motivating business cases • Present understandable demo • Repeatable scenarios • Human error • Opportunity for ad hoc variants

XACML Policy • Use cases overview • Use cases spec available through OASIS XACML TC Public Home Page. • http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#announcements • Authorization logic externalized from applications • Enables centralization of critical business rules in XACML Policy Decision Point (PDP) • Vendor Interoperability achieved through: • Common policy specification language • Use of common application-specific vocabulary • Common request and response for policy execution

XACML Policy • Use cases interop document • Describes planning process for the Interop demo application and test framework • Describes architectural approach and implementation options for building demo infrastructure. • Contains detailed description of use cases and scenarios at data element and processing level. • Shows xacml usage models at a depth that goes beyond xacml-core specs and in total application context. • Can be used as sample for doing analysis for new applications

XACML Policy • Use case 1: Authorization Request - overview • Hypothetical Customer high-value stock account application • Account is “managed” by professional investment advisor • Customer can make trades within portfolio guidelines • If customer attempts trade outside programmed guidelines of trade size and credit limits, automatic request for approval is generated for the account manager to review and approve • Shows how xacml can be used to extract authorization logic from application using a custom vocabulary • Shows how fine grained authorization can be centrally managed for uniform control of enterprise business policies

XACML Policy • Use case 1: Authorization Request - technical • Shows how one vendor Policy Enforcement Point (PEP) can use other vendor PDP • Demo has application acting as PEP that sends a XACMLAuthz-DecisionQuery Request to PDP • XACML SAML 2.0 profile for PEP/PDP request/response • Shows variety of policy execution paths in PDP within Policy hierarchy • Shows how Obligations can be used to direct subsequent steps taken by PEP and application to initiate approval processes

XACML Policy • Use case 2: Policy Exchange • Department administrators at vendor-specific Policy Administration Point (PAP) create or modify Policies using custom tools • Policy can then be published into a centralized PDP and enforced by PEPs throughout the enterprise • Shows how Policy from one vendor PAP(/PDP) can be used by other vendor PDP(/PAP) • Create Policy at one vendor’s PAP and add to another vendor’s repository (or export Policy from PDP and add to repository) • Import other vendor’s policy from repository to PDP for execution (or to PAP for editing)

Addressing Interoperability Challenges Q & A

Addressing Interoperability Challenges June 12 & 13, 2007