SAML 2.0 is an OASIS standard for exchanging authentication and authorization data between online services. It defines XML frameworks to securely share this information. The document discusses SAML's security components and profiles, analyzing how they work and potential vulnerabilities like CSRF, replay, and man-in-the-middle attacks if not using secure communication or PKI. It outlines the IdP-initiated and SP-initiated flows of the Web Browser SSO profile to illustrate normal SAML usage and points where security could be compromised without additional protections.

1. Introducing SAML 2.0 protocol:
Security and Performance
M. Amin Saghizadeh
JUL 2015

2. 1) Introduction
In this document we review the security and performance of the Security Assertion Markup Language
(SAML) 2.0 protocol. SAML is an OASIS [1] standard and defines a framework for exchanging security
information between online business partners. It defines a common XML framework for exchanging
security assertions between entities to define, enhance, and maintain a standard XML-based framework
for creating and exchanging authentication and authorization information [2].
After a brief introduction about the protocol and its flow in section 2, we review some security aspects
of the protocol in section 3 and see how secure is it against common attacks on authentication
protocols. Reviewing performance of the protocol and some considerations about high availability is in
section 4. We then conclude this document in section 5.
2) Introducing SAML 2.0 protocol
SAML is different from other security systems due to its approach of expressing assertions about a
subject that other applications within a network can trust. There are several drivers behind the creation
of the SAML standard [2]:
Limitations of Browser cookies. Most existing Single-Sign On products use browser cookies to
maintain state so that re-authentication is not required. Browser cookies are not transferred
between DNS domains. So, if you obtain a cookie from www.abc.com, then that cookie will not
be sent in any HTTP messages to www.xyz.com. This could even apply within an organization
that has separate DNS domains. Therefore, to solve the Cross-Domain SSO (CDSSO) problem
requires the application of different technology.
SSO Interoperability. How products implement SSO and CDSSO are completely proprietary. If
you are an organization and you want to perform SSO across different DNS domains within the
same organization or you want to perform CDSSO to trading partners, then you will have to use
the same SSO product in all the domains.
Web Services. Security within Web Services is still being defined. Most of the focus has been on
how to provide confidentiality and authentication/integrity services on an end-to-end basis. The
SAML standard provides the means by which authentication and authorization assertions can
exchanged between communicating parties.
Federation. The need to simplify identity management across organizational boundaries,
allowing users to consolidate many local identities into a single (or at least a reduced set)
Federated Identity.
There are two high-level use cases of the SAML standard. We now take a brief look at each of them.
Single-Sign-On Use case. This use case illustrates the support for Cross Domain Single Sign-On. A user
has a logon session (that is a security context) on a website (AirlineInc.com) and is accessing resources
on that site. At some either explicitly or transparently he is directed over to another web site (in a
different DNS domain). The Identity Provider site (AirlineInc.com) asserts to the Service Provider site
(CarRentalInc.com) that the user is known to it and provides the user's name and session attributes (e.g.

3. gold member). As CarRentalInc.com trusts AirlineInc.com it knows that the user is valid and creates a
session for the user based on the user's name and/or the user attributes. This use case illustrates the
fact that the user is not required to re-authenticate when directed over to the CarRentalInc.com site.
Figure (1) shows the SSO high-level use case.
Figure 1 – SSO high-level use case
Federation Use Case. This use case illustrates the “account linking” facet of federation [3]. Figure 2
illustrates one possible scenario. Two Service Providers exist, one for car rentals the other for hotel
bookings. The same user is registered on both sites, however using different names. On
CarRentalInc.com he is registered as JDOE and on HotelBookings.com as JOHND. Account Linking
enables a pseudonym to be established that links the two accounts.
Figure 2 – Federation high-level use case

4. 2-1) Base Definitions
Before we proceed any further, we should take a look at some definitions and conventions used in the
rest of the document [2]. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as
described in RFC 2119 [4], too.
Identity Provider (IdP). The system or administrative domain that asserts information about a subject.
For instance, the identity provider asserts that this user has been authenticated and has given
associated attributes. In SAML, Identity Providers are also known as SAML Authorities and Asserting
Parties.
Service Provider (SP). The system or administrative domain that relies on information supplied to it by
the identity provider. It is up to the service provider as to whether it trusts the assertions provided to it.
Service providers are also known as Relying Parties.
Assertion. Assertions carry statements about a principal as asserted by an Asserting Party and are
defined by an XML Schema.

