SAML proposal for securing XML web services
Jayesh Naithani
University of St. Thomas, Saint Paul, MN
jnaithani@gmail.com
Abstract
The Security Assertion Markup Language (SAML)
standard defines an XML-based framework for describing
and exchanging security information between trusting
parties. It provides interoperability in a distributed
environment between disparate security systems. This
paper will describe how SAML can provide a means for
communicating authentication, data integrity, and
message confidentially information across web services
using the XML based SOAP protocol. The paper will first
describe the fundamentals of the SAML protocol, then
review in greater detail the OASIS proposal for securing
XML based web service message exchanges using the
SAML 2.0 standard, and conclude with a general analysis
of some of the threats and security risks affecting the
SAML proposal from the perspective of secure web service
message exchanges.
1. Introduction
Today, more and more systems are linked through Web
services, portals, and integrated applications. The need for a
standard that allows security information to be shared and
exchanged has never been felt more necessary. The Security
Assertion Markup Language, or SAML, protocol provides a
flexible and extensible set of data formats designed for
communicating user authentication, entitlement, and attribute
information between disparate services in a dynamic,
distributed, networked environment [7].
The SAML standard is being applied in a number of
different ways today, the major ones being for Web single
sign-on (SSO), attribute-based authorization, and the
securing of web services. In web based single sign-on (SSO)
a user authenticates to one web site and without additional
authentication is able to access personalized and customized
information at other sites. This is accomplished by SAML
through the communication of an authentication assertion
between sites. Each site validates the assertion and allows or
denies access based on the result. With attribute-based
authorization, identity information about a user or subject is
communicated between web sites to support the completion
of a transaction. The identity information is a property of the
user, and is in addition to their authentication related
information. Partner services establish an agreement on how
1
to refer to the user, and the user is then said to have a
federated identity [7]. Finally, SAML allows for the use of
the assertion format in securing web service Simple Object
Access Protocol (SOAP) message exchanges. SAML
provides a standards-based approach for the exchange of
user information, using security tokens, which is not possible
as easily by other WS-Security token profiles.
In this paper I will begin with a brief introduction about
SAML history and core concepts. I will then focus in greater
detail on the OASIS Web Services Security SAML Token
Profile standard for securing web service message
exchanges. I will conclude the paper by reviewing some
security considerations for the use of the SAML proposal.
2. SAML History
The Organization for the Advancement of Structured
Information Standards (OASIS) developed the SAML
V1.0 standard in November 2002. SAML V1.1 followed
in September 2003. In March 2005, SAML V2.0 was
announced, and is intended to be the convergence point
for the three major identity federation initiatives that
came into existence after the release of V1.0, namely, the
Liberty Alliance, the Internet2 Shibboleth project, and
the OASIS Web Services Security (WS-Security)
committee. SAML V2.0 is considered by all to be an
important step towards full convergence for federated
identity standards [7].
3. Conceptual introduction
System entities use the SAML protocols for
constructing and exchanging security assertions. An
asserting entity can use SAML to make the following
statement:
"Alice has these profile attributes and her domain's
certificate is available over here, and I'm making this
statement, and here's who I am." [1]
The assertion is then conveyed to some other party
who can then trust it and provide access to secured
resources.
The specification of how SAML is used in a particular
context is knows as a "SAML Profile". The specification
of how SAML assertions are conveyed over another
protocol is known as a "SAML Binding". SAML
profiles and bindings reference other SAML
specifications such as the "SAML Core" specification.
These concepts are briefly discussed next.
4. SAML Concepts and Architecture
The SAML protocol consists of assertions, protocols,
bindings, and profiles [see Figure 2].
4.1 Assertions
An assertion contains one or more statements made by a
SAML authority about a subject which it considers to be true
or valid. Assertions are created by an asserting party, also
known as the identity provider (IdP), and based on a request
by a relying party, also known as the service provider (SP)
[2, 5].
There are three different kinds of assertion statements:
 Authentication: indicate that a subject was
