SAML (Security Assertion Markup Language) is an XML-based standard that allows identity providers to pass authentication and authorization data about a user to a service provider. It enables single sign-on access across different domains. SAML works by having an identity provider authenticate a user and issue a signed assertion about the user to the service provider. The service provider can then grant access to its resources based on the information in the assertion without requiring separate authentication. The key components of SAML include assertions, protocols, bindings, and profiles that define how identity and attribute information is exchanged securely between identity and service providers. SAML addresses important issues like federated identity, security, and portability.

1. WHITEPAPER
What | Why | How
SAML 101

2. Security Assertion Markup Language (SAML) 101
CONTENTS
Introduction
What is SAML?
The Use Cases
The Advantages
The Components
The Security
Echoworx Supports SAML
3
4
5
7
6
8
9

3. INTRODUCTION
SAML: The Building Blocks of Federated Identity
Today, enterprise employees use a vast number of
applications. These applications can be domestic in-house
hosted applications or external partner/vendor cloud web
applications. Seemingly, the use of the latter is growing day
by day.
Security access to the in-house hosted application is
straightforward since all users and application are in the
same security domain, a central Identity Management
system (IdM), that can identify and authenticate users. You
just type your password and login. However, access to the
external Software as a Service (SaaS) applications, such as
a cloud-cased encryption solution, is more challenging.
Since these SaaS applications do not have access to the
organization’s IdM system, they need to maintain their
own user credentials.
As the number of external SaaS applications grows,
memorizing different user ids and passwords for different
applications becomes the main risk of security breaches
as the user often chooses the same password for multiple
applications. It isn’t the user’s fault.
The answer is Identity Federation; It solves these
challenges by using standard-based policies and protocols
to manage and enforce users’ access to cross domains
applications. It enables business partners to allow secure
access to internal resources without having to assume the
burden of maintaining users’ credentials that belong to
their business partners.
Keys to successful implementation of identity federation
are standardized mechanisms, and formats for the
communication of identity information between the
domains – The Security Assertion Markup Language (SAML)
defines just such a standard.
3
Author: Paul Jong, Application Architect at Echoworx
This whitepaper sets out to explain what SAML is, how it
works and why it’s important. In addition, it looks at some
of the most common business use case scenarios.

4. WHAT IS SAML?
Security Assertion Markup Language (SAML), developed by the Security Services Technical Committee of the Organization
for the Advancement of Structured Information Standards (OASIS), is a secure XML-based communication mechanism for
asserting identities between organizations. It provides the ability to send information about an authenticated user and does
not require a third-party system to have access to the user’s credentials.
SAML version 2.0 was approved as an OASIS Standard in March 2005. Since then, the latest approved modifications (errata)
were released in May 2012.
PRIMARY USE CASE
The primary use case for SAML is Web Single Sign-On. There are three entities involved.
1. The User | client attempting to access an application.
2. The Organization that maintains directories of users and authentication mechanism – Identity Provider (IdP) and
is sometimes referred to as the SAML asserting party.
3. The Organization that hosts the target application or service. Service Provider (SP) and is sometimes referred to
as the SAML relying party.
These three entities are related.
• The user has an account at the IdP. (e.g. IdP is an employer and the user is an employee)
• The user wants to use the SaaS application hosted by the SP.
• The IdP and the SP are related because they want to federate identities. (e.g. customer supplier; customer vendor)
Security Assertion Markup Language (SAML) 101
4

5. 5
User attempts to access the application.
Federated software running at the IdP kicks into actions and it validates the user
identity and that the user is correctly authenticated. It then constructs a specially
formatted message containing information about that user which it then communicates
to the federated software running at the SP.
The software then determines if the message has come from a known IdP. If so, it
creates a session for that specific user, for the target application, granting the user
direct access to the application.
This entire process (SAML message creation, redirection, session creation) is completely
transparent to the users.
USER ACCESS
REQUEST
VALIDATION
SESSION
CREATION
HOW SAML WORKS

