1

SAML

Computación Ubicua. Máster Interuniversitario en Ingeniería Telemática

Andrés Marín López amarin@it.uc3m.es

Index

� Introduction to SAML� SAML Architecture� SAML Profiles� XML Encryption� XML Digital Signature

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 trust

SAML 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 queriesissued by the

� Attribute Requester

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 identitiesmaintaning 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 tokens

SAML use cases

� Web (multi domain) single sign-on� AirlineInc.com and CarRentalInc.com have

business (trust) relations� There is a federated identity for a user� User first authenticates to AirlineInc.com� When user visits CarRentalInc.com he is

not required to authenticate again� CarRentalInc.com creates a local session

for the user with the security information (idand id attributes) asserted by AirlineInc.com

4

Web SSO

Identity Federation use case

� A user identity is federated between a set of providerswhen there they agree on a set of identifiers andidentity attributes by which the providers will refer tothe 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?

5

SAML 2.0

� SAML V2.0 introduced two features toenhance its federated identity capabilities. � new constructs and messages added to support the

dynamic establishment and management offederated name identifiers

� two new types of name identifiers were introducedwith privacy-preserving characteristics

� The process of associating a federatedidentifier with the local identity at a partner (orpartners) where the federated identity will be used is often called account linking.� Example of account linking

Account linking

1. John books a flight atAirlineInc.com using his johndoeuser account.

2. John then uses a browserbookmark or clicks on a link to visitCarRentalInc.com to reserve a car.

CarRentalInc.com sees that thebrowser user is not logged in locally but that he has previouslyvisited their IdP partner siteAirlineInc.com (optionally usingthe new IdP discovery feature ofSAML V2.0).

So CarRentalInc.com asks John ifhe would like to consent tofederate a local identity withAirlineInc.com.

3. John consents to the federationand his browser is redirected back to AirlineInc.com where the sitecreates a new pseudonym, azqu3H7 for John's use when he visits CarRentalInc.com. Thepseudonym is linked to hisjohndoe account.

4. John is then redirected back toCarRentalInc.com with a SAML assertion indicating that the userrepresented by the federatedpersistent identifier azqu3H7 islogged in at the IdP.

Since this is the first time thatCarRentalInc.com has seen thisidentifier, it does not know whichlocal user account to which itapplies.

6

5. Thus, John must log in atCarRentalInc.com using his jdoeaccount.

Then CarRentalInc.com attaches theidentity azqu3H7 to the local jdoeaccount for future use with the IdPAirlineInc.com.

The user accounts at the IdP and this SP are now linked using the federatedname identifier azqu3H7.

6. After reserving a car, John selects a browser bookmark or clicks on a link to visit HotelBooking.com in order tobook a hotel room.

7. The process is repeated with the IdPAirlineInc.com, creating a newpseudonym, f78q9C0, for IdP userjohndoe that will be used whenvisiting HotelBooking.com.

8. John is redirected back to theHotelBooking.com SP with a newSAML assertion.

The SP requires John to log into his local johnd user account and adds thepseudonym as the federated nameidentifier for future use with the IdPAirlineInc.com.

The user accounts at the IdP and this SP are now linked using the federatedname identifier f78q9C0.

7

SAML Architecture: components

SAML 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”

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 serviceprovider.

� 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 anIdP an identifier for a user that the SP can use at another SP in an applicationintegration 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

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 Profile

Ejemplo

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>http://www.example.com</saml:Issuer><saml:Subject>

<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">j.doe@example.com

</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:2.5.4.42"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=http://smithco.com/attr-formats Name=“CreditLimit”>

xmlns:smithco=”http://www.smithco.com/smithco-schema.xsd”<saml:AttributeValue xsi:type=“smithco:type”>

<smithco:amount currency=“USD”>500.00</smithco:amount></saml:AttributeValue>

</saml:Attribute></saml:AttributeStatement>

11

