SAML 2.0 and Related Work in XACML and WS-Security Hal Lockhart BEA Systems

Acknowledgements n Many of the slides provided by l Eve Maler, Sun Microsystems l Prateek Mishra, Principal Identity l Rob Philpott, RSA Security

Agenda n SAML History and Overview n SAML 2.0 New Features n SAML-related features in XACML n SAML in Web Services Security

SAML and the OASIS SSTC n SAML: Security Assertion Markup Language l A framework for the exchange of security-related information between trusting parties l The key standard for federated identity systems l Supports many real-world business scenarios l Widely used today for cross-domain single sign-on n OASIS Security Services Technical Committee (SSTC) l SSTC manages SAML development l 36 current voting members representing 24 organizations

SAML Timeline SAML 1.0 Completed: May 2002 OASIS Standard: November 2002 SAML 1.1 Completed: May 2003 OASIS Standard: September 2003 Liberty 1.1 Completed: Jan 2003 Shibboleth OpenSAML 1.0 Completed: June 2003 SAML 2.0 Completed: January 2005 OASIS Standard: March 2005 Nov-2002: SAML wins PC Magazine Technology Excellence Award Oct-2003: SSTC receives Digital ID World “Balancing Innovation & Reality" award Shibboleth OpenSAML 1.1 Completed: August 2003 Liberty ID-FF 1.2 Completed: Oct 2003

Specification Suite n Conformance Requirements l Required “Operational Modes” for SAML implementations n Assertions and Protocols l The “Core” specification n Bindings l Maps SAML messages onto common communications protocols n Profiles l “How-to’s” for using SAML to solve specific business problems n Metadata l Configuration data for establishing agreements between SAML entities n Authentication Context l Detailed descriptions of user authentication mechanisms n Security and Privacy Considerations l Security and privacy analysis of SAML 2.0 n Glossary l Terms used in SAML 2.0

SAML producer-consumer model

SAML assertions n Assertions are declarations of fact, according to someone n SAML assertions are compounds of one or more of three kinds of “statement” about “subject” (human or program): l Authentication l Attribute l Authorization decision n You can extend SAML to make your own kinds of assertions and statements n Assertions can be digitally signed

All statements in an assertion share common information n Issuer ID and issuance timestamp n Assertion ID n Subject l Name plus the security domain l Optional subject confirmation, e.g. public key n “Conditions” under which assertion is valid l SAML clients must reject assertions containing unsupported conditions l Special kind of condition: assertion validity period n Additional “advice” l E.g., to explain how the assertion was made

Authentication statement n An issuing authority asserts that subject S was authenticated by means M at time T n Targeted towards SSO uses

Attribute statement n An issuing authority asserts that subject S is associated with attributes A, B, … with values “a”, “b”, “c”… n Useful for distributed transactions and authorization services n Typically this would be gotten from an LDAP repository l “john.doe” in “example.com” l is associated with attribute “Department” l with value “Human Resources”

Authorization decision statement n An issuing authority decides whether to grant the request by subject S for access type A to resource R given evidence E n Useful for distributed transactions and authorization services n The subject could be a human or a program n The resource could be a web page or a web service, for example

SAML protocol for getting assertions

The SOAP-over-HTTP binding

Agenda n SAML History and Overview n SAML 2.0 New Features n SAML-related features in XACML n SAML in Web Services Security

SSTC SAML 2.0 Goals n Continue SSTC tradition of focusing on real-world business problems n SAML 2.0 Charter l Address issues and enhancement requests that have arisen from experience with real-world SAML implementations and with other security architectures that use SAML. l Add support for features that were deferred from previous versions of SAML. l Develop an approach for unifying various identity federation models found in real-world SAML implementations and SAML-based security architectures.

Business Benefits n Platform and vendor neutrality n Support for new devices n Consistent online user experience n Unified approach to identity federation n Improved control over identity data helps meet regulatory compliance requirements n Privacy protection and user consent mechanisms n Reduced deployment and administrative costs

SAML 2.0 New Features n Robust identity federation and management n Enhanced web single sign-on profile n Identity provider discovery n Basic session management and global logout n Encrypted attributes, name identifiers, and assertions n Profiles for well-defined attribute sharing n Fine-grained description of authentication mechanisms n Metadata for simplified configuration n Enhanced Client or Proxy (ECP) profile

Single-Sign On n Browser-driven SSO l Form POST, SAML Artifact Profiles n Note: conformant implementations must implement both profiles l Assertions may contain attribute statements n SAML 2.0 introduces notion of attribute profile l All or certain parts of an assertion may be encrypted n Important when security intermediaries are involved n SSO for enhanced client l Enhanced client is a device that understands HTTP but not SOAP n Also has “built in” knowledge of identity provider l Examples n HTTP proxies such as a WAP gateway n Consumer device with HTTP client

Identity Federation n What is Identity Federation? l Agreement between providers concerning data used to identify users n User-specific attributes: address? Office number and Employee Id? Role or membership in certain groups? n Unique, privacy-preserving identifiers known only to the providers? l Federated identifiers can be created in different ways n Dynamic assignment based on business agreements n Dynamic creation based on user consent n Out-of-band bulk synchronization or update at both parties