5. SAML protocol. SAML Protocols define how and which assertions are requested and they also have their
own XML schema.
Binding. Bindings define the lower-level communication or messaging protocols (such as HTTP or SOAP)
that the SAML Protocols can be transported over them.
Profile. SAML Protocols, Bindings and Assertions can be combined together to create a Profile. In
general, profiles are a set of rules and concepts satisfying a particular use case.
SSO. SSO refers to Single Sign On.
SLO. SLO refers to Single Logout.
The official SAML 2.0 Glossary is available in [5] which defines all concepts used in all other SAML
documents.
2-2) SAML Components
SAML consists of a number of building-block components that, when put together, allow a number of
use cases to be supported. Primarily the components permit transfer of identity, authentication, and
authorization information to be exchanged between autonomous organizations. This section describes
The SAML components and their individual parts. Detailed information about the individual parts can be
found in [2] and [6].
Assertion. SAML allows for one party to assert characteristics and attributes of an entity. For instance, a
SAML assertion could state that the user is “John Doe”, the user has “Gold” status, the user’s email
address is john.doe@example.com, and the user is a member of the “engineering” group. SAML
assertions are encoded in a XML schema. SAML defines three kinds of statements that can be carried
within an assertion: Authentication Statement, Attribute Statement and Authorization Decision
Statements. Technical details about assertions can be found in [6].
SAML protocol. SAML defines a number of request/response protocols. The protocols defined are
Assertion Query and Request Protocol, Authentication Request Protocol, Artifact Protocol, Name
Identifier Management Protocol, Single Logout Protocol and Name Identifier Mapping Protocol.
Technical details about protocols can also be found in [6].
Binding. It details exactly how the SAML protocol maps onto the transport protocols. For instance, the
SAML specification provides a binding of how SAML request/responses are carried with SOAP exchange
messages. The bindings defined are SAML SOAP, Reverse SOAP (PAOS), HTTP Redirect, HTTP Post, HTTP
Artifact and SAML URI Binding. More information and details about bindings are available in [7]
Profile. Profiles define how the SAML assertions, protocols and bindings are combined. The profiles
defined are Web Browser SSO, Enhanced Client and Proxy (ECP), Identity Provider Discovery, Single
Logout, Name Identifier Management, Artifact Resolution, Assertion Query/Request and Name Identifier
Mapping Profile. A comprehensive definition of each profile can be found in [8]
Figure (3) illustrates the relationship between the SAML components.
Figure 3 – Relationship between SAML components

6. Some real examples of implementation of the components and their structures can be find in [2].
2-3) SAML Profiles
This section is about how the protocol actually works. SAML supports a number of use cases and
profiles. Each use case with combination of a binding within a profile can be thought as a protocol flow.
In this section we describe two use cases of Web Browser SSO profile and analyze them in the rest of this
document. More information about all SAML profiles and their use cases can be found in [8].
2-3-1) Base Definitions
Web Browser SSO profile supports some different types of model, based on how the message flows are
initiated (IdP or SP initiated), and which SAML bindings will be used when sending messages back and
forth between the IdP and SP. We discuss about two of them in this document. Figure (4) illustrates IdP
and SP Initiated approaches.

7. IdP Initiated. In this approach the user is accessing resources on the Identity Provider, and wishes to
access resources on another web site (the Service Provider). The user already has a current security
context with the Identity Provider. A SAML Assertion is provided to the Service Provider.
SP Initiated. Here, the user is accessing resources on the Service Provider and attempts to access a
protected resource requiring knowledge of their authentication and authorization attributes. The Service
Provider directs the request to their Identity Provider so that it may provide back SAML Assertion(s) in
order to validate whether they have access rights to the resource.
Figure 4 – IdP and SP Initiated approaches
Now we present the above mentioned protocol flows (use cases).
2-3-2) SP initiated: Redirect/POST binding
In this use case the user attempts to access a resource on the SP, sp.example.com. However it do not
have a current logon session on this site and its federated identity is managed by the IdP,
idp.example.org. The user is sent to the IdP to log on and the IdP provides a SAML web SSO Assertion for
the user's federated identity back to the SP. Figure (5) illustrates this flow.
Figure 5 – SP initiated Redirect/POST binding