authenticated using a particular method at a
specific time. This type of statement is typically
generated by a SAML authority or identity
provider.
 Attribute: contain properties about the subject,
such as group and role information.
 Authorization decision: define something that
a subject is entitled to do.
The diagram below shows the high-level structure of a
typical SAML authentication assertion.
Issuer
Signature
Subject
=
Conditions
AuthnStatement
Figure 1. SAML Assertion [5]
2
4.2 Protocols
SAML defines a set of request and response messages
XML that are used by service providers to obtain
assertions [2, 5].
The request/response protocols are:
 Assertion Query and Request Protocol:
request one or more assertions from a SAML
authority
 Authentication Request Protocol: request
an identity provider authenticate a principal
 Single Logout Protocol: request a near-
simultaneous logout of a collection of related
sessions
 Artifact resolution protocol: retrieve a
protocol message by means of an identifier
called an artifact
 Name Identifier Mapping and Manage
Protocols: permits the programmatic
mapping, and termination, of SAML name
identifiers for a user between one or more
service providers
4.3 Bindings
Bindings describe how SAML protocol messages are
carried over transport protocols from an identity provider
to a service provider, and vice versa [5].
Some of the following bindings are defined by the
protocol:
 HTTP Redirect/Post Bindings: defines
how protocol messages can be transported
using HTTP redirect messages, or via Base64
encoded content of an HTML form control
 HTTP Artifact binding: defines how
artifacts are transported between message
senders and receivers using HTTP.
 SAML SOAP Binding: defines how SAML
protocol messages are transported within
SOAP messages
 Reverse SOAP (PAOS) Binding: for
devices like cell phone that cannot accept a
request but can send one (reverse SOAP)
 SAML URI Binding: defines a method to
retrieve existing SAML assertions by
resolving a URI (Uniform Resource
Identifier)
4.4 Profiles
Profiles consist of SAML assertions, protocols, and
bindings, constrained to provide interoperability
depending on usage scenarios.
 There are a number of profiles defined by SAML, and
the following are a few of the profiles defined by V2.0
[3]:
 Web Browser SSO Profile: defines how
SAML entities can use the Authentication
Request Protocol and SAML response
messages to achieve Web browser based
single sign-on
 Single Logout Profile: defines how the
Single Logout Protocol can be used with
SOAP, HTTP Redirect/POST/Artifact
bindings
 Assertion Query/Request Profile: defines
how SAML can use the SAML Query and
Request Protocol to obtain SAML assertions
using SOAP messages
 Artifact Resolution Protocol: defines how
SAML entities can use the Artifact
Resolution Protocol to get protocol messages
referred by artifacts using the SOAP binding
4.5 Metadata and Authentication Context
Two other SAML concepts are useful for
understanding a SAML environment [5]:
 Metadata: defines a way to express and
share configuration information between
SAML parties, such as the identify provider
and service provider. Information consists of
identifier information, operation roles, key
information for encryption and signing.
 Authentication Context: this is referenced
by an assertion's authentication statement to
carry detailed information regarding the type
and strength of authentication requested, such
as multi-factor authentication
SAML is highly extensible and can be further
customized to create additional bindings and profiles and
ensure maximum interoperability.
Having described the general concepts of the SAML
standard, the paper will next review the details of the
SAML proposal for protecting web service message
exchanges as defined by the OASIS SAML Token
Profile V2.0.
3
Profiles
Contains assertions, protocols, bindings
to support defined use cases
Bindings
Protocol mappings onto standard
messaging and communication protocols
Protocols
Requests and responses for assertions
and for managing identities
Assertions
Authentication, attribute, and
authorization information
Figure 2. SAML Concepts [5]
5. Securing Web Services
Web services are decoupled applications. The
simplest example is a Web service client that calls a Web
service, for example, a stock quote client web service that
calls a stock quote service, which then returns
information containing the market price for the specified
company. Additionally, a Web application could call the
same Web service client, which in turn invokes the stock
market Web service.
Both Web services and Web applications can require
authentication. They may likely authenticate against a
common user store and will use different means for
authentication.
The OASIS WS-Security specification is the open
standard for Web services security. Its goal is protecting
Web service SOAP messages exchanges by providing
message encryption, authentication, data integrity, and
confidentiality. It provides authentication support for
SOAP messaging by offering several general purpose
mechanisms for associating security tokens with message
content. The specification defines three approved token
types:
 UsernameToken Profile
 X.509 Certificate Token Profile
 SAML Token Profile
