Contents: ID management Web single-sign-on SAML design Defining attribute meanings Authentication authority Transmitting data on the Web Replay techniques Authentication authorities Anonymous access SSL certificates Vaporware Canonicalization Conclusion Resources About the author Rate this article Related content: Enabling XML security Using Web services for e-Commerce single sign-in Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Frank Cohen (fcohen@pushtotest.com)
Founder, PushToTest
08 Jul 2003

At the beginning of 2003, the Organization for the Advancement of Structured Information Standards (OASIS) group approved the Security Assertion Markup Language (SAML) specification. With 25 companies participating, you would think that the software development community would have a good understanding of SAML. However, misconceptions about SAML still exist, so this article aims to detail and debunk many of the myths and misunderstandings surrounding SAML.

As a newcomer, the SAML specification is being compared to existing single-sign-on technologies, authentication services, and directory services. SAML is the first of what likely will be many authentication protocols to leverage Web infrastructures, where XML data moves over HTTP protocols on TCP/IP networks.

The OASIS group developed SAML as an XML-based framework for exchanging security information. SAML is different from other security approaches mostly because of its expression of security in the form of assertions about subjects. Other approaches use a central certificate authority to issue certificates that guarantee secure communication from one point to another within a network. With SAML, any point in the network can assert that it knows the identity of a user or piece of data. It is up to the receiving application to accept if it trusts the assertion. Any SAML-compliant software can assert its authentication of a user or data. This is important for the coming wave of business workflow Web services standards where secured data needs to move through several systems for a transaction to be completely processed.

Misunderstanding: SAML is a complete identity management solution
SAML plays an important role as a communication protocol between servers in an identity management solution; however, SAML is not an entire solution. In the information systems security space, identity management recently emerged as a new term that covers the following areas of computing:

• Provisioning. Adds new users to network operating system directories and application server directories, both inside an enterprise and outside at partner information systems.
• Password management. Enables users to have a single set of credentials to sign on to the company information systems. Additionally, it enables users to self-administer their passwords, user account data, and privileges.
• Access control. Enables the system to recognize security policies for groups of users. For example, a security policy would prevent people from changing their own job title and instead route a request for a job title change to the appropriate authority.

SAML is a protocol specification to use when two servers need to share authentication information. Nothing in the SAML specification provides the actual authentication service that a commercial directory server otherwise provides.

Myth: Web single-sign-on between enterprises is well understood and easy to implement
SAML is one of many attempts to reduce the cost of building and operating information systems that interoperate between many service providers. In today’s competitive, fast-moving environment, federations of enterprises emerge that provide interoperability to the user through a browser and Web-enabled application. For example, on a travel Web site, users can book airline tickets and car rentals without having to sign on more than once. Today, hordes of software developers, QA technicians, and IT managers are required to handle complex and unreliable backend systems that provide federated security between enterprises.

In a typical Web-enabled infrastructure, software running leading-edge enterprise systems needs to handle browser redirects between authorization servers; HTTP post commands between server domains, public key infrastructure (PKI) encryption, and digital certificates; and a mutually agreed-upon mechanism that states the trust level for any given user or group. SAML shows software developers how to represent users, identifies what data needs to be transferred, and defines the process for sending and receiving authorization data.

Myth: SAML is a complicated design
SAML provides a blueprint for systems architects who need to design and build scalable and federated systems on Web infrastructures (XML/HTTP/TCP). Even if you decide not to use SAML, the SAML specification answers many of the design questions that any system architect needs to answer when building an interoperable, Web-enabled system.

As an example, consider the SAML assertion mechanism that is used to encode a request for authorization into an XML request. SAML defines several types of statements:

Authentication. The subject has logged in. For example, a SAML Assertion for authentication may look like the following:

fcohen@pushtotest.com logged in at 2003-02-06T19:22:09Z

Attribute. Identifies the properties for a subject. For example, fcohen@pushtotest.com has the role of Admin.

Authorization decision. States the subject is allowed to perform operations on a resource. For example, fcohen@pushtotest.com is authorized to GET http://www.pushtotest.com/ptt/kits/index.html.

