How SAML works

We take a look at why SAML is vital to the future of Web services, how it works, and whether it has a rosy future.

 


The Web Services Advisor
(To receive this column in your inbox,
click Edit your profile and subscribe.)

How SAML works
As I wrote about in my last column, perhaps the biggest roadblocks to the long-term success of Web services are security issues. 

And one of the most important of those security issues is user authentication - specifically, allowing a user to sign on or use multiple Web services from separate but affiliated sites, without having to authenticate himself at every step of the process. That's the job of SAML (Security Assertion Markup Language), an XML-based standard for authentication and authorization that provides a "single sign-on" so that people can be authenticated once and then be able to access multiple Web services. SAML allows each individual site to have its own mechanism for sign-on and authentication, but will allow sites to accept authenticated users from other sites.

Why SAML is needed
Before we take a look at how SAML works, let's take a look at why it's needed. Let's say someone visits an airline site with a Web services architecture, and reserves tickets after signing on and being authorized to buy the tickets. The site offers special deals with partner sites on hotel stays and car rentals, and so the user decides to make reservations with them. In order to make reservations with each of those partner sites without SAML, the person will have to sign on separately to each site, using different user names, passwords and authentication information. He also might have to enter special codes that say he is entitled to the special deals. But with SAML, the person would only have to sign on to the first site, and he would then automatically be authenticated via SAML at the affiliated sites.

Even more problematic are complex B2B transactions done via Web services. Web services will most likely be used in automated transactions that involve multiple business partners, including manufacturers, distributors, packagers, suppliers and retailers. With no way to authenticate each partner and what they can and can't do in a transaction, these transactions won't be able to be done automatically. With SAML handling authentication, complex transactions can be automated without worrying about authentication problems.

How SAML works
So how does SAML tackle all this? At its base, SAML is nothing more than a series of XML-based messages that detail whether users are authenticated, what kind of rights, roles and access they have and how they can use data and resources based on those rights and roles. It will work with HTTP, SMTP, FTP and SOAP, among other protocols and technologies.

The three main components of the SAML specification are:

 

  • Assertions SAML has three kinds of assertions. Authentication assertions are those in which the user has proven his identity. Attribute assertions contain specific information about the user, such as his spending limits. Authorization decision assertions identify what the user can do, for example, whether he can buy an item.
  • Protocol This defines the way that SAML asks for and gets assertions, for example, using SOAP over HTTP for now, although using other methods in the future.
  • Binding This details exactly how SAML message exchanges are mapped into SOAP exchanges.

The assertions are exchanged among sites and services using the protocol and binding - and those assertions are what authenticates users among sites.

SAML in real life
How does SAML work in real life? Let's take a real-life example. Say someone logs in and uses a Web service, is authenticated and then wants to go to a partner site. With SAML, he can be authenticated at the second site without having to sign on. The nearby figure shows each step of the process:

In Step 1 the user has authenticated himself with Site 1 and wants to visit Site 2. He clicks on a link to go to Site 2.

In Step 2, instead of being sent straight to Site 2, he is instead sent to the SAML service for Site 1.

In Step 3 the SAML service appends a partner ID and a special handle to Site 2's URL in the user's browser. For example, if the user wants to go to the site http://www.buymenow.com, after the SAML service appends the extra information, the URL might now be https://www.buymenow.com?SAMLart= . Note that the protocol has changed to the secure https instead of http. The user is redirected now to Site 2's SAML service, which examines the URL with the appended information. Based on the information in the URL, Site 2's SAML service communicates with Site 1's, and Site 1 sends along the authenticated identity of the user, along with any rights that the user has.

In Step 4 the user is sent to Site 2, fully authenticated. The user can now perform transactions on the site just as if he had logged directly into the site.

The future of SAML
As of now, SAML is not yet a fully accepted standard. OASIS, the consortium that develops XML standards, is expected to accept the first official SAML standard this summer or late spring. Some time in the fall, you can expect products to be available that can make use of the accepted spec.

As with all standards, though, expect some problems. It's unclear whether a Web service built using an early version of SAML will be able to completely work with a Web service built using a later version. Considering that SAML 1.0 hasn't even been accepted yet, it's a moot point right now, but could be problematic in the future.

A bigger potential issue is whether Microsoft will buy in to the spec. Even though Microsoft is an OASIS board member, it's working on its own separate authentication protocols, known as WS Security and WS License. If Microsoft decides to continue work on them and use them as an alternate to SAML, all bets are off as to how useful the protocol will prove in the long run.

 


 

About the Author

Preston Gralla, a well-known technology expert, is the author of more than 20 books, including "How the Internet Works," which has been translated into 14 languages and sold several hundred thousand copies worldwide. He is an expert on Web services and the author of a major research and white paper for the Software and Information Industry Association on the topic. Gralla was the founding managing editor of PC Week, a founding editor and then editor and editorial director of PC/Computing, and an executive editor for ZDNet and CNet. He has written about technology for more than 15 years for many major magazines and newspapers, including PC Magazine, Computerworld, CIO Magazine, eWeek and its forerunner PC Week, PC/Computing, the Los Angeles Times, USA Today, and the Dallas Morning News among others. As a well-known technology guru, he appears frequently on TV and radio shows and networks, including CNN, MSNBC, ABC World News Now, the CBS Early Show, PBS's All Things Considered and others. He has won a number of awards for his writing, including from the Computer Press Association for the Best Feature in a Computer Publication. He can be reached at preston@gralla.com.

 

For More Information

 

  • For the Best Web Links for Web services security, click here.
  • What do you think about this column? If you'd like to send feedback, you can E-mail the Editor.
  • Post your technical questions, or help out your peers by answering questions, in our Discussion Forums.
  • Ask the Experts! Our Web Services, SOAP, WSDL, XML, .NET, Java and EAI gurus answer your toughest questions.


 

This was first published in April 2002

Dig deeper on SOA security tools

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close