XML Reference Guide

Everybody starts the discussion of "Single Sign-on" by talking about how many times a day you have to use a (potentially different) username and password in your daily computer dealings. They talk about how nice it would be if you only had to sign in once, and then everywhere you went sites would automatically open their virtual doors to you based on this magical authentication. And they talk about it as though it were something new.

It's not new. You use a version of this "single sign on" virtually every day in your offline life. Every time you get stopped for speeding or write a check or sign up for a library card and someone asks to see your drivers license or state ID, you're using a version of "single sign on".

It works like this: the clerk at the grocery store or the librarian or the traffic cop are not verifying that you are who you say you are, or that you were born on a certain day, or that you live in a certain place. They're all relying on the fact that the state (or non-US equivalent, if applicable) did all of that verification, asking for a birth certificate, and so on, when you applied for the drivers license. They take your ID to be an assertion that you are who you say you are.

Theoretically, that's how it works online, as well. Ideally, you would be able to sign in to your computer once, and from then on wherever you went, be it your company's intranet or your bank account, the site would know who you were and you wouldn't have to sign in again. That's the theory, anyway.

Making that happen is a little bit more complicated. One way is for everybody to simply use a single sign-on "provider" such as Microsoft's Passport service, but that's not necessarily attractive to companies because Microsoft then owns all of their customer data. Another way is by using "federated" identities.

And that's where SAML comes in.

Security Assertion Markup Language, or SAML, is a way for sites to "vouch for" users. In other words, if I sign in to my company's intranet and then try to go to, say, a partner company's site, my company's intranet can vouch for me, telling the partner site who I am so that it doesn't have to ask for another username and password. SAML describes an XML vocabulary for doing that.

For example, check out this sample file from Authenticating Web Services with SAML:

<saml:Assertion 
    MajorVersion="1" MinorVersion="0"
    AssertionID="192.168.19.12.109856"
    Issuer="Issuingauthority.com"
    IssueInstant="2002-06-21T12:02:02Z">
    <saml:Conditions
       NotBefore="2002-06-21T12:02:02Z"
       NotAfter=""2002-06-21T12:12:02Z" />

    <saml:AuthenticationStatement
         AuthenticationMethod="Password"
         AuthenticationInstant="2002-06-21T12:12:02Z">
        <saml:Subject>
            <saml:NameIdentifier 
                     SecurityDomain="relyingdomain.com" 
                     Name="bridget" />
        <saml:Subject>
        <saml:Attribute>
              <saml:AttributeDesignator AttributeName="Department"
                       AttributeNamespace="http://www.informit.com"/>

              <saml:AttributeValue>Editor</saml:AttributeValue>
        </saml:Attribute>
    </saml:AuthenticationStatement>
    <saml:AuthorizationDecisionStatement
           Decision="Permit" 
           Resouce="http://www.informit.com/articles/edit.cgi">
        <saml:Actions Namespace="http://www.informit.com">

               <saml:Action>Execute</saml:Action>
        </saml:Actions>
        <saml:Subject>
             <saml:NameIdentifier 
                 SecurityDomain="relyingdomain.com" 
                 Name="bridget" />
        </saml:Subject>

    <saml:AuthoricationDecisionStatement>
</saml:Assertion>

This SAML statement actually serves several purposes. I've lumped them all together for the sake of brevity, but in reality a message doesn't have to do this much work.

First, note that we have an Assertion of some kind. That Assertion is identifiable, and comes from a particular place. Based on the Conditions, we see that it's only valid during a particular period of time. In this case, we start by noting that a user that can be identified as bridget authenticated with the server using a Password at a particular instant. Based on that, the server asserts that this person is not only bridget, but that bridget has been assigned the attribute of Editor in the http://www.informit.com namespace. Note that the server could have simply replied that this is bridget, or that this person was an Editor and not supplied the information as to how it knew.

Next we have the AuthorizationDecisionStatement, which states that this person, bridget, is allowed to Execute the http://www.informit.com/articles/edit.cgi resource. (Kind of like the blue background on your drivers license that says you can buy a beer.)

All of these messages are carried via SOAP, so they are perfectly suited to Web Services, but remember that they're not foolproof. First of all, you need to make sure that you really trust the party who's making these decisions. (Before you sell them the beer, are they offering you a state-issued ID, or a library card?) Second, you need to make sure that these messages are really coming from the party who's making these decisions. (Is that state-issued ID a fake?) Third, you need to remember that this is simply a means for communicating centralized identification information. You still need to formulate your own security policies.

But at least, with SAML, you have a base to work from.