8. The flow is as the following:
1. The user attempts to access a resource on sp.example.com. The user does not have a valid
logon session (i.e. security context) on this site. The SP saves the requested resource URL in local
state information that can be saved across the web SSO exchange.
2. The SP sends an HTTP redirect response to the browser (HTTP status 302 or 303). The
Location HTTP header contains the destination URI of the Sign-On Service at the identity
provider together with an <AuthnRequest> message encoded as a URL query variable named
SAMLRequest.
3. The Single Sign-On Service determines whether the user has an existing logon security context
at the identity provider that meets the default or requested (in the <AuthnRequest>)
authentication policy requirements. If not, the IdP interacts with the browser to challenge the
user to provide valid credentials.
4. The user provides valid credentials and a local logon security context is created for the user at
the IdP.

9. 5. The IdP Single Sign-On Service builds a SAML assertion representing the user's logon security
context. Since a POST binding is going to be used, the assertion is digitally signed and then
placed within a SAML <Response> message. The <Response> message is then placed within an
HTML FORM as a hidden form control named SAMLResponse. If the IdP received a RelayState
value from the SP, it must return it unmodified to the SP in a hidden form control named
RelayState. The Single Sign-On Service sends the HTML form back to the browser in the HTTP
response. For ease of use purposes, the HTML FORM typically will be accompanied by script
code that will automatically post the form to the destination site.
6. The browser, due either to a user action or execution of an “auto-submit” script, issues an
HTTP POST request to send the form to the SP's Assertion Consumer Service.
7. An access check is made to establish whether the user has the correct authorization to access
the resource. If the access check passes, the resource is then returned to the browser.
2-3-3) IdP initiated: POST binding
In this use case the identity provider is configured with specialized links that refer to the desired service
providers. These links actually refer to the local IdP's Single Sign-On Service and pass parameters to the
service identifying the remote SP. So instead of visiting the SP directly, the user accesses the IdP site and
clicks on one of the links to gain access to the remote SP. This triggers the creation of a SAML assertion
that will be transported to the service provider using the HTTP POST binding. Figure (6) shows this flow.
Figure 6 – IdP initiated: POST binding

10. The flow is as the following:
1. If the user does not have a valid local security context at the IdP, at some point the user will
be challenged to supply their credentials to the IdP site, idp.example.org.
2. The user provides valid credentials and a local logon security context is created for the user at
the IdP.
3. The user selects a menu option or link on the IdP to request access to an SP web site,
sp.example.com. This causes the IdP's Single Sign-On Service to be called.
4. The Single Sign-On Service builds a SAML assertion representing the user's logon security
context. Since a POST binding is going to be used, the assertion is digitally signed before it is
placed within a SAML <Response> message. The <Response> message is then placed within an
HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a
specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP
is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On
Service sends the HTML form back to the browser in the HTTP response. For ease-of-use

