SAML: It's Not just for Web services

Introduction

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between security domains. SAML is a product of the OASIS Security Services Technical Committee. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. However, there are limitations to SAML 1.1 for that purpose and, in fact, the problem that SAML 1.1 solves more efficiently is the authentication and authorization of SOAP Web services by using SAML as a WS-Security token. Useful technologies find a way to be relevant and find unintended ways of fitting into the vast technology landscape. For example, Kerberos was an integral part of the ill-fated DCE (Distributed Computing Environment) and while DCE has clearly been dead a long time, Kerberos has been a core Microsoft security component.

SAML 2 does include features for resolving some of the issues with multi-site authentication using a Web browser. Today, many organizations are now in the SAML "zone of indecision" as to whether you stay with version 1.1 or move to 2.0.

In preparation for a project recently that would involve securing a portal application and associated Web applications using SAML for SSO, I did what I normal do before engaging with the client -- email my personal list of experts and conduct a search on SAML. What became immediately apparent to me was the lack of substantive documents on this subject.

Findings, Conclusions and Recommendations

One article that was recommended by a number of individuals was "Configuring Single Sign-On using SAML in WebLogic Server 9.2" by Vikrant Sawant at http://www.oracle.com/technology/pub/articles/dev2arch/2006/12/sso-with-saml.html.
Even though this article is somewhat dated, it remains the seminal contribution to this somewhat arcane technology area. I first read it about a year and a half ago when I was on a project where we were using SAML for SSO within an SOA environment.

While this article is a valid "hello world" example for SAML, it does not provide guidance for real world implementations for the following reasons:

• An Oracle WebLogic instance is used as the IdP (Identity Provider), instead of a more enterprise-grade access management application.
• A local LDAP instance is used for both the IdP and the Service Provider (SP) as opposed to a "virtual user."
• The resulting SAML assertion does not include a "Groups" attribute, which is required for providing RBAC (Role-based Access Control).
• Problem detection needs to include more than just source and destination server log analysis, and enabling application server debugging and filtering for SAML messages.
• Trusted Partner key and certificate configurations require more than just configuring a private key.
• The security model is configuration in a standalone environment, rather than a cluster-aware, production-type environment.

The purpose of this article is to provide a view into how SAML security can be architected and implemented as an enterprise-wide platform.

An Enterprise-grade IdP

While it is clearly viable to use Oracle WebLogic as an IdP, it does not have the features of a true access management environment, such as, Sun Access Manager, Tivoli Access Manager, Oracle Access Manager, etc. Using Oracle Weblogic Server as an IdP, does not provide the session management functionality similar to what, for example, Sun Access Manager provides. SAML by being supported by many vendors provides a beyond the intranet SSO solution. Figure 1 depicts a reference architecture using

• Sun Access Manager 7.1 as an IdP, and;
• WebLogic Server 10.3 as a SP.

Figure 1 - Conceptual SAML Architecture - include LDAP repository on this

While many IdP vendors support both the format and protocol, configuring SAML becomes somewhat of a mapping exercise, since vendor implementations differ and include their own internal constructs. With Oracle purchasing Sun, it remains to be seen where Sun Access Manager will be retired in favor of Oracle Access Manager, itself another acquisition by Oracle, which was formerly known as Oblix. And while I was assured by a number of SAML-aware technologists that implementing SAML as an IdP within Sun Access Manager is similar to implementing SAML as an IdP within Weblogic, the configuration was not as symmetrical, so to speak, as I anticipated.

Figure 2 - View of Sun Access Manager 7.1 Console for SAML Trusted Partner Configuration

Sun Access Manager Source ID is an opaque data type that is the SHA1, expressed in Base64 of the string of the "protocol://hostname:port" of the SP site, although the SP does not need to know about this ID. More specifically, the Trusted Partner configuration window captures the following information:

IdP and SP User Repositories

Within the SAML authentication model, The IdP requires a local repository as the "system of record" for the authenticated user. Typically, the user will be contained in local LDAP repository. In turn, when invoking a protected resource on the SP, the SP can use the same local LDAP repository to authenticate a user. However, while this model may be appropriate for intranet applications, it is not viable for cross-site, internet applications and really does not take advantage of the SAML SSO assertion model.

Alternatively, the SP can be configured to use a "virtual user." Figure 3 depicts the window for creating an asserting party in the WebLogic console to allow for virtual users. This option configured on the SP allows the SAML Identity Asserter to instantiate user and group Principal(s), based on the incoming assertion. The configuration also requires that a SAML Authentication provider be configured for the security realm. This configuration enables the user to be logged in as a virtual user -- a user that does not correspond to any locally-known user.

Figure 3 - View of WebLogic Server 10.3 Console for Creating an Asserting Party

Specifically, the Create Asserting Party window captures the following information:

Specifying the SAML Assertion

JEE applications, including portals, are usually designed and developed to provide RBAC functionality. This requires group to role mapping by the application in conjunction with application server configuration. Within the SAML Assertion model, the SP needs to indicate whether it will be processing for group behavior (see Figure 3) in the protected application and the user needs to be a member of a group within the IdP's local (LDAP) repository. Processing the assertion, results in a "Groups" attribute (see Listing 1), which is mapped to JAAS Principal object(s) by the SP's authenticator.

Listing 1 - SAML Assertion elements related to the incoming user

