SAML and Federated Identity 101 (Part 1)
I am dealing with some tough SAML issues, with Michele's help, and I thought I would put in some review notes on SAML for other people to benefit as well. Reference for this material was the book: Securing Web Services with WS-Security.
Introduction
In the past, there was no real need to share identities from one organization or company to another. This has changed quite a bit with SOA, Services and the Internet with increased collaboration across trust domains. The need for federation of security attributes has become critical.
Some Definitions
- Identity - Individual or entity (machine) representing itself for consideration
- Subject - Entity asserting it's identity
- Credentials - created when a subject's identity initially established and verified in some trust domain by some 3rd party
- Portable - Credentials are portable when subject's identity verified in one trust domain and wants to assert and its identity and rights in another trust domain
- Assertions is a claim when some subject identity wants to do something. They may be challenged and proven.
- Authentication is an assertion that a subject is who they say they are
- Authorization is an assertion that the subject identity is allowed to do something
Why SAML?
XML and/or SOAP has no standardized and interoperable way to communicate two different entities in two different trust domains to communicate their security properties and establish trust. Security Assertion Markup Language (SAML) is the XML standard that was created in order to enable portable identities and the assertions they want to make. SAML is a standard XML format suitable for but not tied to any transport. SAML includes a standard message exchange protocol. SAML specifies the rules for how it is transported, making interoperability explicit at the specification level. SAML is unlike other security approaches because of its expression of assertions about subjects.
What Problems Does SAML Address?
We have been dealing with a world where each organization acted as its own identification authority for its users and thus formed its own trust domain. As organizations got larger and more complex with large numbers of users and large collections of users, there as a push for single sign-on capability.
The single most important problem that SAML is trying to solve is the Web Browser Single Sign-On (SSO) problem. Single sign-on solutions are abundant at the intranet level (using cookies, for example) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies. SAML has become the definitive standard underlying many web Single Sign-On solutions in the enterprise identity management problem space. [3]
In addition, we found that it not work for Web Services that span multiple trust domains, and thus there is a strong push for Federated Identity.
Transportable Trust
SAML came into the picture as a major, standards-based way for describing the assertions we just talked about. SAML allows you to specify identity information IN XML, which allows you to attach this to other XML messages, including SOAP. This creates a "portable trust" that is critical for cross-domain trust and cross-domain B2B Web Services.
Trust Assertions
SAML defines three types of assertions: authentications, authorizations, and attributes. A trust assertion is defined in SAML as a claim, statement, or declaration of fact according to some assertion issuer (SAML authority) specifying:
- Authentication - States that a particular authentication authority has authenticated the subject of the assertion, using a particular process at a particular time with a validity for a specific period of time
- Authorization - States that the particular authority has granted or denied permission for the subject of the assertion to act on a particular resource within a specific period of time.
- Attributes - Provides qualifying information about either an authentication or authorization assertion.
This section [1]
How SAML Works
SAML is fundamentally three ZML-based mechanisms:
- Assertions - An XML schema and definition for security assertions. This makes SAML an XML framework that can be extended with new assertions.
- Protocol - An XML schema and definition for a request/reply protocol. The requests are for policy decisions and enforcement from SAML authorities
- Bindings - Rules on using assertions with standard transport and messaging frameworks. These rules are described as a set of bindings and protocols. [2]
Well, I bet you are just itching to see the angle brackets at this point right? Well, maybe not :). Let's see if I can sum up the major aspects of how SAML works.
SAML Assertions
A SAML assertion contains a packet of security information:
<saml:Assertion ...> ... </saml:Assertion>
Claims are made to an authority who returns another assertion. Assertions contain statements that service providers use to make access control decisions. Three types of statements are provided by SAML:
- Authentication statements
- Attribute statements
- Authorization decision statements
Authentication statements assert to the service provider that the principal did indeed authenticate with the identity provider at a particular time using a particular method of authentication. Other information about the authenticated principal (called the authentication context) may be disclosed in an authentication statement.
An attribute statement asserts that a subject is associated with certain attributes. An attribute is simply a name-value pair. Relying parties use attributes to make access control decisions.
An authorization decision statement asserts that a subject is permitted to perform action A on resource R given evidence E. The expressiveness of authorization decision statements in SAML is intentionally limited. [4]
SAML Producers and Consumers
Here is where there are some fancy names but basically you are making the decisions or requesting them. Fancy name time. A Policy Decision Point (PDP) makes decisions about access control based on one or more parameters. A Policy Retrieval Point (PDP) is needed to get policy information if the PDP is external to the system. A Policy Enforcement Point (PEP) is what makes the enforcement decision. A PEP makes a connection to the appropriate PDP for the decision. Which leads us to ....
SAML Protocol
SAML defines a request/response protocol to exchange assertions. A request contains a claim and the response contains the resulting assertion.
SAML Versions
In summary, SAML has undergone one minor and one major revision since V1.0.
- SAML 1.0 was adopted as an OASIS Standard in November 2002
- SAML 1.1 was ratified as an OASIS Standard in September 2003
- SAML 2.0 became an OASIS Standard in March 2005
The Liberty Alliance contributed its Identity Federation Framework (ID-FF) to the OASIS SSTC in September 2003:
- ID-FF 1.1 was released in April 2003
- ID-FF 1.2 was finalized in November 2003
Where are We?
Well, that was a quick introduction. There is a lot more, especially with Federated Identity. The rest is up to you? Like what you see? Thoughts? Where would you like to see this go if it were a series?
[1] Securing Web Services with WS-Security. Sam's Press, 2004
[2] Securing Web Services with WS-Security. Sam's Press, 2004
[3] SAML, Wikipedia, http://en.wikipedia.org/wiki/Saml
[4] SAML, Wikipedia, http://en.wikipedia.org/wiki/Saml