Each of these profiles defines how to use its token
type within the WS-Security specification. The use of
SAML assertions with WS-Security is described in the
SAML Token Profile.
5.1 WS-Security SAML Token Profile
The WS-Security specification defines the use of
SAML assertions as security tokens for the purpose of
securing SOAP messages and SOAP message exchanges.
 This particular profile describes [4]:
 How SAML assertions are carried within the
<Security> element in SOAP message
headers [see Figure 3]
 How SAML assertions are used to bind the
subject(s) of the assertion with the
statement(s) contained in the assertion
5.2 Terminology
Some new terminology and concepts have been
introduced by the SAML token profile:
 The SAML assertions themselves have been
obtained previously and typically pertain to
the identity of the sender of the SOAP
message. In the SAML Request/Response
protocol the assertions are provided by a
trusted authority and may or may not pertain
to the party requesting the assertion.
HTTP response
SOAP envelope

 Attesting Entity: provides confirmation SOAP header

evidence for binding the subject of SAML
statements within SAML assertions with the wsse: Security
SOAP message content.
 Relying Entity: the receiver of the SAML Assertion
assertion who makes use of the information
in the assertion for access control purposes
 Subject Confirmation: the method used to Authentication
establish the binding between the subject statement
within SAML assertions and the SOAP
message content. The subject confirmation is Other
identified by a confirmation method statements
identifier with the SOAP security header
 SAML Assertion Authority: the entity that
issues SAML assertions
 Subject: the entity to which the claims in the
SAML assertion refer to wsse: SecurityTokenReference
5.3 Characteristics of the SAML Token Profile
The SAML protocols have a binding to SOAP as we
described earlier. However, the use of SAML assertions
by WS-Security should not be confused with the SAML SOAP body
defined binding [5]. The characteristics of the use of
SAML assertions as defined by WS-Security are as
Figure 3. WS-Security with a SAML Token [5]
follows:
5.4 Use of SAML assertions with WS-Security
 SAML assertions are carried in the
<Security> element within the header There are three SAML use cases for web services
section of the SOAP message envelope. In security.
the SAML Request/Response protocol
binding, the assertions are contained within  Holder-of-Key: In the holder of key use
the SAML response. case, the sender submits a request for an
 The SAML assertions play a role in the assertion to the SAML authority. The issuer
protection of the message they are carried in then returns a signed assertion with the user's
and typically contain a key used for digitally public key embedded in it. The sender then
signing data within the body of the SOAP signs the message body with their private
message. Again, in contrast to the SAML key.
Request/Response protocol binding over  Sender-Vouches: In the sender vouches use
SOAP, assertions play no role in protecting case, the sender vouches for the verification
the SOAP message itself. of the assertions subject. The sender's

4
 private key is used to sign both the assertion
and the message body. If the sender gets the
assertion from a SAML authority then the
SAML authority could also sign the message.
 Bearer: When the confirmation method is of
