Adventures in Web Application Develompent by Phil Duba: SAML and ColdFusion

Popular Entries

Top Commenters

Nathan Mische (12)
CFFusionDev (6)
CFdevfusion (6)
Peter Bell (4)
Sean Corfield (3)
Rey Bango (3)
Terrence Ryan (3)
ah7866 (3)
Scott (2)
Jim Priest (2)

Slideshows

Dresser/Changing Table...
Images related to the lay...
Nursery renovations...
Pool Surprises...

Search

Enter your email address to subscribe to this blog.

RSS

AGGREGATORS

SAML and ColdFusion - Part 2

Posted On February 9, 2007 7:42 AM By Phil in SAML,ColdFusion

Ok, I know it has been a while, but I'm ready for part 2 of the SAML and ColdFusion series. In this post, I will talk about the main carrier of information between an Identity Provider and a Service Provider, the Assertion. If you recall from my previous post, a form variable called SAMLResponse containing a Base64 string is submitted. This variable is what contains the Assertion document. The Assertion helps to convey the following information:

Header information which usually identifies the identity provider submitting the assertion and any conditional information used to validate the request
Information relating to the Subject of the Assertion or the user for which the SSO action is being performed
A series of Authentication or Attribute Statements
Digital Signature

Now, I will not go into Digital Signatures in this post, as that is a fairly lengthy topic in and of itself, so look for that post in the future. There are two typs of Statements: Authentication and Attribute.

Authentication Statements - statements that describe how the Subject/user was authenticated at the Identity Provider.

Attribute Statements - statements that contain information and properties associated with the Subject. Within these attribute statements is where the information the Service Provider needs to set up the user's session are usually found.

Ok, enough about all this definition stuff and let's look at the sturture of an Assertion. First, before I continue, some companies have placed a namespace of "saml" before each of the tags in the SAML Assertion. For brevitiy's sake, I am not going to do that (besides, it makes working with the XML easier in CF) but just know that you may see an assertion tag like <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ... >. Without futher adu, let's devle into some SAML XML. Here is a full blown SAML Assertion (minus the XML digital signature):

<Assertion xmlns:"urn:oasis:names:tc:SAML:2.0:assertion"
    AssertionId="353FE620-1143-EBE0-E1C96F56FD89EE2E"
    IssueInstant="2007-01-01 14:30:23Z"
    Version="2.0">
   <Issuer>https://www.identityprovider.com/IDP</Issuer>
   <Conditions NotAfter="2007-01-01 14:31:23Z" NotBefore="2007-01-01

14:30:23Z">
      <AudienceRestriction>
         <Audience>http://www.serviceprovider.com/SP</Audience>
      </AudienceRestriction>
   </Conditions>
   <AuthnStatement AuthnInstant="2007-01-01 14:30:23Z"
         SessionIndex="1234567890">
      <AuthContext>
         <AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:Password
         </AuthnContextClassRef>
      </AuthContext>
   </AuthnStatement>
   <AttributeStatement>
      <Subject>
         <NameID format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
            foppa@identityprovider.com
         </NameID
         <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
      </Subject>
      <Attribute AttributeName="idpSystemID" AttributeNamespace="http://www.identityprovider.com">
         <AttributeValue>foppa21</AttributeValue>
      </Attribute>
</Assertion>

Ok, let's take this one item at a time. In the Assertion tag, you'll notice there are attributes for the id, issued instand, and version. The AssertionId attribute can be used as an internal document reference (uri) elsewhere in the Assertion (this is common in the digital signatures). The Version is important as this is specific to SAML 2.0. Version 1.1 breaks this into a MajorVersion and MinorVersion attribute (1 and 1, respectively).

The next few nodes relate to the Authentication statements described earlier. The Issuer node identifies the source or the Assertion. This cand be used to validate against a refer variable or execute different processing if there is one singular SAML gateway to an application, but many Identity Providers using it. The Conditions node contains a child node and two important attributes. The NotBefore and NotAfter nodes give a time stamp. The time difference should be worked out between the two parties and allow for processing and network latency and should also be in UTC time to avoid server timestamp differences. The AudienceRestriction tag can be used to identify the resulting application the Subject is to be redirected to, particularly if there is more than one application hosted under a domain. Again, business logic can utilize this node-set to execute different logic accordingly.

The AuthnStatement node is nothing more than a reference to how the Subject was identified by the Identity Provider. A Subject node could be put into the AuthnStatement node and the contents of that could be compared to the Subject node defined later as another security check. In this instance, the Subject was password authenticated and that's the only information we are given so this type of check is unavailable.

The AttributeStatement node is where the crux of the information the application needs to login the Subject is contained. The first node is the Subject node. This node contains an identifier and a confirmation method. This can contain things like and email address, X509 subject, Windows Active Directory information, etc. This is usually how the user is identified in the Identity Provider's domain, in our case this is by email address. The Attribute node contains the information that may or may not be needed by the Service Provider to login the user. I say may or may not because a number of times, the Subject will contain the proper information that acts as a foreign key in the Serverice Provider's system, identifying them as an Identity Provider user. In cases like X509, however, it is unrealistic to store this type of information in the Service Provider user area as they most likely will not know what that entry is for the user within the Identity Provider's architecture. The ability to define attributes, like Username, allows for other unique identifiers to be passed to the SAML template for processing.

Well, that's a good overview of a SAML Assertion. Again, this does not cover digital signatures and how to process the SAML, but it should give you an idea when looking at a SAML Assertion of what is going on and what it all means. Next time, I'll look at the Digital Signature and how to read and execute processing against one. Ultimately, I hope to provide a SAML based library of items that can be used to perform authentication, in particular, the Digital Signature verification, as it is very hard to do without having the benefit of a SAML server installed on your system.

Comments (2) |

Print |

Send |

del.icio.us |

Digg It! |

Linking Blogs | 12917 Views

Related Blog Entries

SAML and ColdFusion Part 6 : Validating an Assertion (May 10, 2007)
SAML and ColdFusion Part 5 : Signing a Document (May 1, 2007)
SAML and ColdFusion Part 4 : Setting Up the Library (April 26, 2007)
SAML and ColdFusion Part 3 : XML Digital Signatures (April 16, 2007)
SAML and ColdFusion - Part 1 (December 29, 2006)

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)

For those of you that may have come here while I was updating the code block, I apologize. I haven't quite figured out the <code> block and tinyMCE yet.

# By Phil Duba | 2/9/07 9:11 AM

Over on Part 1 of this series, Jeff Hodges of www.identitymeme.org provides a link to a great article he wrote on learning SAML: http://identitymeme.org/archives/2006/09/08/how-to...

# By Phil | 2/9/07 6:16 PM

philduba.com