11. purposes, the HTML FORM typically will contain script code that will automatically post the form
to the destination site.
5. The browser, due either to a user action or execution of an “auto-submit” script, issues an
HTTP POST request to send the form to the SP's Assertion Consumer Service. The service
provider's Assertion Consumer Service obtains the <Response> message from the HTML FORM
for processing. The digital signature on the SAML assertion must first be validated and then the
assertion contents are processed in order to create a local logon security context for the user at
the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the
desired application resource URL and sends an HTTP redirect response to the browser directing
it to access the requested resource (not shown).
6. An access check is made to establish whether the user has the correct authorization to access
the resource. If the access check passes, the resource is then returned to the browser.
3) Security Analysis
In this section we review security of the mentioned flows. This protocol brings no security by itself and
highly relies on secure communications (SSL or TLS) or some pre-existed trust relationship which also
typically relies on PKI or asymmetric cryptography. We discuss about possible attacks in absence of
secure communication or PKI. A comprehensive official security and privacy consideration document is
available in [9].
3-1) Compromising with CSRF Attack
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a
web application in which they're currently authenticated [10]. CSRF attacks specifically target state-
changing requests, not theft of data, since the attacker has no way to see the response to the forged
request. In other words, CSRF attack is useful when the authenticated user can perform actions which
change the state of the system (i.e. Insert, Update and Delete), so this attack alone is not suitable when
the user just retrieves some protected data. A real example of CSRF attacks is available in [11].
As all SML Assertions are delivered by HTTP headers, cookies or query strings in URLs, attacker can
simply perform a CSRF attack trying to change the system state in account of the authenticated user.
From the other side, without the pre-existing trust, the Service Provider has no idea which the forged
request is legal or malicious request and simply accepts it. Enabling pre-existed trust alone also is not
enough to protect against CSRF attack since the protocol has not a solution to recognize the real origin
of the request.
3-2) Compromising with Replay Attack
A replay attack occurs when an attacker copies a stream of messages between two parties and replays
the stream to one or more of the parties [12]. Unless mitigated, the computers subject to the attack
process the stream as legitimate messages, resulting in a range of unwanted consequences, such as
authenticating or recognizing the attacker as an authenticated user.
By eavesdropping SAML Assertions, the attacker can perform replay attacks to impersonate the
authenticated user and perform whatever the user can do. The protocol itself does not have a solution
(usually a hashed or encrypted time stamp) to mitigate replay attacks.

12. 3-3) Compromising with MITM Attack
The man-in-the middle (MITM) attack intercepts a communication between two systems [13]. For
example, in an http transaction the target is the TCP connection between client and server. Using
different techniques, the attacker splits the original TCP connection into 2 new connections, one
between the client and the attacker and the other between the attacker and the server. Once the TCP
connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in
the intercepted communication.
By performing a MITM attack, the attacker can intercept the protected data and deliver incorrect data
or nothing to the client. It can impersonate the Identity Provider and collect Assertions of all user to
perform replay attacks in the future. The attacker also is able to impersonate the Service Provider and
spread malicious data instead of the protected data requested by users.
4) Performance Analysis
In this section we analyze performance of the above mentioned flows. We concentrate on the
performance of the communication and skip the computational and storage performance analysis of the
protocol. We also define each pair of Request – Response sent and received from/to an entity (user or
every provider) as an Interaction.
4-1) Performance of SP Initiated flow
In this flow, there are four interaction when the user is not authenticated (does not have an Assertion
yet). Two of them are between the client and the Service Provider, and the other two are between the
client and the Identity Provider. So, half of the network load is on the client, 25% on the SP and the other
25% is on the IdP. As a result, from the provider point of view, this flow is a high performance and fair
protocol and none of the providers becomes bottleneck of the system.
Therefore, if the communication pattern of the system is accessing a protected resource just once, then
in large scales of this pattern the bandwidth efficiency will be at least about 1/4 or 25%. This is because
that there are totally four interactions in a flow which one them is used to do the useful work (retrieving
protected resource). This situation can occur when there are many clients that want to access some
resources just once, or logout quickly.
However, if the traffic pattern of the system is accessing same resources, then most of users submit
their assertions with requests and don’t impose any other interaction to channel as there but the one to
retrieve requested resources. So, it can dramatically increase the bandwidth efficiency. In this situation,
the bandwidth is highly dependent on the amount of data supposed to be retrieved and the length of
the assertion. Therefore, if the requested data is very larger than the length of the assertion, the
bandwidth efficiency goes very high and SAML is really a high performance protocol in this situation.
4-2) Performance of IdP Initiated flow
In this flow, there are three interaction when the user is not authenticated (does not have a security
context with the IdP). Two of them are between the client and the Identity Provider, and the other one is
between the client and the Service Provider. So, half of the network load is on the client, about 16.67%
on the SP and about 33.33% is on the IdP. As a result, from the SP point of view, this flow is a high
performance and in IdP opinion, it’s not a so heavy load. So, none of the providers becomes bottleneck
of the system.
From the other hand, there are two interactions in this flow when the user has a security context with
the IdP. One of them are between the client and the IdP, and the other one is between the client and

