Contents: The problem of non-portability of trust SAML objectives SAML architecture SAML overview SAML process Conclusion Resources Download About the author Rate this article Related content: XML Security: Implement security layers, Part 1 XML Security: Implement security layers, Part 2 XML Security: The XML Key Management Specification Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Manish Verma (mverma@secf.com)
Principal Architect, Second Foundation
23 Mar 2004

The Security Assertion Markup Language, or SAML, addresses the long-felt need to provide a mechanism that transfers information about entities between various cooperating domains without the need for those domains to lose the ownership of that information. The information exchanged could be assertions related to a subject or authentication information. This is also known as single sign-on.

In my last article in this series on XML security, I touched on two security-related topics that have gained significant importance:

• Ease of management
• Portable trust

In that article, I covered ease of management of a security infrastructure using XKMS. In this article, I will explore the second topic, portable trust. Security Assertion Markup Language, or SAML, is a mechanism for ensuring portable trust. I will start with the objectives behind SAML, then explain the SAML architecture, and finish with an explanation of SAML concepts.

The problem of non-portability of trust
You can find no shortage of Web sites that require you to give personal information for reasons as basic as authentication or site customization through personal preferences. Ultimately, you can end up having multiple accounts for yourself in dozens of different places. If each site has its own repository of users for such purposes, the consequences can include:

• Concerns about the safety of your information with all of those individual sites.
• Multiple sites cannot collaborate to provide more granular services that you might be interested in.

To explain the second point further, I will offer a very typical example: travel reservations. This involves booking an airline ticket, a hotel, and a rental car. You may be interested in making the reservation with a specific airline, a specific hotel, and a specific car rental agency, but you don't have a mechanism that allows you to move seamlessly between three independent sites -- you may be required to submit your credentials for verification three different times (assuming you already have accounts with all three of them).

Where does Passport fit in? In a very simplistic and centralized way, Microsoft passport does try to address this issue. The Microsoft passport service involves a large central repository of all the subjects and their attributes. Various participating sites can use the information from this central repository to allow subjects to access information and/or authorize them to take certain actions. The only problem -- potentially a showstopper for a lot of organizations -- is the fact that they lose ownership of subject's data. SAML overcomes this problem by allowing a federated identification, authentication, and authorization regime. The federated regime for authentication and authorization allows the organizations creating data to own and control the data with the ability to share it in a structured and controlled manner with other cooperating organizations.

SAML is designed to fix this problem by allowing you to keep your information with only a few selected parties and allowing those parties to share that information with other interested parties, if required, after your explicit approval. This means that your information is safe in the hands of parties you trust, plus you can have access to a range of higher-level services offered by vendors that bring together a multitude of lower-level services.

In this article, I will demonstrate how SAML lives up to its promises.

SAML objectives
The primary objectives of SAML are:

• Create an authentication and authorization exchange mechanism that is protocol- and platform-independent (also defined as Single Sign-On, or SSO).
• This should be independent of the deployment environment and should work with centralized, decentralized, and federated deployment scenarios.
• The SAML framework should be XML-based.

SAML architecture
SAML is a mechanism for controlling access to resources for authenticated principals. Access to resources is managed based on specific policies. Two key actions are required for such a mechanism:

• Decisions about access control based on policies
• Enforcing those decisions

SAML provisions two roles to handle these actions: Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs).

Scenario: The subject is interested in accessing some secured content from a target Web site. The subject goes to the source Web site that recognizes the subject or has already authenticated the subject. From the source site, the user tries to access secured content on the target Web site, taking the following steps:

1. Subject authenticates to the source site and requests a link to target site’s secured resource.
2. Source site redirects to the subject using the authentication token.
3. Subject makes a request to the target site for the secured resource using the token.
4. Target site’s PEP checks permission with the PDP.
5. PDP may internally request the source site for the SAML authentication assertion using the token.
6. The source site provides an SAML authentication assertion to the target site based on the token.
7. Target site provides the secured resource to the subject.

In all, a subject having been authenticated at the originating site gets a token from the SAML authority that it provides to the target site. The target site uses the token to request the information it needs from the originating site without having to get it explicitly from the subject.

SAML overview
The SAML specification is made up of the following components:

• Assertion and protocol: This specification addresses the syntax and semantics for defining XML-encoded assertions as well as the request and response protocols.
• Bindings and profiles: This specification addresses the mapping of SAML request/response message exchange onto lower layer communication protocols like SOAP or SMTP. A set of rules that govern embedding and extracting the SAML information from lower layer communication protocols is called a profile.
• Conformance specifications: Different SAML implementations may only implement part of these specifications. Conformance specifications set the basic standards to which an implementation of the SAML specification must conform before it can be called a conformant implementation. This helps with interoperability and compatibility.
• Security and privacy considerations: This spec covers the security risks in the SAML architecture -- specifically, the way SAML addresses those risks and the risks that are not addressed.