this type, proof of the relationship between
the subject in the SAML assertions and the
sender is assumed (the subject and the bearer
are implicitly the same). This works the
same way as the Holder-of-Key confirmation
method, with the exception that the sender
need not sign the outgoing message - a model
where the communicating parties do not need
the higher level of assurance and non-
repudiation of a signed message.
In this scenario, the basis of trust is the SAML
authorities' signature. The SAML authorities' private key
is used to sign the SAML assertion for the SOAP client.
The SOAP message receiver relies on the SAML
authority to have issued the assertion to an authorized
client.
6.2 SOAP Message Format
The following example shows what a security header
including a SAML assertion using the holder-of-key
subject confirmation method looks like.
<?xml version="1.0" encoding="UTF-8"?>
<S12:Envelope xmlns:S12="..." xmlns:wsu="...">
<S12:Header>
<wsse:Security ...>

Next, let us look into these subject confirmation <saml2:Assertion ... ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc.">
<saml2:Subject>
methods in more detail. <saml2:NameID>
…
6. Holder-of-key Subject Confirmation </saml2:NameID>
<saml2:SubjectConfirmation
method Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml2:SubjectConfirmationData ...>
<ds:KeyInfo>
An attesting entity uses the holder-of-key confirmation <ds:KeyValue>…</ds:KeyValue>
method to demonstrate that it is authorized to act as the </ds:KeyInfo>
</saml2:SubjectConfirmationData>
subject of the SAML subject statements containing the </saml2:SubjectConfirmation>
holder-of-key confirmation element. </saml2:Subject>
<saml2:Statement>
…
6.1 Processing Model </saml2:Statement>
<ds:Signature>…</ds:Signature>
The following sequence of steps describes the holder- </saml2:Assertion>

of-key method of establishing the correspondence <ds:Signature>

<ds:SignedInfo>
between a SOAP message and the subject of the SAML ...
assertions added to the SOAP message [8]. </ds:SignedInfo>
<ds:SignatureValue>
HJJWbvqW9E84vJVQk…
 A SOAP message client requests a SAML </ds:SignatureValue>
<ds:KeyInfo>
authority for an assertion <wsse:SecurityTokenReference ...>
 The SAML authority returns a signed <wsse:KeyIdentifier ...>
_a75adf55-01d7-40cc-929f-dbd8372ebdfc
assertion with the SOAP message client's </wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
public key embedded in it </ds:KeyInfo>
 The client adds the SAML token to the </ds:Signature>

SOAP header and constructs the SOAP body, </wsse:Security>

signs it with its own key and makes a SOAP
client call.
 The SOAP message receiver validates that
the SAML token came from a security token
service it trusts, by verifying that the SAML
token was signed by the SAML authority
 The SOAP message receiver also validates
the message came from the SOAP client
using the client's public key contained within
the SAML token
 The information in the SAML assertion can
then be attributed to the subject contained in
the assertion
</S12:Header>
<S12:Body wsu:Id="MsgBody">
<ReportRequest>
<TickerSymbol>SUNW</TickerSymbol>
</ReportRequest>
</S12:Body>
</S12:Envelope>
Figure 4. H-O-K SOAP Message
The information in the subject confirmation element
[see Figure 4] provides the means for a relying party
(e.g., a web service) to verify the correspondence of the
subject of the assertion with the party (e.g., a web service
client) with whom the relying party is communicating.
The relying party will allow any party capable of
demonstrating knowledge contained within the subject
confirmation data.

5
 The subject confirmation element indicates that the <?xml version="1.0" encoding="UTF-8"?>