Assertion attributes. An optional mechanism to enable industry consortia to define attributes specific to their industry.

Additionally, SAML defines attributes of an assertion that are shared by the statements in an assertion, including:

Version attributes. Identify the major and minor versions of the SAML specification that the assertion complies with.

Signature. SAML defines an XML Signature element to identify the authority. This can contain an X509 certificate with a public key, expiration date, and usage policy. The XML Signature also contains the signature value itself, generated by the authority for the content of the element. The signature can be verified using the authority's public key information in the X509 certificate. In general, the complexity in SAML comes from the deployment of the SAML-based software and the setup of the Public Key Infrastructure (PKI) environment and digital certificates.

SAML also defines optional condition elements to limit the validity of an authorization request. For example, an SAML token may be valid NotBefore or NotOnOrAfter a specified UTC-encoded date. Note that SOAP Security, like SOAP-DSIG, is different than SAML. SOAP has its own security proposals in WS-I and WS-Security that use SOAP headers to embed security, encryption, and authentication tokens. SAML is more appropriate for HTTP over TCP-based Web applications.

Misunderstanding: SAML predefines all the attribute meanings for most industries
SAML does not define attribute meanings for any industry. Instead, SAML defines a namespace mechanism that industry consortia may use to define attributes for their particular industry. For example, in the aerospace industry the SAML attribute role:mechanic defines a mechanic at an airline. The parties at both ends of a system need to agree separately on the namespaces used by SAML.

The SAML specification identifies its own namespace to qualify SAML attributes and elements. For example, the namespace "urn:oasis:names:tc:SAML:1.0:action:ghpp" defines the get/head/put/post http actions that SAML operations use. If the SAML namespace format looks odd, that is probably because SAML namespaces do not follow what has become the traditional XML namespace format found in SOAP and XML-RPC. The XML namespaces are URIs; SAML uses the URN variant of URIs while others use the URL variant.

Myth: SAML is an authentication authority
SAML is an authentication protocol that is used between servers. You still need something that actually performs the login for you. All SAML can say is "you have logged in." For example, when an LDAP server authenticates a user, the authentication authority is the LDAP server even though the LDAP server may be using SAML to communicate the authorization.

In a complete authentication system, you still need to write a policy decision point to decide if a user may access a Web page. Additionally, you still need to write a policy enforcement point. This is a servlet or application that receives the authorization, checks the role and authorization, and then makes an assertion. Several companies provide commercial policy decision point and policy enforcement point solutions, including IBM.

Misunderstanding: SAML does not work well where authentication needs to transmit large data
SAML defines an artifact mechanism when the authorization request is too long for an HTTP redirect. The SAML artifact is 40 bytes long and contains a type-code (20 bytes for a source id) and a 20-byte random number that the servers use to look up an assertion. The source service stores the assertion temporarily. The destination site receives the assertion and does a direct pull of the needed data from the artifact on the source site. This allows two different security servers to use artifacts.

Myth: SAML is easy to break using replay techniques
A replay attack is where a valid message is intercepted and replayed back to the service. You can use replay attacks to create data integrity issues as well as denial-of-service attacks.

SAML provides protection from replay attacks by requiring the use of SSL encryption when transmitting assertions and messages specifically to prevent interception of assertions. Additionally, SAML provides a digital signature mechanism that enables the assertion to have a validity time range to prevent assertions from being replayed later.

Finally, the artifact profile has two additional replay countermeasures:

• The SAML source site only returns the assertion to the requester to which the artifact was sent.
• The SAML source site erases its artifact-to-assertion mapping after the first use of the artifact, making replayed artifacts invalid.

Misunderstanding: SAML defines a discovery procedure to find authentication authorities
SAML has no definition for a mechanism to find destination sites that accept SAML assertions. SAML defines a push mechanism for authentication: The user signs in to a source site, and the site sends an assertion to the destination site. This process requires digital signing between the source and destination sites. In a Web environment, the browser posts a form to the destination site and includes a Base64-encoded signature and assertion in a hidden form variable. It is possible that a future SAML specification will include a discovery mechanism.

