I recently had the opportunity to help a customer implement a web services interface that relied on SAML for authentication. Doing so provided a couple of insights that I found interesting.
What the Heck is SAML?
If you already know what SAML is and why it can be useful, feel free to skip to the next section.
SAML stands for Secure Assertion Markup Language. More than just a language, though, SAML is a standardized protocol for requesting, creating, and consuming SAML tokens.
SAML tokens consist of identity information specified in SAML language. In version 1 of the protocol, SAML was a way for one party to authenticate an individual and then “assert” to another party that the individual was successfully authenticated. Version 2 of the protocol provides more support for asserting additional attributes about the authenticated individual and a somewhat more robust protocol definition.
The “classic” SAML version 2 protocol flow starts with a user, presumably using a web browser, pointing to the URL for some service. The web server hosting the URL redirects the browser to a third-party, known as an Identity Provider (IdP), with a SAML authentication request. The IdP authenticates the requester and creates a SAML response token which is returned to the browser and back to the web server. The application (i.e. the web app represented by the URL) – usually referred to as the service provider or relying party – verifies that the SAML response token came from a trusted IdP and retrieves the authenticated userID from it.
One minor swizzle on this protocol is that the end user starts at the URL of the IdP and is then redirected back to the service provider.
Why go through all this rigmarole?
The Beauty of SAML
The major benefit is that it relieves the application from having to create and maintain its own user registry. Administering and protecting such a registry can be quite costly, especially when it may contain tens or hundreds of thousands — or even millions — of users.
You must go through a one-time setup process with the IdP(s) you intend to use. This process exchanges information between the IdP and the service provider so they can verify request and response tokens, know the URL to which the IdP should redirect SAML responses (although this can be contained in the SAML request token also), and other housekeeping-like chores.
There are several third-party IdP services available today. Some are free and some charge for their services. The difference between these IdPs is primarily in the support they provide, additional functionality related to identity attributes and management, etc.
If you just want plain old userID and password authentication, with basic security, for a relatively small number of users, then a free IdP is a good way to go.
Free IdPs can also be useful for developing SAML-based applications. Because of the SAML standard, you can get your application working using a free IdP and then switch to a more full-service IdP.
Web Service + SAML Project Overview
The project I was involved in was a web service API for a company in the health care industry.
The web service interface was implemented in a WebSphere Application Server (WAS). The web service accessed data from a database that happened to be hosted on an IBM i system – although that had no bearing on how SAML was implemented. The IBM i data is, of course, protected with IBM i user profiles. The data available via the web service API depends on which user profile is attempting to access that data.
Third-party partners of my customer were previously able to access my customer’s IBM i system with a user profile specific to each partner. Each partner was able to retrieve data for only their company and then transfer that data into their company’s systems. Partners then incorporated this data into their applications.
This existing function drove some of the decisions we made regarding the userID names registered with the IdP.
Given that existing partners already had user profiles on the IBM i, my customer decided that those partners would register with the IdP using their IBM i user profile name as the IdP userID name.
New third-party users of the web services API will need to register with the IdP and also with my customer in order to get their user profile created.
From a security point of view, the advantages of using SAML are:
- User profiles representing partners do not have passwords.
Since the customer is authenticating with the IdP, there’s no need to manage passwords in their user profiles. - No password management means no forgotten or expired passwords and no profiles disabled due to too many invalid signon attempts.
- The web service API is the only interface partners can use. Since they must go through the IdP to authenticate to the IBM i, they can’t use unexpected or unintended IBM i interfaces. This means much less effort and worry for system administrators; they don’t have to worry about PUBLIC authority to unrelated resources on their systems.
Lessons Learned
I learned several things as a result of working on this project.
1. WebSphere’s SAML TAI is a Pain!
Overall, WebSphere is still more complicated than it should be, and it’s not very well documented.
WebSphere claims that you can implement SAML at the WebSphere container level and hide all of those details from the application. This is done through things with “obvious” names like Trust Association Interceptors.
There’s a lot of documentation that tells you how to use the SAML TAI for your own applications, but the documentation provides conflicting details in different places.
Most unfortunately, the only documentation for actually implementing the SAML TAI is based specifically on one sample WAS application. The sample application is sort of a gateway that consumes a SAML token and then can call any of a number of other applications. Those same instructions do not work for an application that merely wishes to use the identity represented by the SAML token. IBM fails to provide the information that indicates how the SAML identity can be accessed by, or assigned to, the container hosting the application.
2. An EJB May Be Your Best Bet
In short, it was extremely frustrating trying to use the “convenient” WebSphere SAML TAI. We finally wrote our own Java SAML verification and consumption code (an EJB), and the web service implementation app just used that to access the authenticated userID. Much easier.
3. Free IdP Services Allow You to Try Before You Buy
This project uncovered the fact that there are some good, free IdP services available on the internet so you don’t have to subscribe to a for-fee service just to evaluate whether or not to use SAML. This makes it much more feasible to contemplate using SAML in future projects.
4. Use EIM with SAML for More Flexibility
This project also identified another potentially powerful way to exploit Enterprise Identity Mapping (EIM).
Rather than matching the username that is authenticated by the IdP the name of the user profile needed to process the request, consider using EIM. In effect, EIM allows for manipulating the ID used for authentication independently of the ID used for access control.
By using EIM in this particular case, partners wouldn’t know the name of the user profile being used to process their request on the backend. This could have several benefits:
- The end user has to worry only about the userID.
- Administrators could change the profile being used without getting the partner involved. That means they can not only change the resources to which the ID is authorized, but they can change the ID being used to authorize those resources and they can add or remove additional authentication userIDs associated with the authorization ID, without any involvement of any of those end users.
- A single partner could use multiple authentication identities but the IBM I system administrator has only one user profile to process those requests on the IBM i. Plus, only one profile to manage, and no passwords to manage.
Summary
This was certainly an interesting and eye-opening project. My previous projects with SAML focused more on identifying the protocol as the best alternative. Being involved in the nitty-gritty implementation, with an IBM i in the mix to boot, provideds a different perspective and highlighted additional ways to exploit SAML and improve security.
I’m looking forward to the next project!