holder-of-key method should be applied to confirm the <S12:Envelope xmlns:S12="..." xmlns:wsu="...">
<S12:Header>
subject and all the statements of the assertion. The key <wsse:Security ...>
<saml2:Assertion xmlns:saml2="..." xmlns:xsi="..."
info element contained in the subject confirmation ID=”_a75adf55-01d7-40cc-929f-dbd8372ebdfc">
identifies a public or secret key that can be used to <saml2:Subject>
<saml2:NameID>
validate the identity of the subject. The signature ...
</saml2:NameID>
element is prepared by the sender using its private key <saml2:SubjectConfirmation
for signing the message contents and assertion. Method=”urn:oasis:names:tc:SAML:2.0:cm:holder-of-key”>
<saml2:SubjectConfirmationData
xsi:type="saml2:KeyInfoConfirmationDataType">
7. Sender-Vouches Subject Confirmation <ds:KeyInfo>
<ds:KeyValue>…</ds:KeyValue>
</ds:KeyInfo>
The Sender-Vouches confirmation method is used in </saml2:SubjectConfirmationData>
</saml2:SubjectConfirmation>
the case when a trust relationship exists between a web </saml2:Subject>
service intermediary and the web service provider. <saml2:Statement>
…
</saml2:Statement>
7.1 Processing Model <ds:Signature>…</ds:Signature>
</saml2:Assertion>
The following steps describe this scenario in more <wsse:SecurityTokenReference wsu:Id=”STR1” wsse11:TokenType=”...”>
detail [9]: <wsse:Reference wsu:Id=”…” URI=”...”> </wsse:Reference>
</wsse:SecurityTokenReference>

 The SOAP client sends a request to an <ds:Signature>

intermediary, and authenticates using another
mechanism, such as username/password
tokens.
 The intermediary then requests a token from
a SAML authority
 The SAML authority signs the assertion and
sends it back to the intermediary
 The intermediary signs the assertion (again)
and the SOAP request, and sends the request
to the web service.
 The web service validates the SAML
assertion, generates the response and sends it
back to the intermediary, who forwards it on
to the client
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="..."/>
<ds:SignatureMethod Algorithm="..."/>
<ds:Reference URI="#STR1"> ... </ds:Reference>
<ds:Reference URI="#MsgBody"> … </ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>HJJWbvqW9E84vJVQk…</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference wsu:Id="STR2"
wsse11:TokenType=”...”>
<wsse:KeyIdentifier wsu:Id=”…”ValueType=”...”>
_a75adf55-01d7-40cc-929f-dbd8372ebdfc
</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</S12:Header>
<S12:Body wsu:Id="MsgBody"> … </S12:Body>
</S12:Envelope>
Figure 5. Sender-Vouches SOAP Message

Here the intermediary is the one who is doing the
vouching for the user by signing both the assertion and
the SOAP body. To trust that the user has been
authenticated, the web service provider must have a
trusted relationship with both the intermediary and the
SAML authority.
7.2 SOAP Message Format
A sender, or the attesting entity, uses the sender-
vouches method to assert that it is acting on behalf of the
subject in the SAML assertion [see Figure 5]. The
information in the subject confirmation element indicates
the method of the subject confirmation is sender-vouches.
The sender signs both the message and assertion with
their private key and includes the signature information
in the security header. By signing both the message and
the assertion the sender is vouching for the integrity of
the message and the assertion.
8. Bearer Confirmation Method
This method does not require message receivers to
establish a relationship between the subject of SAML
assertions and the statements in the assertion. The
statements are implicitly confirmed by the sender, who
also happens to be the subject of the message. The
SOAP message format is similar to that for the Holder-
of-key method with the exception that the message and
assertion are not signed by the sender [4].
9. Security and Privacy Considerations
A description of some of the security and privacy
issues involving use of SAML follows. We'll take a look
at the privacy issues first.
9.1 Privacy
SAML assertions make statements about attributes
and authorizations of authenticated entities. This
information is something that often needs to be only