I will explain the concepts associated with SAML using a question-and-answer format. I will answer the following questions one by one to clarify these basic concepts:

• What are assertions?
• Who produces and consumes assertions?
• How are assertions requested and how are responses sent? Essentially, what is the request and response protocol?
• To which underlying communication and transport protocol can the SAML request response protocol be bound?
• How do I insert SAML assertions into an underlying communication and transport protocol like SOAP?
• What is a conformance specification and why would I need it?
• Can an implementation be compliant even if it implements a subset of the standard?
• What is the granularity level for defining conformance?
• What are the security risks in an SAML-based system?

What are assertions?
Assertions provide information about the authentication performed by the subjects, attributes of subjects, and authorization decisions about whether or not subjects are allowed to access certain resources.

A set of assertions makes a profile of a subject. Assertions in a profile set may be from different organizations.

The three assertion types are:

• Authentication: Authentication assertion deals with authentication of a subject by a specific mechanism at a particular time.
• Attribute: Attribute assertion provides a mechanism for associating specific attributes with a given subject.
• Authorization decision: Authorization decision assertion manages a given subject’s authority to access resources.

Who produces and consumes assertions?
SAML authorities produce assertions. SAML authorities can be further specified as authentication authorities, attribute authorities, or PDPs. Consumers of assertions can either be clients or SAML authorities themselves.

How are assertions requested and how are responses sent? Essentially, what is the request and response protocol?
SAML request and response protocol defines a standard message format for sending the assertion request and getting back the response. The SAML request protocol defines message formats that make the following types of requests:

• SubjectQuery : Allows schemas to define new types of queries that specify a single SAML subject.
• AuthenticationQuery : Requests authentication information about a subject. An authentication assertion is returned in response.
• AttributeQuery : Requests information about the attributes of a subject. Response includes attribute assertions for those attributes for which the requester has permissions.
• AuthorizationDecisionQuery : Makes an authorization decision. Given the evidence that a requester submits, the query determines if the requester is authorized to access the secured resource.
• AssertionIDReference : Retrieves a particular assertion based on its unique identifier.
• AssertionArtifact : Retrieves an assertion based on an artifact that represents it.

The response message format is the same irrespective of the type of request.

To which underlying communication and transport protocols can the SAML request response protocol be bound?
SAML defines how SAML request and response messages are mapped over standard communication and transport protocols. Currently only one binding, SAML over SOAP, is defined. The SAML SOAP binding describes how SAML request and response message exchanges are mapped onto SOAP message exchanges. The SAML specification makes it mandatory to implement SAML over SOAP over HTTP for any implementation to be in conformance with SAML specifications. Optionally, the implementations may also implement SAML over SOAP over any other transportation protocol, such as SMTP or FTP.

How do I insert SAML assertions into underlying communication and transport protocols like SOAP?
The SAML specification defines a set of rules called profiles that describe how the implementations should insert, extract, and integrate assertions in the underlying protocol’s messages. For example, the SOAP profile for SAML describes how SAML assertions are added to SOAP messages, how SOAP headers are affected by SAML assertions, and how SAML errors are handled in SOAP messages.

Two profiles are defined in the SAML specification:

• Browser Post Profile or Push Profile: SAML assertions are uploaded to the browser within an HTML form and conveyed to the destination site as part of an HTTP POST payload when the user submits the form. In this case the source site requests a token from the target Web site, which returns an authorization decision token. The subject is redirected to the target Web site with this token.
• Browser Artifact Profile or Pull Profile: An SAML artifact is carried to the destination site as part of a URL query string such that, when the artifact is later conveyed back to the source site, the artifact unambiguously references an assertion. The subject that's interested in some secure content from the target Web site sends a token (SAML artifact) from the source site, which the target site uses to pull the authentication/authorization information and then decides whether or not to allow access.

What is a conformance specification and why would I need it?
Conformance specifications help to objectively evaluate an SAML implementation or application for its conformance to the SAML specification. Conformance specifications are necessary for the following reasons:

• Ensure a common understanding of conformance and what is required to claim conformance
• Promote interoperability in the exchange of authentication and authorization information
• Promote uniformity in the development of conformance tests

Can an implementation be compliant even if it implements a subset of the standard?
Yes. It is possible to have an SAML implementation that can be declared conformant to either the entire specification or to a subset of the specification.