6. • Eliminates the need to maintain multiple credentials in
multiple locations.
• Reduces phishing opportunities by limiting the number of
times users have to login using online forms.
• Reduces the opportunity for identity theft by eliminating
the need for multiple credentials.
• Increases application access by removing usage barrier.
Users can simply click on a link to login, and there’s no
need to type passwords.
• Increases efficiency and reduces costs of administration
by eliminating help desk calls to recover, reset passwords
and efforts to remove duplicate credentials;
• It is a standard. SAML provides a set of interoperable
standard interfaces. The same software at the IdP can be
used to connect to a different SP and vice versa.
Standardizing the interfaces allows for faster, cheaper,
and more reliable integration.
• Eliminates questionable security as well as the
unquestionable administration and development cost
for a proprietary SSO solution.
• Enhances user experience - users are happy since they
get direct access to the application without the hassle of
remembering multiple passwords.
THE ADVANTAGES OF SAML
6
Security Assertion Markup Language (SAML) 101

7. THE COMPONENTS OF SAML
SAML is defined in terms of Assertions, Protocols, Bindings, and Profiles.
Assertions
Is a package of information that supplies one or more statements made by a SAML authority about the User. These
assertions are generated from the Identity Provider and are consumed by the Service Provider. These statements allow the
Service Provider to make access control decisions about the previously authenticated User.
SAML defines three kind of assertions statements that can be created by a SAML authority. They are Authentication,
Attribute and Authorization decision.
1. Authentication Assertions
These assertions let the Service Provider knows that the specified subject was authenticated by a particular means
at a particular time. This kind of statement is typically generated by an identity provider, which is in charge of au-
thenticating users and keeping track of other information about them.
2. Attribute Assertions
These assertions inform the Service Provider that the user has specific identifying attributes.
3. Authorization Decision Assertions
These assertions tell the service provider what resource a User is entitled to access based on certain evidence.
Explanation of Assertion
We will use a real life example to help explain the assertion concept – golfer with a private clubs membership.
The golfer in this case is the User, the golf courses within the club are the Service Providers, the club’s main office is the
Identity Provider and the membership card is the SAML token.
When the club member plays at the club golf course, he/she has to show the membership card to the clubhouse staff. The
staff verifies the membership is legit, (similar to the process of verifying digital signature of the SAML token). Once the
membership identity is verified, the golf course uses the information associated with the membership to determine if the
golfer can play at this particular course or not. In addition the “authentication assertion” would indicate when the golfer
paid their membership fee and that their identity was proven during the initial membership registration process.
The “attribute assertion statement” would include the birthdate, picture, sex and other identifying attributes associated to
the golfer. And the “authorization decision statement” would indicate if and when the golfer is able to use the locker facility
and the dining facility.
7

8. Protocols
SAML defines a number of generalized request/response protocols. Protocol defines how SAML asks for and receives
assertions. E.g. assertions are created by the Identity Provider in response to a request made by the Service Provider.
There are six defined SAML protocols and they enable Service Providers to take a variety of actions. One such protocol
is authentication request protocol.
Authentication Request Protocol
The Web Browser SSO Profile uses this protocol when redirecting a user from an SP to an IdP when it needs to
obtain an assertion in order to establish a security context for the user at the SP.
Bindings
Mappings from SAML request-response message exchanges into standard messaging or communication protocols are
called SAML protocol bindings. It determines how the SAML protocol messages are transported. Typically, SAML protocols
messages are carried over SOAP or HTTP. One of the most common binding is HTTP Redirect/POST binding.
1. HTTP Redirect Binding
Defines how SAML messages can be transported using the HTTP redirection (302)..
2. HTTP Post Binding
Defines how SAML messages can be transported within the base64-encoded content of an HTML form.
Profiles
SAML profiles describe how to use the different SAML request/response protocols together with different combinations of
SAML bindings to solve specific business use cases. One of the most used SAML profiles is the Web Browser SSO Profile.
Web Browser SSO Profile
This profile describes how SAML authentication assertions are communicated via different bindings
(e.g. HTTP Redirect, HTTP POST) to enable the web single sign-on use case.
This profile has different options depending on whether the flow is initiated by the Identity Provider or the Service
Provider and which bindings are used to send messages between the Identity Provider and the Service Provider.
There are two SAML messages involved in this profile; Authentication Request message sent from Service Provider
to Identity Provider, and a Response message containing a SAML assertion that is sent from Identity Provider to
Service Provider.
SP-Initiated SSO Profile
The most common scenario for starting a web SSO exchange is the SP-initiated web SSO model. In this scenario,
user accesses a resource at a Service Provider. Since the user is not logged in at the Service Provider, before it
allows access, the Service Provider sends (redirect) the user to an Identity Provider to authenticate. The Identity
provider produces an authentication assertion. The Service provider then consumes the assertion and determines
whether the access is allowed or not.
8
Security Assertion Markup Language (SAML) 101
THE COMPONENTS OF SAML cont.

