SAML

Computacin Ubicua.
Mster Interuniversitario en Ingeniera
Telemtica

Andrs Marn Lpez amarin@it.uc3m.es

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

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 queries
issued by the
Attribute Requester

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 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 (id
and id attributes) asserted by AirlineInc.com

Web SSO

Identity 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?

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 linking

Account linking
1. John books a flight at
AirlineInc.com using his johndoe
user account.
2. John then uses a browser
bookmark or clicks on a link to visit
CarRentalInc.com to reserve a
car.
CarRentalInc.com sees that the
browser user is not logged in
locally but that he has previously
visited their IdP partner site
AirlineInc.com (optionally using
the new IdP discovery feature of
SAML V2.0).
So CarRentalInc.com asks John if
he would like to consent to
federate a local identity with
AirlineInc.com.

3. John consents to the federation

and his browser is redirected back
to AirlineInc.com where the site
creates a new pseudonym,
azqu3H7 for John's use when he
visits CarRentalInc.com. The
pseudonym is linked to his
johndoe account.
4. John is then redirected back to
CarRentalInc.com with a SAML
assertion indicating that the user
represented by the federated
persistent identifier azqu3H7 is
logged in at the IdP.
Since this is the first time that
CarRentalInc.com has seen this
identifier, it does not know which
local user account to which it
applies.

5. Thus, John must log in at

CarRentalInc.com using his jdoe
account.
Then CarRentalInc.com attaches the
identity azqu3H7 to the local jdoe
account for future use with the IdP
AirlineInc.com.
The user accounts at the IdP and this SP
are now linked using the federated
name identifier azqu3H7.
6. After reserving a car, John selects a
browser bookmark or clicks on a link
to visit HotelBooking.com in order to
book a hotel room.

7. The process is repeated with the IdP

AirlineInc.com, creating a new
pseudonym, f78q9C0, for IdP user
johndoe that will be used when
visiting HotelBooking.com.
8. John is redirected back to the
HotelBooking.com SP with a new
SAML assertion.
The SP requires John to log into his local
johnd user account and adds the
pseudonym as the federated name
identifier for future use with the IdP
AirlineInc.com.
The user accounts at the IdP and this SP
are now linked using the federated
name identifier f78q9C0.

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

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

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

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>

10

SOAP Binding
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
xmlns:env=http://www.w3.org/2003/05/soap/envelope/>
<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="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: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 user's account for privacy issues

11

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

12

SP-initiated, Redirect/POST

13

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

Enahnced Client Proxy profile

15

Example
User agent (Enhanced Client) request to SP:
GET /index HTTP/1.1
Host: identity-service.example.com
Accept: text/html; application/vnd.paos+xml
PAOS: ver='urn:liberty:paos:2003-08' ;
'urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp'

Use of Relay State (SP to ECP)

<SOAP-ENV:Envelope
xmlns: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://identityservice.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:Issu
er>
<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-fe91441e-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>

16

ECP to IdP Authn request

<SOAP-ENV:Envelope xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/"
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:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<ecp:Response SOAP-ENV:mustUnderstand="1" SOAPENV:
actor="http://schemas.xmlsoap.org/soap/actor/next"
AssertionConsumerServiceURL=
"https://ServiceProvider.example.com/ecp_assert_consume"
/>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<samlp:Response> ... </samlp:Response>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

17

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="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<paos:Response refToMessageID="6c3a4f8b9c2d" SOAPENV:
actor="http://schemas.xmlsoap.org/soap/actor/next/" SOAPENV:
mustUnderstand="1"/>
<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: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

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 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, certificatebased SSL).

Besides, the authentication context schema categorizes authentication

with: identification, technical protection, operational protection,
autehntication method, governing agreements.

19

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

20

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

21

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'>
<EncryptedData
Type='http://www.w3.org/2001/04/xmlenc#Element
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<Number>4019 2445 0277 5567</Number>
<CipherData>
<Issuer>Example
Bank</Issuer>
<CipherValue>A23B45C56</CipherValue>
<Expiration>04/02</Expiration>
</CipherData>
</EncryptedData>
</CreditCard>
</PaymentInfo>

22

XML Encryption
Optionally key info and encryption method
may appear within the EncryptedData element
<EncryptionMethod
Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/>
<ds:KeyInfo
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
<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