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
1

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

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

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

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 linking
Account linking
1. John books a flight at 3. John consents to the federation
AirlineInc.com using his johndoe and his browser is redirected back
user account. to AirlineInc.com where the site
2. John then uses a browser creates a new pseudonym,
bookmark or clicks on a link to visit azqu3H7 for John's use when he
CarRentalInc.com to reserve a visits CarRentalInc.com. The
car. pseudonym is linked to his
CarRentalInc.com sees that the johndoe account.
browser user is not logged in 4. John is then redirected back to
locally but that he has previously CarRentalInc.com with a SAML
visited their IdP partner site assertion indicating that the user
AirlineInc.com (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 CarRentalInc.com asks John if Since this is the first time that
he would like to consent to CarRentalInc.com has seen this
federate a local identity with identifier, it does not know which
AirlineInc.com. local user account to which it
applies.
5

6. 5. Thus, John must log in at 7. The process is repeated with the IdP
CarRentalInc.com using his jdoe AirlineInc.com, creating a new
account. pseudonym, f78q9C0, for IdP user
Then CarRentalInc.com attaches the johndoe that will be used when
identity azqu3H7 to the local jdoe visiting HotelBooking.com.
account for future use with the IdP 8. John is redirected back to the
AirlineInc.com. HotelBooking.com SP with a new
The 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 the
6. 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 HotelBooking.com in order to AirlineInc.com.
book a hotel room. The user accounts at the IdP and this SP
are now linked using the federated
name identifier f78q9C0.
6

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

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

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

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

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
12

13. SP-initiated, Redirect/POST
13

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 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. Enahnced Client Proxy profile
15

16. 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 <saml:Issuer>https://ServiceProvider.example.com</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="http://schemas.xmlsoap.org/soap/envelope/"> <samlp:IDPEntry
<SOAP-ENV:Header> ProviderID="https://IdentityProvider.example.com"
<paos:Request xmlns:paos="urn:liberty:paos:2003-08" Name="Identity Provider X"
Loc="https://IdentityProvider.example.com/saml2/sso"
responseConsumerURL="http://identity-
service.example.com/abc" </samlp:IDPEntry>
messageID="6c3a4f8b9c2d" SOAPENV: <samlp:GetComplete>
actor="http://schemas.xmlsoap.org/soap/actor/next" SOAPENV: https://ServiceProvider.example.com/idplist?id=604be136-fe91-
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="http://schemas.xmlsoap.org/soap/actor/next"
actor="http://schemas.xmlsoap.org/soap/actor/next">
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. ECP to IdP Authn request
<SOAP-ENV:Envelope xmlns:SOAP-
ENV="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:SOAP-
ENV="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

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

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

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
21

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>
<EncryptedData Limit='5,000' Currency='USD'>
<CreditCard 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

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