Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. SAML Computación Ubicua. Máster Interuniversitario en Ingeniería Telemática Andrés Marín López amarin@it.uc3m.esIndex Introduction to SAML SAML Architecture SAML Profiles XML Encryption XML Digital Signature 1
  2. 2. Security Assertion Markup Lang SAML defines a framework for exchanging security information authentication and authorization between online partners Objective: Expressing assertions about a subject in a portable fashion that other applications across system domain boundaries can trustSAML entities Subject (Principal) entity that can be authenticated Asserting party (SAML authority) entity that makes the SAML assertions Relying party (SAML requester) entity that uses the received assertions In SSO, SAML defines the roles Identity Providers (IdP) issue assertions on its customers for Service Providers Service Providers use assertions for control access and provide customized services In attribute based authorization, SAML defines the roles Attribute Authority makes the assertions on identity attribute queries issued by the Attribute Requester 2
  3. 3. Drivers of SAML adoption Single Sign-On (SSO) interoperability browser cookies not transferred across separate DNS domains proprietary solutions Federated Identity (sharing information about user identities maintaning privacy) agree and establish a shared common name to refer to users in interactions across organizational boundaries avoid organizations collecting and maintaining identity related data user has more control Web services (WS-Security) SAML offers modularity and can be used in different protocol contexts SAML assertions are defined as security tokensSAML use cases Web (multi domain) single sign-on and have business (trust) relations There is a federated identity for a user User first authenticates to When user visits he is not required to authenticate again creates a local session for the user with the security information (id and id attributes) asserted by 3
  4. 4. Web SSOIdentity Federation use case A user identity is federated between a set of providers when there they agree on a set of identifiers and identity attributes by which the providers will refer to the user Questions to be addressed in the agreement: local identities at the sites linked together through the federated identifiers dynamic or pre-established federated identifiers explicit consent of users to establishment of federated identity Do identity attributes about the users need to be exchanged? Should the identity federation rely on transient identifiers that are destroyed at the end of the user session? privacy of information to be exchanged. Is encryption needed? 4
  5. 5. SAML 2.0 SAML V2.0 introduced two features to enhance its federated identity capabilities. new constructs and messages added to support the dynamic establishment and management of federated name identifiers two new types of name identifiers were introduced with privacy-preserving characteristics The process of associating a federated identifier with the local identity at a partner (or partners) where the federated identity will be used is often called account linking. Example of account linkingAccount linking 1. John books a flight at 3. John consents to the federation using his johndoe and his browser is redirected back user account. to where the site 2. John then uses a browser creates a new pseudonym, bookmark or clicks on a link to visit azqu3H7 for Johns use when he to reserve a visits The car. pseudonym is linked to his sees that the johndoe account. browser user is not logged in 4. John is then redirected back to locally but that he has previously with a SAML visited their IdP partner site assertion indicating that the user (optionally using represented by the federated the new IdP discovery feature of persistent identifier azqu3H7 is SAML V2.0). logged in at the IdP. So asks John if Since this is the first time that he would like to consent to has seen this federate a local identity with identifier, it does not know which local user account to which it applies. 5
  6. 6. 5. Thus, John must log in at 7. The process is repeated with the IdP using his jdoe, creating a new account. pseudonym, f78q9C0, for IdP userThen attaches the johndoe that will be used when identity azqu3H7 to the local jdoe visiting account for future use with the IdP 8. John is redirected back to the SP with a newThe user accounts at the IdP and this SP SAML assertion. are now linked using the federated The SP requires John to log into his local name identifier azqu3H7. johnd user account and adds the6. After reserving a car, John selects a pseudonym as the federated name browser bookmark or clicks on a link identifier for future use with the IdP to visit in order to book a hotel room. The user accounts at the IdP and this SP are now linked using the federated name identifier f78q9C0. 6
  7. 7. SAML Architecture: componentsSAML Assertions Authentication statements Issued by the party that authenticates the user {issuer, subject, validity period, other info} Attribute statements Specific on the subject, i.e. “JD has gold status” Authorization descision statements Define something the user is entitled to do, i.e. “J.D. can buy a specific item” 7
  8. 8. SAML protocols Assertion Query and Request Protocol Subject request assertions containing authentication statements and, optionally, attribute statements. Single Logout Protocol To allow near-simultaneous logout of active sessions associated with a principal. Assertion Query and Request Protocol Set of queries by which SAML assertions may be obtained. Artifact Resolution Protocol To pass SAML protocol messages by reference Name Identifier Management Protocol To change the value or format of a principal name identifier, and to terminate an association of a name identifier between an identity provider and service provider. Name Identifier Mapping Protocol Programmatically map one SAML name identifier into another, subject to appropriate policy controls. It permits, for example, one SP to request from an IdP an identifier for a user that the SP can use at another SP in an application integration scenario.SAML bindings SAML SOAP Binding How SAML protocol messages are transported in SOAP1.1 messages Reverse SOAP Binding (PAOS) SOAP/HTTP mesage interchange, so that an HTTP client can be a SOAP responder For ECP and WAP HTTP Redirect Binding HTTP Post Binding HTTP Artifact Binding SAML URI Binding Retrieving SAML assertion resolving a URI 8
  9. 9. SAML Profiles Web Browser Single Sign-On Profile Mechanism for SSO unmodified web browsers to multiple SP. HTTP Redirect, Post, and Artifact bindings Authentication Request Protocol Enhanced Client and Proxy (ECP) Profile SSO for limited clients or gateways SOAP and PAOS bindings Authentication Request Protocol Identity Provider Discovery Profile How SP can learn about IdPs previously visited by the user Single Logout Profile SAML Single Logout Protocol SOAP, HTTP Redirect, Post, and Artifact bindings Assertion Query/Request Profile How to obtain SAML assertions over a synchronous binding SAML Query and Request Protocol SOAP Binding Artifact Resolution Profile Name Identifier Management Profile Name Identifier Mapping ProfileEjemplo 9
  10. 10. Example: authorization assertion <saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” Version="2.0" IssueInstant="2005-01-31T12:00:00Z"> <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity> </saml:Issuer> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> </saml:NameID> </saml:Subject> <saml:Condition NotBefore="2005-01-31T12:00:00Z" NotOnOrAfter="2005-01-31T12:10:00Z"> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion>Example: Attribute statement <saml:AttributeStatement> <saml:Attribute xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri“ Name="urn:oid:" FriendlyName="givenName"> <saml:AttributeValue xsi:type="xs:string“ x500:Encoding="LDAP">John</saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" Name="LastName"> <saml:AttributeValue xsi:type="xs:string">Doe</saml:AttributeValue> </saml:Attribute> <saml:Attribute NameFormat= Name=“CreditLimit”> xmlns:smithco=”” <saml:AttributeValue xsi:type=“smithco:type”> <smithco:amount currency=“USD”>500.00</smithco:amount> </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> 10
  11. 11. SOAP Binding <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env=””> <env:Body> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" ID="f0485a7ce95939c093e3de7b2e2984c0" IssueInstant="2005-01-31T12:00:00Z" Destination="" > AssertionConsumerServiceIndex=”1” AttributeConsumingServiceIndex="0" > <saml:Issuer></saml:Issuer> <samlp:RequestedAuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" </samlp:NameIDPolicy> </samlp:AuthnRequest> </env:Body> </env:Envelope>Security in SAML SAML allows for message integrity by supporting XML digital signatures in request/response messages. SAML suports public key exchange either out of band or included in request/response messages. If additional message privacy is needed, SAML supports sending request/response messages over SSL 3.0 or TLS 1.0. Other security features security levels of the different bindings, both the IDP and SP can create opaque handles to represent the users account for privacy issues 11
  12. 12. SAML y XACMLWeb Browser SSO Profile Different options who initiates the SSO (where the user starts the process) IdP SP which bindings are used HTTP Redirect (request only) HTTP POST HTTP Artifact RelayState mechanism SP may use to associate the profile exchange with the original request SP should be opaque in the RelayState value unless no privacy is required 12
  13. 13. SP-initiated, Redirect/POST 13
  14. 14. IdP initiated, POSTEnahnced Client or Proxy (ECP)Profile An ECP is a client or proxy that satisfies: It has, or knows how to obtain, information about the identity provider that the principal associated with the ECP wishes to use, in the context of an interaction with a service provider It is able to use a reverse SOAP (PAOS) binding for an authentication request and response The ECP may be viewed as a SOAP intermediary between the service provider and the identity provider. It is a specific application of the Web browser SSO profile 14
  15. 15. Enahnced Client Proxy profile 15
  16. 16. Example User agent (Enhanced Client) request to SP: GET /index HTTP/1.1 Host: Accept: text/html; application/vnd.paos+xml PAOS: ver=urn:liberty:paos:2003-08 ; urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecpUse of Relay State (SP to ECP) <SOAP-ENV:Envelope <saml:Issuer></saml:Issu xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" er> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" <samlp:IDPList> xmlns:SOAP-ENV=""> <samlp:IDPEntry <SOAP-ENV:Header> ProviderID="" <paos:Request xmlns:paos="urn:liberty:paos:2003-08" Name="Identity Provider X" Loc="" responseConsumerURL="http://identity-" </samlp:IDPEntry> messageID="6c3a4f8b9c2d" SOAPENV: <samlp:GetComplete> actor="" SOAPENV: 441e-afb8 mustUnderstand="1" </samlp:GetComplete> service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"> </samlp:IDPList> </paos:Request> </ecp:Request> <ecp:Request xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp <ecp:RelayState " xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp " SOAP-ENV:mustUnderstand="1" SOAPENV: SOAP-ENV:mustUnderstand="1" SOAPENV: actor="" actor=""> ProviderName="Service Provider X" IsPassive="0"> ... </ecp:RelayState> </SOAP-ENV:Header> <SOAP-ENV:Body> <samlp:AuthnRequest> ... </samlp:AuthnRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 16
  17. 17. ECP to IdP Authn request <SOAP-ENV:Envelope xmlns:SOAP- ENV="" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" <SOAP-ENV:Body> <samlp:AuthnRequest> ... </samlp:AuthnRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope>Auth response (IdP to ECP) <SOAP-ENV:Envelope xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:SOAP- ENV=""> <SOAP-ENV:Header> <ecp:Response SOAP-ENV:mustUnderstand="1" SOAPENV: actor="" AssertionConsumerServiceURL= "" /> </SOAP-ENV:Header> <SOAP-ENV:Body> <samlp:Response> ... </samlp:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 17
  18. 18. ECP to SP response <SOAP-ENV:Envelope xmlns:paos="urn:liberty:paos:2003-08" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:SOAP-ENV=""> <SOAP-ENV:Header> <paos:Response refToMessageID="6c3a4f8b9c2d" SOAPENV: actor="" SOAPENV: mustUnderstand="1"/> <ecp:RelayState xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" SOAP-ENV:mustUnderstand="1" SOAPENV: actor=""> ... </ecp:RelayState> </SOAP-ENV:Header> <SOAP-ENV:Body> <samlp:Response> ... </samlp:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope>ECP Security Considerations <AuthnRequest> message SHOULD be signed. Assertions in the <Response> MUST be signed. The SOAP headers SHOULD be integrity protected SOAP Message Security or HTTPS SP SHOULD be authenticated to the ECP The ECP SHOULD be authenticated to the IdP 18
  19. 19. Single Logout Profile LogoutRequest may be issued: • Session Participant • IdPSAML Authentication Contexts Relying party may require information additional to the assertion itself in order to assess its level of confidence in that assertion SAML does not prescribe a single technology, it presently allows many and it can be extended Additional to the authentication other context information may be sent: The initial user identification mechanisms (for example, face-to-face, online, shared secret). The mechanisms for minimizing compromise of credentials (for example, credential renewal frequency, client-side key generation). The mechanisms for storing and protecting credentials (for example, smartcard, password rules). The authentication mechanism or method (for example, password, certificate- based SSL). Besides, the authentication context schema categorizes authentication with: identification, technical protection, operational protection, autehntication method, governing agreements. 19
  20. 20. Context Authentication Schemas main schema, common schema types, IP, IP password, Kerberos, mobile one-factor contract, mobile one-factor unregistered, mobile two-factor contract, mobile two-factor unregistered, nomadic telephony, personal telephony, PGP, password-protected transport, password, previous session, smartcard, smartcard PKI, software PKI, SPKI, secure remote password, SSL certificate, telephony, authenticated telephony, time sync token, X.509, XML SignatureReferences OASIS SAML Homepage: wg_abbrev=security Standards: Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, Bindings, … T Gross “Security analysis of the SAML single sign-on browser/artifact profile”. 19th Computer Security Applications Conference, 2003. 20
  21. 21. XML Digital Signature& XML EncryptionXML Signature XML Signature is a method of associating a key with referenced data Signatures are related to data objects via URIs to local data objects via fragment identifiers (enveloping vs enveloped signatures) to external network resources (dettached signatures) Transform element tells how the signer obtained the data object that was digested. KeyInfo enables the recipient(s) to obtain the key needed to validate the signature 21
  22. 22. Ejemplo <Signature Id="MyFirstSignature" xmlns=""> <SignedInfo> <CanonicalizationMethod Algorithm=""/> <SignatureMethod Algorithm=""/> <Reference URI=""> <Transforms> <Transform Algorithm=""/> </Transforms> <DigestMethod Algorithm=""/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> <P>...</P><Q>...</Q><G>...</G><Y>...</Y> </DSAKeyValue> </KeyValue> </KeyInfo> </Signature>XML Encryption Encrypting data and representing the result in XML <?xml version=1.0?> <PaymentInfoxmlns=> <Name>John Smith</Name> <EncryptedData Limit=5,000 Currency=USD> <CreditCard Type=‘ xmlns=> <Number>4019 2445 0277 5567</Number> <CipherData> <Issuer>Example Bank</Issuer> <CipherValue>A23B45C56</CipherValue> <Expiration>04/02</Expiration> </CipherData> </EncryptedData> </CreditCard> </PaymentInfo> 22
  23. 23. XML Encryption Optionally key info and encryption method may appear within the EncryptedData element <EncryptionMethod Algorithm=> <ds:KeyInfo xmlns:ds=> <ds:KeyName>John Smith</ds:KeyName> </ds:KeyInfo> If CipherValue is not supplied directly, the CipherReference identifies a source which, when processed, yields the encrypted octet sequence 23