Identity Federation and Mgmt n Multiple types of Name Identifiers l Well-known names n Address n X.509 Subject Name n Windows Domain Qualified Name n Kerberos Principal Name l Privacy-preserving pseudonym identifiers n Transient n Persistent l Name Identifier Management Protocol and Profile n Assign new pseudonym identifiers n Terminate identity federation

Anonymous user with attributes or roles n User is never explicitly identified by a persistent identifier l A transient identifier is used as the “name” of the user l One or more roles or attributes describe the user n EmploymentLevel : Manager n AccessRights: Platinum n MemberOf: BellRingers l Access at Service Provider is given against roles or attributes n No need to maintain user entry at SP l Privacy Preserving as user identity at IdP remains unknown n Main use case in Shibboleth and some SAML 1.X deployments

User identified by privacy- preserving identifier n User is identified by a persistent randomized string private to IdP and SP pairs l Unique handle per service provider n Privacy-preserving since no information about user is available at SP n Requires IdP and SP to synchronize portions of their user stores n Affiliations: important sub-case where a single persistent randomized string is shared between a set of Service Providers n Main use case in ID-FF 1.X specifications and deployments

Session Mgmt and Logout n Session Participants l Identity Providers act as session authorities l Service Providers act as session participants l IdP defines session identifier(s) for SP’s l User may initiate logout at IdP or SP to terminate session l User may terminate individual or all active sessions n Follows ID-FF 1.2 closely (logout but no timeout) but also provides extension points for richer session models l Instructions for privacy preservation are provided

Standard Attribute Profiles n Supports attribute naming and values drawn from a variety of syntaxes l Basic Attribute Profile: string names and attribute values drawn from XML schema primitive types l X.500/LDAP Attribute Profile: use of canonical X.500/LDAP attribute names and values l UUID Attribute Profile: Use of UUIDs as attribute names l XACML Attribute Profile: formats suitable for processing by XACML n Attribute statements may be transferred during SSO or by the use of the AttributeQuery protocol n Attributes may be encrypted to ensure end-to-end confidentiality

Name Identifier Management n Protocol for communicating information about name identifiers l When identifiers should be updated n Replace by n Rollover privacy preserving identifier at SP every 6 months n Update identifier at IdP with identifier meaningful to SP l When an identifier will no longer be acceptable for federation n IdP will not issue any more assertions for n SP will not accept assertions for

Metadata n Improves deployment configuration of SAML components n Identifies distinct roles supported by an entity n SSO Identity Provider n SSO Service Provider n Attribute Authority n Authentication Authority n Policy Decision Point n Defines configuration and trust data such as: n Supported identifiers and profiles n SAML service endpoint URLs n Signing and encryption certificates n Metadata Publication and Resolution

Agenda n SAML History and Overview n SAML 2.0 New Features n SAML-related features in XACML n SAML in Web Services Security

eXtensible Access Control Markup Language (XACML) n Define a core XML schema for representing authorization and entitlement policies n Target - any object - referenced using XML n Fine grained control, characteristics - access requestor, protocol, classes of activities, and content introspection n Consistent with and building upon SAML

XACML Objectives n Ability to locate policies in distributed environment n Ability to federate administration of policies about the same resource n Base decisions on wide range of inputs l Multiple subjects, resource properties n Decision expressions of unlimited complexity n Ability to do policy-based delegation n Usable in many different environments l Types of Resources, Subjects, Actions l Policy location and combination

XACML History n First Meeting – 21 May 2001 n Requirements from: Healthcare, DRM, Registry, Financial, Online Web, XML Docs, Fed Gov, Workflow, Java, Policy Analysis, WebDAV n XACML OASIS Standard – 6 February 2003 n XACML 1.1 – Committee Specification – 7 August 2003 n XACML 2.0 – OASIS Standard – 1 February 2005

XACML 2.0 – SAML Features n SAML Attribute mapping n Authorization Decisions l Query l Response (Statement) n Policy Management l Policy Statement l Policy request/response

XACML 2.0 Uses SAML Features

Agenda n SAML History and Overview n SAML 2.0 New Features n SAML-related features in XACML n SAML in Web Services Security

Web Services Security (WSS) n Provides protection of SOAP messages n SOAP header element n Digital signatures and encryption n Greater flexibility than SSL/TLS n Supports multiple Security Token types l Username/password l Binary: X.509 and Kerberos l XML: SAML and REL

Web Services Security History n OASIS TC formed September 2002 n OASIS Standard in April 2004 l Core Specification + Username and X.509 Profiles n OASIS Standard December 2004 l SAML and REL Token Profiles n Attachments Profile completed public review n Kerberos Token Profile in process n WSS Version 1.1 in Progress l Complete document update l Backward compatible

SAML Token Profile n SAML Assertions in Security Header n Primary usage Attribute Statements n Subject Confirmation – Holder of Key l Digital signature or encryption n Subject Confirmation – Sender Vouches l Also supported

WSS SAML Token Profile

SAML 2.0 Summary n Convergence point for SAML 1.x, Liberty ID-FF, and Shibboleth as an OASIS Standard n New customer-driven features to: l Reduce deployment and administrative costs l Improve control over identity data to help meet regulatory compliance requirements l Enhance the web user online experience l Enhance privacy and user control over identity data n Complete identity federation solution with no missing “last mile” pieces n Complementary features in WS-Security and XACML