6
available for viewing to a limited number of entities, for
example, if the statements contain information about
employees, and about medical and financial systems.
Use of a secure network channel, such as SSL/TLS,
provides message confidentiality as SAML messages are
sent between two end points. Within a SAML message,
XML Encryption can also be utilized to provide
additional confidentially [6].
Encrypting contents of assertions sometimes is not
enough to protect privacy information. The notion that a
given entity is accessing a system to obtain the assertion
itself can be considered revealing information about the
entity. Systems using SAML are only able to provide
partial anonymity since any entity about whom an
assertion is made is identifiable by the SAML issuing
authority. An identifier for a subject can be used as an
alias or pseudonym (e.g., like for an anonymous user),
but the more often the pseudonym is used the more it
reveals information about that entity, making it
potentially more vulnerable to harm. A level of
anonymity can be provided by the use of one-time-use
identifiers, and users who are concerned about anonymity
have to take steps to mask patterns of behavior and use
that could reveal information used to identity them.
9.2 Security
Any communication between computer systems can be
the target of a variety of security threats. SAML is used
to transfer authentication and authorization data
supporting distributed systems, and communication
security is important in order for SAML to provide
systems the ability to protect against un-authorized use.
Here is a brief overview of the threat model and
countermeasures that should be used for each situation
[4].
9.2.1 Eavesdropping
Eavesdropping is a threat to the SAML token profile
for web services security. To protect against this threat,
sensitive message content, such as assertions, assertion
references, attribute information, should be encrypted
such that only the valid SAML parties are able to view
this information. Transport layer security should also be
considered for use to further protect the messages and
their contents [4].
9.2.2 Replay
The use of signed SAML assertions ensures data
originated from the holder of the confirmation key
(holder-of-key subject confirmation method). However,
this mechanism does not detect or prevent problems
related to the capture and re-play of the message by other
parties. Also, assertions that contain sender-vouches
7
confirmation impose no restriction on the entities that use
or re-use these assertions. To address the problem of
replay attacks, message senders should include additional
message identifying information such as timestamps,
nonces, and recipient identifiers. Receivers then should
check for this information against previously received
data [4].
9.2.3 Message Insertion/Deletion
The SAML token profile is so far not known to be
vulnerable to message insertion and deletion attacks [4].
9.2.4 Message Modification
SAML messages can be protected from message
modification if receivers have the ability to detect
unauthorized modifications. SAML assertions and
SOAP message content should be signed by the attesting
(sender) entity so that receivers can ensure that the
information that provides binding between the subject to
the message content has been protected by the attesting
entity against modification [4].
9.2.5 Man-in-the-Middle
Assertions with a holder-of-key subject confirmation
method are not known to be vulnerable to a man-in-the-
middle attack. However, the sender-vouches are since
the receiver does not actually authenticate the attesting
entity every time and relies on a previously established
trust relationship [4].
9.2.6 SAML Protocol
Here are some of the more general security
considerations affecting the SAML protocol.
SAML Assertions
A SAML assertion once issued is out of the control of
the issuer, and hence the issuer has no control over how
long the assertion will exist before it is made use of.
Also, the issuer has no control over who the assertion
will be shared with. SAML authorities therefore need to
careful of the information they include in an assertion in
consideration of possible consequences if the assertion is
somehow misused, made public, or exposed to
potentially malicious entities [6].
Denial of Service
Handling, parsing, and lookup of SAML assertions are
a potentially expensive operation. The effort required for
the processing of each assertion is proportionally much
greater than the effort required by an attacker to generate
the request, and so the SAML protocol is vulnerable to a
denial of service (DOS) attack [6].
Requiring additional client authentication (pre-
authentication) at some level below the SAML protocol
level, e.g., SOAP over HTTP, together with the use of an
access control system can block the DOS type attacks
from non-insiders. Any client level authentication used
must have the ability to provide authentication
traceability and not itself be vulnerable to forgery [6].
Also, requiring signed requests can also help level the
effort required to send a signed request with the amount
of effort required to process it. Signing a request is
typically a much larger amount of work as opposed to the
work required to verify the signature itself [6]. However,
an attacker could get around this by potentially replaying
the same signed request. Time stamping can be used
within signatures, and the narrower the window of time a
signature is treated as valid, will further help counter this
form of attack.
Limiting the ability to request SAML assertion to a
select few entities can be used to reduce the risk of a
DOS attack as well. Other methods at the software and
hardware level (firewalls and router) can be used to
further restrict access to the SAML authority or
responders [6].
Key Management
The SAML Token Profile for web service security in
particular relies on the use of digital signatures and
encryption to provide authentication, data integrity, and
confidentiality. Any security provided by it is directly
affected by the security and protection offered by the key
management systems in place. Adequate protection
needs to be provided to limit the access to keys to a
minimum set of entities, together with the use of strong
encryption and password policies for accessing and
storing key materials [6].
Also, while a digital signature can determine if a
message has been altered or not, it does not confirm that
the key used is the actual key of the specified entity, or if
the key itself is still valid (not expired, is of the correct
type). Verifying the binding of key to an entity requires
additional validation and the use of public key
infrastructure (PKI, trusted certification authorities),
helps in establishing the key-to-individual binding [6].
9.2.7 Threats introduced by SAML
Protocol variants
Finally, the SAML protocol is highly extensible and
has been customized by implementers to provide a
federated environment for single sign-on. An
implementer is ultimately responsible to adhering to the
8
SAML specification for providing the levels of message
protection guaranteed by the protocol. Google
implemented a variant of the protocol, using the SAML
Web Browser SSO Profile, for providing single sign-on
for its applications [15]. Its initial implementation
contained a flaw [13, 14], which has been fixed [16],
where a user was granted access to their web site (Google
Docs, for instance) and where the web site could then use
the SAML assertion to access other Google applications
(Google Mail) as the same user. The problem with this
approach is that if one of the web sites gets
compromised, the penetrated service can use of any of
the tokens it receives to impersonate users at any other of
Google's relying sites. Google once notified of the
problem has fixed the issue by changing their
implementation to require identity providers to send
information in assertion responses that will allow it to
check the response is being sent by a valid sender
(identity provider) [16].
There may be other organizations that are using
customized (not fully compliant) implementations of the
SAML protocol and may be vulnerable to other types of
attacks as well. Vendors should make certain that any
customers participating in identity federated
environments ensure that SAML assertions include the
appropriate recipient attribute in the subject confirmation
information, indicating the SAML assertion is indeed for
their service and not hijacked by the sender.
10. Ongoing implementation related work
I initially intended to also develop a supporting
SAML compliant implementation demonstrating secured
message exchanges between a web service client and a
web service provider. I found a few open source projects
including sample code that demonstrated this capability -
mainly the Sun supported open source projects for
NetBeans, Glassfish, OpenSSO [10, 11] and the Internet2
Shibboleth/OpenSAML [13] projects. Learning from the
information gathered by reading and trying the sample
applications and sharing them with my director of
application security development at work, I came up with
a startup project that would meet some of the learning
related goals for future development at my work
involving web services, message security, and
authentication/single sign-on.
The following diagram describes the configuration for
the learning project.
 message level integrity and confidentiality, and defines a