<Subject>
  <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">auser</NameIdentifier>
   <SubjectConfirmation>
  <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</ConfirmationMethod> 
   </SubjectConfirmation>
</Subject>
<Attribute AttributeName="Groups" AttributeNamespace="urn:bea:security:saml:groups">
<AttributeValue>atlantis</AttributeValue> 
</Attribute>

Figure 3 has a flag for indicating whether the SAML Identity Asserter should look for a SAML AttributeStatement containing group names when processing an incoming assertion. This requires that the application be enabled for RBAC using Web.xml and the associated WebLogic.xml, Listings 2 and 3, respectively. Within the application, resources contained in the "working" directory require that the incoming user be a member of the "atlantis" group. It is important to note that within JAAS and JEE a Principal can either be a specific user or a group.

Listing 2 - Web.xml in the SP

<security-constraint>
 <web-resource-collection>
  <web-resource-name>TheSecurePages</web-resource-name>
  <description>Pages accessible by authorized users.</description>
  <url-pattern>/working/*</url-pattern>
  <http-method>GET</http-method>
 </web-resource-collection>
 <auth-constraint>
  <description>Roles who have access.</description>
  <role-name> atlantis </role-name>
 </auth-constraint>
</security-constraint>
<login-config>
 <auth-method>CLIENT-CERT</auth-method>
 <realm-name>myrealm</realm-name>
</login-config>
<security-role>
 <description>These are the roles who have access.</description>
 <role-name> atlantis </role-name>
</security-role>
</web-app>

Listing 3 - Weblogic.xml in the SP

...
 <security-role-assignment>
  <role-name> atlantis </role-name>
  <principal-name> atlantis </principal-name>  
 </security-role-assignment>
 <context-root>TargetApplication</context-root>
</weblogic-web-app>

Effective IdP and SP Error Resolution

For middleware error detection and resolution, within Oracle WebLogic or any application server, being able to enable SAML security debugging for both the Idp and SP and/or directly "tailing" the logs is a standard testing procedure. When using SAML for Web application Browser authentication, another tool is tcpmon. tcpmon is an open-source utility for monitoring the data flowing on a TCP connection; it is used by configuring it in-between a client and a server.

If using Firefox for unit testing Live HTTP headers is a good plug-in in order to test the required SAML site redirection for authentication. Live HTTP headers is useful in order to debug how the SP and IdP are redirecting the Browser during authentication and assertion processing at the HTTP protocol-level.

Establishing the Partner Trust Relationship

Key configuration requires more than configuring just a private key as indicated in the referenced article. That type of process is only good for development mode. It is strongly recommended to acquire a properly trusted certificate from a valid Certificate Authority, such as, VeriSign.

For trusted partner SAML integration, there are, at a minimum, two keys needed:

• A private key used by the Assertion Consumer Service on the SP site to provide SSL client identity functionality for the IdP (see Figure 1).
• A public key or certificate trusted for verifying signatures on assertions from the Asserting Party. The certificate must be registered in the SAML Identity Asserter's certificate registry and it must be configured for Browser/POST profile.

Production Environment vs. Standalone

Middleware applications that require SSO or cross-domain integration usually require a degree of scalability or fault tolerant replication from the middleware environment. With respect to the middleware SAML security model, this would require that source and destination site URLs would need to reflect the virtual addresses of load balancers, other than that the model remains relatively intact.

Implications: SAML 2.0 features

The decision to move to SAML 2.0, for many organizations, will most likely be based on whether the new features are compelling enough to force the software organization to:

• Upgrade access manager applications;
• Reengineer SP configurations, and;
• Rework application logic.

SAML 2.0 includes a Single Logout Protocol, which supports near-simultaneous logout of sessions of Web SSO participants. For SAML 1.1, this type of "universal logout" functionality must be engineered in conjunction with the IdP's inherent cookie management behavior. For example, after authenticating and achieved single sign-on to multiple service providers, the user could be automatically logged out of all of those service providers at the request of the identity provider. The <AuthenticationStatement> element has been renamed to <AuthnStatement>. The <AuthnStatement> element now supports the concept of a session in support of single logout and other session management requirements.

The SAML schema extensibility mechanism has been updated. XSD element substitution has been blocked in favor of type extension. The <xs:anyAttribute> wildcard has been added selectively to structures where it has been deemed valuable to add arbitrary attributes without having to create a schema extension, such as, subject confirmation data and SAML attributes. This is a useful modification, since real world implementations sometimes require transient, in flight information that needs to be contained in an assertion, such as, the login context of the incoming user. For example, an authenticated user that may have the ability to authenticate to the application from multiple locations and the application may be interested in knowing that information.

This article has been based on Browser/POST profile. The two original web browser profiles (Browser/Artifact and Browser/POST) in SAML 1.1 have been consolidated into a single Web Browser SSO Profile. Although, an enhanced client and proxy SSO profile has been added, which again results in two distinct profiles.

To recommend SAML 2.0 over SAML 1.1 is not just a matter of keeping current with technology, SAML 2 provides a complete distributed SSO experience; whereas, SAML 1.1 has some serious shortcomings. Lastly, a word to the recalcitrant adopter, change is neither benign nor nefarious, it just is.

Frank Teti is an Architect with Ironworks and was formerly part of Oracle/BEA Systems SOA/BPM practice. He can be reached at [email protected].

References

SAML, JAAS, & Role-Based Access Control: Part 1 and 2, http://www.ddj.com/java/209100671.