Workshop on Security for Web Services. Amsterdam, April 2010 Applying SAML to Identity Data Exchange

Workshop on Security for Web Services. Amsterdam, April 2010 Setting the Landscape

Workshop on Security for Web Services. Amsterdam, April 2010 The Components An infrastructure supporting the trust fabric  Typically based on public keys  A set of protocols for data exchange  SAML is the lingua franca A common schema for syntax and semantics  eduPerson  SCHAC An agreement among participants Bi- or multi-lateral Through a unilateral declaration (affiliation)

Workshop on Security for Web Services. Amsterdam, April 2010 Identity Data Flow

Workshop on Security for Web Services. Amsterdam, April 2010 Map of Languages

Workshop on Security for Web Services. Amsterdam, April 2010 FØD. (USA) (AU) Circles All Around the Map Different technologies, even with identical technology the AAI systems may have different policy and purpose The “inter- federation soup”

Workshop on Security for Web Services. Amsterdam, April 2010 $ X.509 RADIUS Kerberos PAPI Shibboleth (SAML 1.1 plus extensions) SAML 2 WS-Sec OpenID WS-fed OAuth Map of Protocols

Workshop on Security for Web Services. Amsterdam, April 2010 Defining SAML Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between entities Product of the OASIS Security Services TC: Built upon the following standards:  XML  XML Schema  XML Signature  XML Encryption  HTTP  SOAP

Workshop on Security for Web Services. Amsterdam, April 2010 What SAML Is Made of Assertions (XML data units)  Authentication, Attribute and Authorization information Protocols (XML + processing rules)  Request and Response elements packaging assertions Bindings (HTTP, SOAP,…)  How SAML Protocols map onto standard messaging or communication protocols Profiles (Protocols + Bindings)  Define semantics for use cases Assertions and protocols together constitute SAML core  Syntactically defined by XML schema Profiles Bindings Protocol Assertions

Workshop on Security for Web Services. Amsterdam, April 2010 SAML Assertions An assertion contains a packet of security information: … How to interpret the assertion: “Assertion A was issued at time t by issuer R subject to conditions C” Assertions are the atomic unit of SAML  And constitute the element referred as a SAML token elsewhere

Workshop on Security for Web Services. Amsterdam, April 2010 Assertion Example A typical SAML assertion: The value of the Issuer element is the unique identifier of the SAML authority

Workshop on Security for Web Services. Amsterdam, April 2010 Subject Defines the principal that is the subject of all of the statements in the assertion The principal’s identifier  Several identifier formats supported  Different properties: uniqueness, persistency, opacity… One or more subject confirmations  Information that allows the subject to be confirmed  Method plus data associated to that method

Workshop on Security for Web Services. Amsterdam, April 2010 SAML Statements SAML assertions contain statements Authentication statements  Subject S authenticated at time t using authentication method m Attribute statements  Subject S is associated with attributes A,B,C having values “a”,”b”,”c” Authorization decision statements (deprecated)

Workshop on Security for Web Services. Amsterdam, April 2010 Peeling the Attribute Onion Relying parties use attributes to make access control decisions Standard attribute schemas with well understood values  Basic schemas  eduPerson  SCHAC  Community schemas  Local schemas Basic schemas (person, inetOrgPerson, organizationalPerson)‏ eduPerson schac iris-* Local schemas

Workshop on Security for Web Services. Amsterdam, April 2010 SAML Protocol Exchanges via a simple request/response protocol A Request initiates an exchange A Response often contains one or more assertions SAML Core (Assertions and Protocol) defines the structure of requests and responses Request AttributeQuery Response Assertion AttributeStatement

Workshop on Security for Web Services. Amsterdam, April 2010 The Trust Issue SAML supports a variety of security mechanisms  Transport-level security (SSL 3.0/TLS 1.0)  Message-level security (XMLSig/XMLEnc) Trust is established through the metadata IdPSP fccn.pt SCS CA rediris. es IRISGrid CA Can I trust this SP and send data about my users to it? Can I trust this IdP and accept the data it sends? SAML AttributeRequest SAML AttributeResponse Metadata

Workshop on Security for Web Services. Amsterdam, April 2010 SAML Metadata XML document, with a container element ( EntitiesDescriptor ) Individual elements for each known entity ( EntityDescriptor )  Endpoint references for different roles  Supported protocols and options  Keys using for encrypting and signing  Administrative and reference data Both the container and the individual elements can be signed and provide trust links  Plus hints on data liveliness Extension points for supporting additional services

Workshop on Security for Web Services. Amsterdam, April 2010 Next Steps: Dynamic Metadata Dynamically manage metadata for an entity or group of entities Publish-and-subscribe interfaces  Metadata aggregators  GÉANT MDS Well-know metadata locations  Maintained by the entity itself  Signed by a Trusted Third Party Much more flexible revocation schemas

Workshop on Security for Web Services. Amsterdam, April 2010 Next Steps: VO Support Entities providing additional attributes about users  Not available at their institutional IdP  Mostly because of management reasons The base for VO operation Several implementations currently available  VOMS (originally X.509-based, now with SAML gateway)  SWITCH VO management system (Shibboleth-based, SAML over Java)  RedIRIS AA (SAML over PHP)  FEIDE VO PoC (SAML on OAuth over PHP)  GÉANT about to deploy one

Workshop on Security for Web Services. Amsterdam, April 2010 Use Cases: WebSSO Identity data is exchanged through the user’s browser  SAML is used in steps 4, 5, 6 and 7 An additional element allowing the SP to decide the appropriate IdP (Discovery Service) not shown  Key to usability and security  Makes additional use of metadata Identity Provider Service Provider CLIENTCLIENT Authentication Authority Attribute Authority SSO Service Assertion Consumer Service Resource Attribute Requester 7 6

Workshop on Security for Web Services. Amsterdam, April 2010 Use Cases: WebSSO + SSH Connecting WebSSO and access to other applications Attributes are used to dynamically establish SSH public keys In use for teaching environments in combination with an invitation system

Workshop on Security for Web Services. Amsterdam, April 2010 Use Cases: DAMe

Workshop on Security for Web Services. Amsterdam, April 2010 Use Cases: WS (ECP)

Workshop on Security for Web Services. Amsterdam, April 2010 Use Cases: WS (star) Subject NameIdentifier

Workshop on Security for Web Services. Amsterdam, April 2010 Subject NameIdentifier Use Cases: WS (star)

Workshop on Security for Web Services. Amsterdam, April 2010 Subject NameIdentifier Use Cases: WS (chain)

Workshop on Security for Web Services. Amsterdam, April 2010 Subject NameIdentifier Use Cases: WS (chain)

Workshop on Security for Web Services. Amsterdam, April 2010 Subject NameIdentifier Use Cases: WS (chain)

Workshop on Security for Web Services. Amsterdam, April 2010 A Few Other Use Cases InfoCard  Enhancing usability OpenID  Simplify IdP discovery  Attribute query bootstrapping OAuth  Initial enrollment  RESTful WS (with OAuth WRAP) X.509  Derived personal certificates  PKI-based attribute authorities

Workshop on Security for Web Services. Amsterdam, April 2010 It’s About the Identity Identity transfer protocols are just vehicles for data transfer  Must not determine the nature of an individual identity Digital identities are more valuable as they are more widely assertable And SAML is a perfect mean as lingua franca  Protocols  Data formats  Metadata  All of them or some of them