Federated Identity for the Technically-Adept

Nick Ragouzis, Enosis Group, 30Mar05 (posted); 12Apr06 (link updates)

An unofficial prioritized reading list for technologists just beginning the journey into design and architecture of Federated Identity systems.

Specs only; so don't stop with this set of docs.


I created this list on the request of John Moehrke, at GE Healthcare, as part of his work with the IHE ITI Technical Committee working on the Technical Framework for Cross-Enterprise User Authentication (XUA) in its 2005-2006 profile. (For an overview of that domain's work, see: Integrating the Healthcare Enterprise.)

This is not a simple domain, so there's no shortcut to the knowledge necessary to architect and specify a service. To balance that warning, I think a solid reading of the Domain Scope documents will pay off in a strong foundation for a fast pass at the remaining documents.

I present these in three scopes: First Domain Scope, then Assertions on Identity, SAMLv2.0, then Identity-Enabled Web Services, Liberty Alliance ID-WSF2.0. I've placed at the end the links to the higher-level sites.

Version 1.1, 12Apr06


SAMLv2.0 Executive Overview

Best, most-recently updated, short introduction to the domain.

SAMLv2.0 Technical Overview

This is a quick dive into the basics, a useful foundation for subsequent readings. The assertion is detailed. Discussion of protocols and profiles.

Security and Privacy Considerations for SAMLv2.0

Very useful, broad coverage of the considerations. Applicable to most users of this technology -- offering insight for every essential use case.

Liberty ID-WSF Web Services Framework

From a perspective of identity-enabling web services, this document in one of two that fill a role similar to the first two above -- providing a high level view _plus_ some pointy brackets.

Liberty ID-WSF Overview

The second of the set to get initial grounding, in the web services environment. (This edition is the ID-WSF2.0 draft.)


SAMLv2.0: Authentication, attributes and context, with integrity and privacy. Offering federated identity, SSO, and other basic necessities.

Conformance Requirements for SAMLv2.0

This document serves as a concise guide to the rest of the standard. I am speaking primarily of Table 1 in Section 2, Profiles and Possible Implementations, and of the list of Operational Modes at the beginning of Section 3, and the feature mixes in Tables 2, 3, and 4. Fuller understanding of the doc. can wait until later.

Assertions and Protocols for SAMLv2.0 (aka Core)

Assuming you're not simply plug-and-play with a COTS product, the fundamental basis for evaluating use cases and deriving solution architectures is an understanding of, at least, Section 2 (SAML Assertions), and Section 3 (SAML Protocols), of this document.

Profiles for SAMLv2.0

This describes how the above may be combined into an operational framework -- what goes where, when. On a first pass, just become familiar with the concepts in Section 3 and the major heads of Section 4.

Bindings for SAMLv2.0

Recommend only a brief scan on first pass. You will probably want to return to this document to understand the current protocol bindings and the potential for defining a new one where appropriate.


Significant new challenges arise in attempting to bring advanced identity services (SAMLv2.0-class) into the web services environment. Liberty released ID-WSF1.0 a year ago (or so) leveraging ID-FF1.2; several large vendors have interoperable-certified implementations. The upcoming ID-WSF2.0 leverages SAMLv2.0. Note: All the Liberty ID-WSF2.0 documents are drafts.

Liberty ID-WSF Implementation Guidelines

Not a part of the specification, but a useful document to frame thinking about solving identity, authentication, and integrity problems in the web services environment. Will serve as your roadmap for the specifications.

ID-WSF2.0 Security Mechanisms

There really isn't any way to avoid digging right into the specs. The form of Liberty's ID-WSF specifications reflect the main challenge (and benefits) of all web services -- in design _or_ understanding: they are distributed and somewhat autonomous. The same is true of this specification set: two handfuls of related docs, but apart from the above no one whole, central, document. SechMechs is important to understand, but a first pass could ignore Section 8 and on.

ID-WSF2.0 SOAP Bindings

This is the other foundational specification -- but I think you could give it a miss on the first pass. One reason to include a quick scan is that it gives you a good sense of the message exchange patterns and the key players in the architecture.

ID-WSF2.0 Discovery Service

DS is central to the interplay of Web Service Consumers (WSC) and Web Service Providers (WSP) and the coordination with the Interaction Service (IS). On first pass focus on Section 5, Discovery Service. Take a quick scan of Section 3, Service Instance Description, and Section 4, Resource Offering Description.

ID-WSF2.0 Interaction Service

The IS serves to ameliorate the gap borne of the paradigm of autonomy that is central to web services: IS makes it possible to contact resource owners to obtain consent, authentication, or other information related to the activity of a third party. Scan Section 2, Overview, and Sections 5 and 6, Interaction Service, and Security Considerations.

ID-WSF2.0 Authentication Service

This is the last key service to review in a first pass. The AS provides a SASL-based design to identity authentication in ID-WSF. This is crucial to working with identity providers, and extends to SSO in the web services environment. If you are not familiar with this domain I recommend a pass through Section 3, Terminology. Then I think Section 4.1 Authentication Protocol: Conceptual Model, followed by Section 5, Authentication Service (covering sub-sections 5.1-5.4). Section 6, Single Sign-on Service, might not ultimately be important to your service, but skimming through 6.1-6.4 would help cement the whole picture.

ID-WSF People Service

Okay, one more service. Review this to test your grasp of the relationships among, and gaps in, the prior services. Without a service such as this, web services have to design their own way of helping users to grant to other users access to identity-protected information (which, experience shows is usually accomplished by (a) forcing the guest to become a member themselves at the targeted service, or (b) sharing identity information, either with the service of the guest or the other way round). This service accomplishes this while protecting the privacy of both parties, and maintaining the integrity of the services involved.


To underscore the obvious: Many other documents comprise these specifications and related information. A visit to the following web sites will give you the broader picture (including links to other resources):

OASIS Security Services (SAML) TC


Liberty Alliance Specifications


Shibboleth Project


Of Interest