Myth: SAML does not handle anonymous or guest access automatically
SAML has no provision for providing anonymous authentication. Consider the scenario where a Web site allows you to use the functions of a partner Web site, but the partner site is not allowed to know who you are. SAML does not provide this. It is possible to get SAML to handle anonymous or guest access, but this requires that the participating enterprises agree to their own convention for anonymous or guest authorized access.

Myth: SAML provides its own certificate mechanism
SAML is built on a foundation that requires SSL certificates to provide digital signing and encryption of SAML assertions. So, SAML comes with all the pain you expect from SSL.

SAML is one of the first protocols to require that degree of fine-grained security; for example, the fine-grained security that XKMS provides authenticates an SAML assertion. In the meantime, SAML provides security for an SAML artifact by requiring HTTP client-side authorization using HTTP Basic or SSL client-side certificate authentication. The artifact is sent only to the expected requester and is deleted after it is retrieved.

Misunderstanding: SAML is vaporware; no one has implemented it yet
A number of commercial and open-source products already provide SAML, including:

• IBM Tivoli Access Manager
• Oblix NetPoint
• SunONE Identity Server
• Baltimore, SelectAccess
• Entegrity Solutions AssureAccess
• Internet2 OpenSAML
• Netegrity SiteMinder
• Sigaba Secure Messaging Solutions
• RSA Security ClearTrust
• VeriSign Trust Integration Toolkit
• Entrust GetAccess 7

Misunderstanding: Canonicalization in XML Signatures is not needed
This is simply false.

This simply is false. XML Signature is a specification designed to meet the special requirements for using digital signatures with XML documents, including SAML. The XML Signatures working group at the W3C is developing an XML syntax to sign just about anything -- such as XML documents, SOAP message headers, and XML elements -- and to provide protocols and procedures for creating and verifying digital signatures.

Canonicalization in XML Signatures is necessary to allow authentication between multiple services. For example, consider what happens on the server side when you buy a personal computer from a manufacturer through a browser interface. Multiple services handle portions of your order: one provides a search to find the product you wish to order, the next is a billing service to take your payment information, and the final service takes your shipping information. These three systems share your record using SAML assertions. Canonicalization makes sure the order of the bytes in your record stays the same even though three different systems are manipulating the record. Without canonicalization, the record may change and make the XML Signature invalid because the XML Signature's mission is to make sure the contents it has signed are intact and in the same byte order. Neither XML Signature nor WS-Security is required to use SAML.

Conclusion
With many security-focused companies already providing shipping products, SAML is off to a good start. The SAML specification provides a good framework for designing Web-enabled single-sign-on services among a group of federated services. The SAML specification working group continues to rationalize the interoperability requirements between SAML and other emerging standards, including WS-Security.

The author thanks Charles Knouse, Principal Software Engineer at Oblix, and the Web Services Special Interest Group of the Software Development Forum (www.sdforum.org) for their assistance in researching this article.

Resources

• Read the SAML specification on the OASIS consortium site.
  
  
• Check out Murdoch Mactaggart's developerWorks article Enabling XML security, an excellent introduction to XML encryption and XML signature (September 2001).
  
  
• See how the upcoming Web services security protocols work -- read the WS-Security Profile for XML-based Tokens here on developerWorks (August 2002).
  
  
• Get more background with Jon Udell's InfoWorld article on SAML and PKI.
  
  
• Download alphaWorks' XML Security Suite for an implementation of XML digital signatures.
  
  
• Review this previous article by Frank Cohen to see an XML single-sign-on approach that was popular prior to Web services (developerWorks, January 2002).
  
  
• Find more XML resources on the developerWorks XML zone.
  
  
• Get IBM WebSphere Studio, a suite of tools that automate XML development, both in Java and in other languages. It is closely integrated with the WebSphere Application Server, but can also be used with other J2EE servers.
  
  
• Find out how you can become an IBM Certified Developer in XML and related technologies.
  

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

developerWorks > XML | Security >