9. This use case is described as follows:
1. The user tries to access a resource on sample.sp.com
(SP). This user has not logged in before on this site.
The SP remembers the original resource requested
URL.
2. The SP sends an HTTP 302 or 303 redirect response
to the browser with a SAML AuthnRequest. The
browser processes the redirect response and issues
an HTTP GET request to the IdP’s Single Sign-On
Service (idp.example.org) with the SAML
AuthnRequest.
3. The Single Sign-On Service determines whether if
the user has sign in before. If not, the IdP interacts
with the browser to challenge the user to provide
login credentials.
4. The user authenticates to IdP.
5. The IdP Single Sign-On Service creates a SAML
Response Assertion containing the user’s
authentication context. This response is digitally
signed and the Response message is sent back to
the browser via HTTP POST. For ease of use
purposes, the HTML FORM typically will be
accompanied by script code that will automatically
post the form back to the Service Provider site.
6. The browser issues an HTTP POST request to send
the form to the SP’s Assertion Consumer Service.
After the digital signature is verified, the assertion
contents are processed. If successful, the SP will
redirect the browser to the originally requested
resource (remembered from step 1) .
7. The requested resource is returned to the browser
if the user is authorized to access it.
SP-INITIATED SSO: REDIRECT/POST BINDINGS
9

10. SECURITY IN SAML
10
Security Assertion Markup Language (SAML) 101
Communication of assertions between Identity Provider and Service Provider are secured using digital signatures and
encryption.
Use of TLS is recommended to enforce in transit confidentiality and data integrity. XML Encryption and XML Signature
provide the ability to enforce confidentiality and data integrity at the message level.
PKI is recommended to set up a trust relationship between Service Provider and Identity Provider.
In addition to using TLS, digital signatures, and encryption for transport level and message level protection, SAML
provides additional countermeasure protection from various other attacks.
The following are some examples.
• The Identity Provider and Service
Provider should try to synchronize
their clocks as close as possible.
• Assertions attributes like “NotBefore”
and “NotOnOrAfter” should have the
shortest possible validity period
to ensure that stolen assertion can only
be used successfully within a
small-time window.
• “One-use” assertion attribute can be
used to counter Replay attack.

11. ABOUT US
About us
Since 2000, Echoworx has been bringing simplicity and flexibility to encryption. Headquartered in North America and
with offices in the UK, our certified, redundant and replicated data centres are located in the US, UK and Canada. Our
passionate encryption experts transform chaos into order for world leading enterprises and OEM providers who
understand the requirement for secure communication is of the upmost importance. We are proud to have clients in
30 countries worldwide, with more than 5,000 enterprise-level deployments.
Encryption is an investment in brand, maximizing competitive advantage.
Echoworx’s flagship solution, OneWorld Enterprise Encryption, provides an adaptive, fully flexible approach to encryption
that ensures the privacy of sensitive messages. We leverage industry standard protocols like Security Assertion
Markup Language (SAML) and OAuth for full support of Single Sign On (SSO). Enterprises investing in Echoworx’s
OneWorld platform, are driving encryption adoption, creating seamless customer experiences, and in turn earning their
loyalty and trust.

12. For more information www.echoworx.com
info@echoworx.com
NorthAmerica 1 800.346.4193 | UK 44 0.800.368.5334
@Echoworx