Roman Pletka

Christof Dornbierer

(3482) SAML: Identity Federation in Practice

Technical long talk 50 min

Tuesday, 2008-06-24, 15:00 - 15:50, Arena 5

• Roman Pletka - AdNovum Informatik AG (speaker)
• Christof Dornbierer - AdNovum Informatik AG (co-speaker)
• Alex Suzuki

Topics

• Security
• Real-world experiences and show cases

Download the presentation

Abstract

The Security Assertion Markup Language (SAML) is an XML-based open standard for 
exchanging authentication and authorization information between identity 
providers and consumers. Although standardized for quite some time, SAML, 
unfortunately, is not yet widely deployed. We discuss the alleged shortcomings 
and how they can be overcome by a mature design combined with some detailed 
know-how of existing implementations and their differences. We focus on two 
advanced use cases and present viable solutions for further problems.

After the introduction of the initial standard SAML 1.0 in 2002, version 1.1 in 
2003 aimed to simplify the processing of digital signatures by removing some 
definitions and enable non-cacheable assertions (i.e., one-time usage) as a new 
element. A clean-up in elements and URIs as well as many clarifications have 
also been made.  Today, SAML 1.0 is only of historical interest.

SAML 2.0, adapted in March 2005, added many new features motivated by the 
Liberty Alliance Federation Framework (ID-FF) V1.2 specifications, the 
Shibboleth architecture from Internet2, and practical experience with SAML 1.x. 
SAML 2.0 introduced considerable changes which made the transmitted 
representations and protocols incompatible with the previous ones.  The main 
novelties in SAML 2.0 include 5 new protocol bindings beside the exsting SAML 
SOAP binding, namely, Reverse SOAP (PAOS), HTTP Redirect, HTTP POST, HTTP 
Artifact, and SAML URI, the addition of 11 new profiles (previously 2), and 
changes in the definition of the assertion itself.  The important adaptations 
with respect to identity federation are the XML encryption support which allows 
SAML identifiers, assertions, and attributes to be encrypted, and new name 
identifier formats allowing to provide privacy protection.

Based on an introduction to the SAML standards including assertions, protocols, 
and bindings, we will discuss SAML support of different J2EE containers and 
address the discrepancy between theory and practice, the detection of which is 
one of the key aspects for a successful deployment of SAML.

Limitations of SAML support in application containers can be overcome using the 
OpenSAML Java library, an open source implementation of SAML. OpenSAML supports 
the creation of SAML messages and building the corresponding SAML representation 
from it, parsing of SAML assertions, and provides the functionalities for 
implementing applications using various SAML profiles and transport bindings. 
Currently, support of SAML 2.0 is being developed by the OpenSAML project.

- Advanced use case 1: Trust relationship establishment in the form of 
impersonation of federated identities

For an impersonation of federated identities SAML assertions are issued with 
another user name than the real one, hence the real user's credentials are 
actually not known. Limitations to the impersonation are realized by adding 
conditions to the assertion. In such a setup special care has to be taken to 
correctly define all trust relationships which we will point out based on an 
example.

- Advanced use case 2: SAML assertions in WebServices

SAML assertions can also be used for WebServices. The WebService Security (WSS) 
profiles describe how assertions are placed in a WSS security header. Because 
there are only few implementations with limited capabilities, only the username 
tokens and X..509 certificates are really used in practice today. By adding SAML 
assertion support in a reverse proxy, authentication methods can be easily 
exchanged and adapted to the actual requirements. This can be realized as 
browser-POSTs or Reverse-Proxy-POSTs.

Some of the pitfalls and limitations arising while working with SAML have to be 
taken into account already at the design phase. We present viable solutions for 
problems such as limited query strings limiting data in an assertion, 
unintentional signature discrepancies and potential browser redirects.

Finally, we provide directions to realize SAML-based trust relationships for 
identity federation and give an insight into how information can be piggy-backed 
in SAML assertion. We also compare SAML to other approaches for identity 
federation such as OpenID. And last but not least, we would like to point out 
that besides the technical issues that arise with identity federation, a mature 
design also has to take into account legal aspects which, unlike a standard such 
as SAML, can differ from country to country.