With software delivered as a service on the rise and more organizations moving toward service-orientated architectures (SOA), vulnerabilities in such environments are becoming ripe targets for rogue attackers. This tendency has created a need for specially designed techniques to deal with security, up next I will describe the approach set forth by the Security Assertion Markup Language (SAML).
The current areas leveraging SAML include single sign-on schemes like those developed by the Liberty Alliance Project - similar in nature to the Open-ID project - to more general purpose areas like those used in SOAP based services via WS-Security. The basis for understanding SAML lies in its assertion mechanism which is the cornerstone for the language. Listing 1-1 shows a SAML assertion.
Listing 1-1 SAML assertion
<saml:Assertion xmlns:saml=â urn:oasis:names:tc:SAML:2.0:assertionâ Version="2.0" IssueInstant="2008-10-15T12:00:00Z"> <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity> http://www.acme.org </saml:Issuer> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> email@example.com </saml:NameID> </saml:Subject> <saml:Conditions NotBefore="2008-10-15T12:00:00Z" NotOnOrAfter="2008-10-15T12:10:00Z"> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2008-10-15T12:00:00Z" SessionIndex="67775277772"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion>
As you can observe in this last listing, a SAML assertion consists of multiple security statements made in reference to a subject. An assertion's values can range from fundamental elements (like who is making an assertion on a subject) to more elaborate topics like the times and dates an assertion is valid for or even conditionals that make an assertion more stringent.
Assertions are exchanged between a SAML authority â " the one providing the assertion â " and a SAML relying party â " the one requesting the assertion. Depending on the nature of the exchange, a third party or 'asserted' can also be involved. This third party scenario fits the single sign-on scheme where the 'asserted' is an end user attempting to access a resource, kicking off the SAML authority and SAML relying party exchange. For other SAML exchanges, the 'asserted' is simply application logic that forms part of a SAML relying party.
The appeal for incorporating something like SAML into a SOA security scheme lies in its platform neutrality. Take the case of the <NameID> element inside the <NameSubject> of the earlier SAML assertion. In this particular case, the assertion is being made on an email address, but this is just one case scenario. SAML equally supports identities like X.509 or Kerberos which are often common in enterprise settings, thus shielding an application from a particular platform.
Taking the same scenario as the single sign-on approach; instead of locking-in an application â " and users â " into using email addresses, a SAML based architecture allows the 'asserted' to provide credentials in things like digitally signed certificates(X.509) or Kerberos, allowing a security strategy to be based on wider and often pre-existing security infrastructure.
In essence the 'Yes'/'No' answer to the main security question of 'Is this party who he says he is?' is answered through SAML tokens, and not the particularities of certain platforms which often have proprietary ways of asserting (e.g timeouts, fail overs, conditions). SAML standardizes this assertion process.
Take another case scenario involving a SOAP service. Listing 1-2 illustrates a SAML snippet that would be embedded in the body of a SOAP request.
Listing 1-2 SAML assertion in SOAP request
<?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env=â http://www.w3.org/2003/05/soap/envelope/â > <env:Body> <samlp:AttributeQuery xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="aaf23196-1773-2113-474a-fe114412ab72" Version="2.0" IssueInstant="2008-10-15T20:31:40Z"> <saml:Issuer>http://example.sp.com</saml:Issuer> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"> C=US, O=TECHTARGET-TEST, OU=User, CNfirstname.lastname@example.org </saml:NameID> </saml:Subject> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:184.108.40.206" FriendlyName="givenName"> </saml:Attribute> </samlp:AttributeQuery> </env:Body> </env:Envelope>
Note the <NameID> value now pointing to an X.509 value. A security check is still being performed on a client-server SOAP exchange, but since the assertion is based on SAML tokens, this allows looser coupling and the capability to switch over to something like email addresses or kerberos if the need requires, which is one of the primary goals of a SOA.
So where does SAML fit in with initiatives like Open-ID, Liberty Alliance and web services in general? SAML operates at the very bottom of the application stack â " markup â " so its unlikely you will see its explicit mention in such projects that address security in a more holistic fashion. Nevertheless, SAML's granularity make it all that powerful and suited for more general purpose security concerns involving cloud computing.
Currently, there are already various open source SAML implementations to further extend SAML's reach beyond the projects cited earlier. So if your SOA projects require incorporating security checks that have the same loose coupling behavior as your business logic, give SAML a closer look, its the XML equivalent for a distributed security.
About the author
Daniel Rubio is an independent technology consultant with over 10 years of experience in enterprise and web-based software, he blogs regularly on these and other software areas.
This was first published in November 2008