SOAP Binding

<?xml version="1.0" encoding="UTF-8"?><env:Envelopexmlns:env=”http://www.w3.org/2003/05/soap/envelope/”><env:Body><samlp:AuthnRequestxmlns: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="https://www.AirlineInc.com/IdP/" >AssertionConsumerServiceIndex=”1”AttributeConsumingServiceIndex="0" ><saml:Issuer>http://www.CarRentalInc.com</saml:Issuer><samlp:RequestedAuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef><samlp:NameIDPolicyFormat="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 bandor included in request/response messages.

� If additional message privacy is needed, SAML supports sending request/response messages overSSL 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 user's account for privacy issues

12

SAML y XACML

Web 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

13

SP-initiated, Redirect/POST

14

IdP initiated, POST

Enahnced 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 associatedwith the ECP wishes to use, in the context of aninteraction with a service provider

� It is able to use a reverse SOAP (PAOS) binding foran authentication request and response

� The ECP may be viewed as a SOAP intermediary between the service provider andthe identity provider.

� It is a specific application of the Web browserSSO profile

15

Enahnced Client Proxy profile

16

Example

User agent (Enhanced Client) request to SP:

GET / i ndex HTTP/ 1. 1

Host : i dent i t y- ser v i ce. exampl e. com

Accept : t ext / ht ml ; appl i cat i on/ vnd. paos+xml

PAOS: ver =' ur n: l i ber t y: paos: 2003- 08' ;

' ur n: oasi s: names: t c: SAML: 2. 0: pr of i l es: SSO: ecp'

Use of Relay State (SP to ECP)

<SOAP-ENV:Envelopexmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header>

<paos:Request xmlns:paos="urn:liberty:paos:2003-08"responseConsumerURL="http://identity-

service.example.com/abc"messageID="6c3a4f8b9c2d" SOAPENV:actor="http://schemas.xmlsoap.org/soap/actor/next" SOAPENV:mustUnderstand="1"service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"></paos:Request><ecp:Request

xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"

SOAP-ENV:mustUnderstand="1" SOAPENV:actor="http://schemas.xmlsoap.org/soap/actor/next"ProviderName="Service Provider X" IsPassive="0">

<saml:Issuer>https://ServiceProvider.example.com</saml:Issuer>

<samlp:IDPList><samlp:IDPEntry

ProviderID="https://IdentityProvider.example.com"Name="Identity Provider X"Loc="https://IdentityProvider.example.com/saml2/sso"</samlp:IDPEntry><samlp:GetComplete>https://ServiceProvider.example.com/idplist?id=604be136-fe91-

441e-afb8</samlp:GetComplete></samlp:IDPList></ecp:Request><ecp:RelayState

xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"

SOAP-ENV:mustUnderstand="1" SOAPENV:actor="http://schemas.xmlsoap.org/soap/actor/next">...</ecp:RelayState></SOAP-ENV:Header><SOAP-ENV:Body>

<samlp:AuthnRequest> ... </samlp:AuthnRequest>

</SOAP-ENV:Body></SOAP-ENV:Envelope>

17

ECP to IdP Authn request

<SOAP- ENV: Envel ope xml ns: SOAP-ENV=" ht t p: / / schemas. xml soap. or g/ soap/ envel ope/ "

xml ns: saml p=" ur n: oasi s: names: t c: SAML: 2. 0: pr ot ocol "

<SOAP- ENV: Body>

<saml p: Aut hnRequest > . . . </ saml p: Aut hnRequest >

</ SOAP- ENV: Body>

</ SOAP- ENV: Envel ope>

Auth response (IdP to ECP)

<SOAP- ENV: Envel opexml ns: ecp=" ur n: oasi s: names: t c: SAML: 2. 0: pr of i l es: SSO: ecp"xml ns: saml p=" ur n: oasi s: names: t c: SAML: 2. 0: pr ot ocol "xml ns: SOAP-