What is the granularity level for defining conformance?
SAML conformance is defined in terms of SAML bindings and profiles that are supported by an application or implementation. For each supported binding and profile, the conformance must then be specified in the following areas:

• Whether the application or implementation acts as producer, consumer, or both producer and consumer of the SAML messages.
• Which assertions and statements the application or implementation supports

What are the security risks in an SAML-based system?
SAML allows authentication and authorization statements to be made, but does not specify how authentications are done or how authorizations are established. Consumers of the SAML statements must be sure of the underlying infrastructure before trusting the SAML statements. The underlying infrastructure also includes the security and confidentiality that must cover the payloads that go back and forth as client requests and server responses.

Given that SAML is a multi-party authentication and authorization system, it's possible for a valid participant in an SAML transaction to use the information maliciously in another transaction.

Risks associated with SAML assertions: Once an assertion is issued, it is out of the issuer's control. For example, a consumer may choose to persist the assertion for an indefinite period of time or may choose to share the information with a third party that's unknown to the original issuer.

Risks associated with SAML protocol: Denial of Service attack (DOS) can be averted by requiring client authentication at a lower level, by signed requests from a client, or by restricting the ability to issue SAML requests to a limited number of known parties.

Risks associated with SAML protocol bindings (presently SOAP binding):

• Eavesdropping
• Replay
• Message insertion
• Message deletion
• Message modification
• Man-in-the-middle

Risks associated with SOAP over HTTP over TLS/SSL: This provides security, confidentiality, and authorization only for a single hop. For multiple intermediaries in between, HTTP and TLS/SSL do not provide adequate security.

Risks associated with the profiles of SAML (the browser/artifact profile and the browser/POST profile):

• Eavesdropping
• Theft of user authentication information
• Theft of the bearer token
• Replay
• Message insertion
• Message deletion
• Message modification
• Man-in-the-middle

SAML process
Listing 1 demonstrates how assertions associated with a subject might be retrieved using SAML. The code is taken from the SAML sample implementation provided by Verisign. (See Resources to download the source code and associated files.)

Public class SAMLAssertions {
// SAML service provider
// Change it to the SAML service provider url that you are
// trying to connect to
static final String SERVICE_URL =
      "https://pilotpts.verisign.com/vspts/SamlResponder";
// Email of the subject that uniquely identifies it
static final String SUBJECT_EMAIL = "jdoe@tpms.verisign.com";
// Subject password to authenticate the user  
static final String SUBJECT_PASSWORD = "password";
// The keystore to be used for getting the private key and 
// the public key
static final String KEYSTORE_FILE = "saml_sample_keystore";
// Keystore password
static final String STORE_PASS = "changeit";
static final String SIGNER_ALIAS = "pilot_saml_signer";
//  VeriSign attribute naming constants
static final String V_NAME_QUALIFIER = "verisign.com/ams";
static final String V_ATTR_NAMESPACE = 
      "verisign.com/ams/namespace/common";
static final String V_ATTR_EMAIL = 
      "//verisign.com/core/attr/email";
static final String V_ATTR_FIRSTNAME = 
      "//verisign.com/core/attr/first_name";
public static void main(String arg[]) {
NameIdentifier nameId = 
      new NameIdentifier(SUBJECT_EMAIL, V_NAME_QUALIFIER, "");
String[] confMethods = { Identifiers.AUTHN_METHOD_PASSWORD }; 
SubjectConfirmation sconf = 
      new SubjectConfirmation(confMethods, SUBJECT_PASSWORD);
Subject subject = new Subject(nameId, sconf);
AttributeDesignator[] reqAttrs = null;
AttributeQuery query = new AttributeQuery(subject, reqAttrs);
AttributeStatementProvider provider = null;
try { 
provider = getAttributeStatementProvider();
} catch (Exception e) { 
// XXX Auto-generated catch block
e.printStackTrace();
}
AttributeStatement[] statements = null;
try { 
statements = provider.processAttributeQuery(query);
} catch (Exception e1) {
// XXX Auto-generated catch block
e1.printStackTrace();
}
if (statements.length == 0) {
System.out.println("No statements returned");
}
for (int i = 0; i < statements.length; i += 1) { 
AttributeStatement statement = statements[i];
Authenticity authenticity = statement.getAuthenticity();
System.out.println( "Statement "+ (i + 1)+ " authenticity: "
      + authenticity.isAuthentic());
// Print attribute statement  
System.out.println("--- Attribute Statement ---");
System.out.println(  "  Subject: "
      + statement.getSubject().getNameIdentifier().getValue())
// Print attribute values
Attribute[] attrs = statement.getAttributes();
for (int k = 0; k < attrs.length; k += 1) {
Attribute attr = attrs[k];
System.out.println(  "Namespace: " + attr.getAttributeNamespace());
System.out.println(" Name: " + attr.getAttributeName());  
Object[] values = attr.getAttributeValues();
for (int m = 0; m < values.length; m += 1) { 
System.out.println( " Value: " + values[m].toString());
}
}
}
}
private static AttributeStatementProvider
getAttributeStatementProvider() throws Exception {
// Read the keystore and get the signing cert/key.
InputStream fileInput = new FileInputStream(KEYSTORE_FILE);
KeyStore keystore = 
      KeyStore.getInstance(KeyStore.getDefaultType());
keystore.load(fileInput,STORE_PASS.toCharArray());
PrivateKey key = 
      (PrivateKey) keystore.getKey(
            SIGNER_ALIAS,STORE_PASS.toCharArray());
if (key == null) {
throw new Exception(SIGNER_ALIAS + 
      " key not found in keystore " + KEYSTORE_FILE);
}
Certificate[] certArray = 
      keystore.getCertificateChain(SIGNER_ALIAS);
if (certArray == null) {
throw new Exception(SIGNER_ALIAS + 
      " cert not found in keystore " + KEYSTORE_FILE);
}
X509Certificate[] certs = new X509Certificate[certArray.length];
System.arraycopy(certArray, 0, certs, 0, certs.length);
// Create SOAP assertion provider factory with signing information
SOAPAssertionProviderFactory factory =
      new SOAPAssertionProviderFactory(new URL(SERVICE_URL));
factory.setSigningKey(new RSASigningKey(key));
factory.setVerifyingKey(new RSAVerifyingKey(certs));
return factory.newAttributeStatementProvider(); }
}