standard set of SOAP extensions containing SAML
User Directory assertions as security tokens. A general description of
some of the privacy and security issues pertaining to the
base SAML protocol and SAML Token Profile are
Client Application Security Token discussed in the end.
Service
The OASIS SAML proposal for securing web services
provides a good, flexible, and extendible framework for
securing web service message exchanges. By offering a
standardized method for the communication of security and
identity information between partners, the SAML standard
make the possibility of providing a common federated
Web Service identity and the seamless processing of cross-domain
Web Service Security Security
Provider
Client Interceptor Interceptor business transactions.

References
Figure 6. Web services message security [1] J. Hodges, How to Study and Learn SAML.
scenario http://identitymeme.org/doc/draft-hodges-learning-
saml-00.html
[2] OASIS Assertions and Protocols for the Security
I have setup the open source Apache CXF web
Assertion Markup Language (SAML) v2.0.
services framework in Apache Tomcat, to host the web Available at http://docs.oasis-
service. Use of the Apache CXF web service framework open.org/security/saml/v2.0/saml-core-2.0-os.pdf,
made sense form the perspective of it being the March 2005
framework of choice for web service development within [3] OASIS Profiles for OASIS Security Assertion
other internal projects. For a security token service I have Markup Language (SAML) v2.0. Available at
OpenSSO setup as the Identity Provider in another http://docs.oasis-open.org/security/saml/v2.0/saml-
instance of Apache Tomcat. I have successfully built, profiles-2.0-os.pdf
deployed, and tested a very basic sample web service and [4] OASIS Web Services Security: SAML Token Profile
client. Work that I have not been able to complete in 1.1. Available at http://www.oasis-
time for the class project, and which I intend to continue open.org/committees/download.php/16768/wss-v1.1-
working on are the two CXF interceptor modules: the spec-os-SAMLTokenProfile.pdf , February 2006
sending interceptor which will use the open source [5] OASIS Security Assertion Markup Language
OpenSAML APIs to request the SAML assertion on the (SAML) v2.0 Technical Overview. Available at
client side for a given user supplied directly to it via http://www.oasis-
open.org/committees/download.php/27819/sstc-saml-
other means such as another authenticated client
tech-overview-2.0-cd-02.pdf, March 2008
application, the construction and signing of the SOAP
[6] OASIS Security and Privacy Considerations for the
message, and the receiving interceptor which will OASIS Security Assertion Markup Language
validate the message sender and the subject information (SAML) v2.0. Available at http://docs.oasis-
within the received SOAP message's security header. open.org/security/saml/v2.0/saml-sec-consider-2.0-
Changes in the choice of APIs and/or products are quite os.pdf, March 2005
possible as I learn more about the capabilities and [7] OASIS SAML V2.0 Executive Overview. Available
limitations of the selected open source products. at http://www.oasis-
open.org/committees/download.php/13525/sstc-saml-
11. Conclusions exec-overview-2.0-cd-01-2col.pdf, April 2005
The paper provides an overview of the SAML XML [8] Glen Mazza, SAML subject confirmation methods:
based framework for describing and sharing security holder-of-key vs. sender-vouches.
http://www.jroller.com/gmazza/entry/saml_subject_c
information between multiple web services. The main
onfirmation_methods_holder, November 2008
focus has been on describing the details of protecting and [9] help.SAP.com, Subject Confirmation Methods for
securing message exchanges between multiple online SAML Token Profiles.
parties as described by the OASIS standard for Web http://help.sap.com/saphelp_nwpi71/helpdata/en/44/3
Services Security using the SAML Token Profile V2.0. 22225a52d5447e10000000a422035/content.htm
The proposal specifies how multiple entities can implement