13. the SP. So, half of the network load is on the client, 25% on the IdP and the other 25% is on the SP. As a
result, from the provider point of view, in this situation the protocol act as a high performance and fair
protocol and none of the providers becomes bottleneck of the system.
Therefore, if the communication pattern of the system is accessing a protected resource just once, then
in large scales of this pattern the bandwidth efficiency will be at least about 1/3 or 33%. This is because
that there are totally three interactions in a flow which one them is used to do the useful work
(retrieving protected resource).
However, if the traffic pattern of the system is accessing same resources, then most of users have a
security context with the IdP and perform two interactions to retrieve the protected resources. The
bandwidth also is dependent on the amount of data supposed to be. Therefore, if the requested data is
very larger than the length of the other interaction, the bandwidth efficiency can go very high and SAML
can be a high performance protocol in this situation, too.
5) Conclusion
In this document we first introduced the SAML 2.0 protocol. SAML is an OASIS standard for exchanging
authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol
that uses security tokens containing assertions to pass information about a principal (usually an end
user) between a SAML authority, that is, an identity provider, and a SAML consumer, that is, a service
provider.
Then we discussed about the security matters. Security of the SAML 2.0 protocol highly relies on secure
communications (SSL, TLS). If the communication goes through HTTP, the attacker can eavesdrop the
assertions and perform impersonation attacks. It also can perform information disclosure and even
MITM attacks and deliver wrong resources to the client.
We also analyzed the performance of the protocol in two of the most used flows, each of which in two
traffic patterns. We saw that the SP initiated flow has more performance in authenticated traffic pattern
and the IdP initiated flow has more performance in unauthenticated traffic pattern.
6) References
[1] OASIS | Advancing open standards for the information society. 2015. OASIS | Advancing open
standards for the information society. [ONLINE] Available at: https://www.oasis-open.org/.
[Accessed 03 July 2015].
[2] SAML Technical Overview | SAML XML.org. 2005. SAML Technical Overview | SAML XML.org.
[ONLINE] Available at: http://saml.xml.org/saml-technical-overview. [Accessed 03 July 2015].
[3] Federated identity - Wikipedia, the free encyclopedia. 2015. Federated identity - Wikipedia, the
free encyclopedia. [ONLINE] Available at: https://en.wikipedia.org/wiki/Federated_identity.
[Accessed 03 July 2015].
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, [ONLINE] Available at: http://www.rfc-editor.org/info/rfc2119.
[Accessed 03 July 2015].

14. [5] Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0| SAML XML.org.
2005. Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML XML.org.
[ONLINE] Available at: https://www.oasis-open.org/committees/download.php/21111/saml-
glossary-2.0-os.html. [Accessed 03 July 2015].
[6] Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML
XML.org. 2005. Assertions and Protocols for the OASIS Security Assertion Markup Language
(SAML) V2.0 | SAML XML.org. [ONLINE] Available at: http://docs.oasis-
open.org/security/saml/v2.0/saml-core-2.0-os.pdf. [Accessed 03 July 2015].
[7] Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML XML.org.
2005. Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML XML.org.
[ONLINE] Available at: http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf.
[Accessed 03 July 2015].
[8] Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML XML.org.
2005. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML XML.org.
[ONLINE] Available at: http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf.
[Accessed 03 July 2015].
[9] Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML)
V2.0 | SAML XML.org. 2005. Security and Privacy Considerations for the OASIS Security Assertion
Markup Language (SAML) V2.0 | SAML XML.org. [ONLINE] Available at: http://docs.oasis-
open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf. [Accessed 03 July 2015].
[10]Cross-Site Request Forgery (CSRF) - OWASP. 2015. Cross-Site Request Forgery (CSRF) - OWASP.
[ONLINE] Available at:https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF).
[Accessed 07 July 2015].
[11]Introducing CSRF Attacks. 2015. Introducing CSRF Attacks. [ONLINE] Available at:
http://www.aparat.com/v/TOwmh/. [Accessed 07 July 2015].
[12]Replay Attacks - Microsoft. 2015. Replay Attacks - Microsoft. [ONLINE] Available at:
https://msdn.microsoft.com/en-us/library/aa738652(v=vs.110).aspx. [Accessed 07 July 2015].
[13]Man-in-the-middle attack - OWASP. 2015. Man-in-the-middle attack - OWASP. [ONLINE]
Available at: https://www.owasp.org/index.php/Man-in-the-middle_attack. [Accessed 07 July
2015].