The following steps describe how in Listing 1, attributes associated with a subject are being queried over the SOAP protocol:

• Step 1: Create the subject whose attributes you are interested in. This is done by creating a SubjectIdentifier and defining the SubjectConfirmation method.
• Step 2: Use the e-mail ID of the subject as a unique subject identifier.
• Step 3: Specify the method to be used for authenticating the user. The method used in Listing 1 is password authentication.
• Step 4: Create an AttributeDesignator object that specifies the attributes you are interested in retrieving values of. In Listing 1, the array is left null as the current Verisign implementation of SAML retrieves values of all the attributes associated with the queried subject, irrespective of what is specified in the AttributeDesignator array.
• Step 5: An AttributeQuery object is created with the subject and the AttributeDesignator array.
• Step 6: Create the AttributeStatementProvider using the key store and the service URL on which the sample SAML service is running.
• Step 7: Use the SOAPAssertionProviderFactory to create the AttributeStatementProvider. Before you create the AttributeStatementProvider, you have to give the SOAPAssertionProviderFactory the signing key as well as the verifying key. The signing key is the private key of the subject and the verifying key has the certificates attached to the key.
• Step 8: Execute the query created in Step 5 on the AttributeStatementProvider created in Step 6. Get an array of AttributeStatement objects. The array contains the values of all the attributes that the provider sent as the result of the query. Iterate through all the attributes in the statement to get the values.

Conclusion
In this article, I have examined the objectives, architecture, and basic concepts of SAML. SAML does a couple of things that clear a lot of clutter in the security portability space: It defines a standard mechanism for representing information that needs to be exchanged, and it defines a standard for exchanging that information. If you are serious about providing security portability, you cannot afford to not evaluate security portability products in terms of their plans for adopting SAML as the standard.

Resources

• Download the source code used in this article.
  
  
• Read the Assertions and Protocol for the OASIS Security Assertion Markup Language (PDF file).
  
  
• See Bindings and Profiles for the OASIS Security Assertion Markup Language (PDF file).
  
  
• Read Security and Privacy Considerations for the OASIS Security Assertion Markup Language (PDF file).
  
  
• Also see Conformance Program Specification for the OASIS Security Assertion Markup Language (PDF file).
  
  
• Get a closer look at the Glossary for the OASIS Security Assertion Markup Language (SAML) (PDF file).
  
  
• Read the XML-Signature Syntax and Processing specification.
  
  
• Find more XML resources on the developerWorks XML zone.
  
  
• Browse a wide range of XML-related titles at the developerWorks Developer Bookstore.
  
  
• Learn how you can become an IBM Certified Developer in XML and related technologies.
  

	Name				Size				Download method
	x-seclay4_SAML.zip				779 KB				FTP

Information about download methods

Rate this article This content was helpful to me: Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5) Comments?

developerWorks > XML >