9
[10] www.NetBeans.org, Securing Web Services Using
the SAML or UserNameToken Profiles.
http://www.netbeans.org/kb/60/javaee/identity-
amsecurity.html
[11] java.sun.com, SAML Sample Application.
http://java.sun.com/webservices/docs/1.6/tutorial/doc/
XWS-SecuritySamples7.html
[12] dev.globus.org, GSoC08/SAML Holder of Key
Authn for HTTP SSO.
http://dev.globus.org/wiki/GSoC08/SAML_Holder_o
f_Key_Authn_for_HTTP_SSO
[13] Alessandro Armando, et. al., Formal Analysis of
SAML 2.0 Web Browser Single Sign-On: Breaking
the SAML-based Single Sign-On for Google Apps.
http://www.ai-lab.it/armando/pub/fmse9-armando.pdf
or http://www.ai-
lab.it/armando/GoogleSSOVulnerability.html
[14] US-CERT, Google SAML Single Sign on
vulnerability. http://www.kb.cert.org/vuls/id/612636
[15] Google.com, SAML Single Sign-On (SSO) Service
for Google Apps.
http://code.google.com/apis/apps/sso/saml_reference_
implementation.html
[16] Google.com, Change in SSO SAMLResponse
requirements.
https://groups.google.com/group/google-apps-
apis/browse_thread/thread/35c9d1a049ef71f3

10