ENV=" ht t p: / / schemas. xml soap. or g/ soap/ envel ope/ " ><SOAP- ENV: Header ><ecp: Response SOAP- ENV: must Under st and=" 1" SOAPENV:act or =" ht t p: / / schemas. xml soap. or g/ soap/ act or / next "Asser t i onConsumer Ser vi ceURL=" ht t ps: / / Ser vi cePr ovi der . exampl e. com/ ecp_asser t _consume"

/ ></ SOAP- ENV: Header ><SOAP- ENV: Body><saml p: Response> . . . </ saml p: Response></ SOAP- ENV: Body></ SOAP- ENV: Envel ope>

18

ECP to SP response

<SOAP- ENV: Envel opexml ns: paos=" ur n: l i ber t y : paos: 2003- 08"xml ns: saml p=" ur n: oasi s: names: t c: SAML: 2. 0: pr ot ocol "xml ns: SOAP- ENV=" ht t p: / / schemas. xml soap. or g/ soap/ envel ope/ " ><SOAP- ENV: Header ><paos: Response r ef ToMessageI D=" 6c3a4f 8b9c2d" SOAPENV:act or =" ht t p: / / schemas. xml soap. or g/ soap/ act or / next / " SOAPENV:must Under st and=" 1" / ><ecp: Rel aySt at e

xml ns: ecp=" ur n: oasi s: names: t c: SAML: 2. 0: pr of i l es: SSO: ecp"SOAP- ENV: must Under st and=" 1" SOAPENV:act or =" ht t p: / / schemas. xml soap. or g/ soap/ act or / next " >. . .</ ecp: Rel aySt at e></ SOAP- ENV: Header ><SOAP- ENV: Body><saml p: Response> . . . </ saml p: Response></ SOAP- ENV: Body></ SOAP- ENV: Envel ope>

ECP Security Considerations

� <AuthnRequest> message SHOULD be signed.

� Assertions in the <Response> MUST be signed.

� The SOAP headers SHOULD be integrityprotected� SOAP Message Security or� HTTPS

� SP SHOULD be authenticated to the ECP� The ECP SHOULD be authenticated to the IdP

19

Single Logout Profile

LogoutRequest may be issued:• Session Participant• IdP

SAML 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 manyand 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.

20

Context Authentication Schemas

main schema, common schema types, IP, IPpassword, Kerberos, mobile one-factor contract, mobile one-factor unregistered, mobile two-factor contract, mobile two-factor unregistered, nomadic telephony, personal telephony, PGP, password-protectedtransport, password, previous session, smartcard, smartcard PKI, software PKI, SPKI, secure remote password, SSL certificate, telephony, authenticated telephony, time synctoken, X.509, XML Signature

References

� OASIS SAML Homepage:http://www.oasis-open.org/committees/tc_home.php?

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.

21

XML Digital Signature& XML Encryption

XML 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

22

Ejemplo

<Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>

<Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> <Transforms>

<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Transforms>

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><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='http://example.org/paymentv2'>

<Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'>

<Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration>

</CreditCard> </PaymentInfo>

<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element‘xmlns='http://www.w3.org/2001/04/xmlenc#'>

<CipherData><CipherValue>A23B45C56</CipherValue>

</CipherData> </EncryptedData>

23

XML Encryption

� Optionally key info and encryption methodmay appear within the EncryptedData element

<Encr ypt i onMet hod

Al gor i t hm=' ht t p: / / www. w3. or g/ 2001/ 04/ xml enc#t r i pl edes- cbc' / >

<ds: KeyI nf o xml ns: ds=' ht t p: / / www. w3. or g/ 2000/ 09/ xml dsi g#' >

<ds: KeyName>John Smi t h</ ds: KeyName>

</ ds: KeyI nf o>

� If CipherValue is not supplied directly, theCipherReference identifies a source which, when processed, yields the encrypted octetsequence