Java Development News:

A Proposal for SAML communications with JAAS

By David Whitehurst

29 Jul 2005 |


Most Enterprise developers have created login pages for web applications and they've probably not given it much thought. While the internet is wide open, web applications require more security. Most systems of authentication and authorization are created for web applications individually. Were Enterprise applications or systems considered collectively during the design process? Probably not. And, identity management is needed for most Enterprise applications today. Many development projects never considered application security beyond the application scope, across multiple domains, or among internal systems. To add to these problems, businesses now want to share proprietary applications with other business partners. What's needed is an identity management system that's interoperable with any Enterprise system regardless of it's physical or virtual location.

An identity management solution is needed that the Enterprise community can implement and security communications need to be understood by all. The Security Assertion Markup Language (SAML) provides a good answer because it's an authentication and authorization language, using XML, and can be passed around the net using SOAP. The Enterprise community should continue to consider its use of SAML. Let's look at the Enterprise problem in more detail.

The Problem

The problem is very clear. People want to use computers and they want to use them securely and safely and they don't want to login to every application they visit. These applications are all virtually close to each other and the user doesn't see the domain borders. And, the user could care less about a login-authentication callback or some J2EE acronym called JAAS. Every business with proprietary data hosted on the web will protect it with some form of authentication and authorization mechanism. And, whether this business uses a single user and a password in a deployment descriptor or thousands of users and passwords to be checked by a custom login module, they still must provide some checking mechanism for their users. This also extends beyond the application context. They may require access checking across multiple domains.

Somebody, several years ago came up with the first mouse-trap Single Sign-On (SSO) solution and presented it to his boss. He drew on the white board, and they all said "ah, by George, he's got it". "We can create a central login site and then force all of our third party sites to use this man's solution. It's perfect". Well, not quite. I've seen a few of these implementations and while I was the third party in every case, they all had the same problem. Each solution did not have a neutral and interoperable authentication and authorization service. Put the Java Authentication and Authorization Service (JAAS) out of your mind for now. We'll discuss its involvement further into this article.

The reason why most SSO implementations are failures is because a standard implementation does not exist and each SSO implementation is driven by a specific enterprise solution. The problem domain is defined by this business and once their unique SSO problem is solved, implementation instructions are given to their partner sites with no regard to the sometimes different security needs of the partner.

A Solution

Enter SAML. There are many use-cases that have been documented in the pursuit of the SSO solution. I disagree with many of them. The answer is the isolation of a SAML service. SAML was developed specifically for authentication and authorization. The SAML specifications define both request and response types. SAML is XML and meant to be wrapped in a SOAP wrapper and sent across HTTP or HTTPS. SAML requests and responses need to be served as a web service.

A SAML server using XML across an HTTPS protocol would be more than sufficient to solve this SSO problem. An XML web service would provide an interoperable authentication and authorization web service that could be used by either .NET or J2EE. Also, ASP,PERL,PHP, etc. could viably use it as well. You should isolate the SAML service from the SSO solution. Things are much simpler if you centralize the authentication and authorization for all sites by using a single SAML server.

The SAML server will be very complex internally, however, the simplicity is it's input and outputs. The server would accept a request for a SAML response that would provide authentication and authorization information based on a small number of request inputs. The response from the server is called a SAML assertion. The SAML specification glossary defines an assertion as "... an XML response containing data that's either authentication, attribute, or authorization information about the subject with respect to a specified resource.". The SAML server is essentially federated JAAS.

Now, I didn't say that SAML replaces JAAS. It's similar to JAAS in that it can perform some of the same functionality just on a higher level and across applications, servers, and even domains. So, yes, we'll still need JAAS. But, before we discuss the SSO solution, let's look at SAML from a high level. A diagram is provided here in figure 1.0 that shows 3 companies and a single user's use of SAML.

View larger image

Figure 1.0 Basic three site SSO using SAML Service

The initial login does not have to be at the MainCompany's application. Each company would require a portal servlet. This servlet would be a very lightweight application that would talk with the SAML service and set/reset the JAAS security information on this site. A token is needed and it could be created within the servlet or requested of the SAML service. The token would be given to the SAML service along with a hostname ID. An ID would be more secure but its purpose would be for the SAML service to provide the authentication and authorization information needed for the specific main or partner site.

The beauty of the SAML solution is that each site would need the same lightweight portal servlet. The servlet on initial login, could redirect to an already implemented JAAS secured application. An example portal servlet that might work on any site is shown here in Listing 1.0

Listing 1 Basic Common SAML Portal Servlet

* Example SAML portal servlet
public class SAMLPortal extends HttpServlet {
  public void doGet(HttpServletRequest request,    HttpServletResponse response) 
 throws ServletException, IOException {
     String token = null;
     String hostID = null;
     // get parameters
     token = request.getParameter("token");
     hostID = getParameter("hostID");
     // scenario 2
     if (token != null) {
response.sendRedirect("" );
     // scenario 1
     } else {
       token = Util.getToken();
response.sendRedirect("" );

Notice that in scenario 1 a Utility object gets a token. This token will be given to myapp1, however, the user will still authenticate at myapp1 using an existing JAAS implementation. The token will be used on links to other sites along with the hard-coded host identification (hostID). In this case, the existing code of myapp1 does not change. In scenario 2, however, the token is given, meaning the user probably has authenticated already. In this case, the Utility object passes the token and the host identification (hostID) to the SAML service. A lot will go on behind the authenticate method. The token and the hostID are passed along to the SAML server and if the proper assertion is returned, the Utility object takes the information and uses it to tell JAAS that this user (principal) has already authenticated. Simple right?

There two very difficult aspects to this solution. First, a SAML identity management server (service) has to be developed. This server will be complex. A good deal of administration will be needed. This SAML authority has to be administered and maintained for all businesses that participate. This could be somewhat difficult in itself. Secondly, the Utility object discussed above is quite complex as well. This object has to present web service requests and receive their responses and also it has to interact with the JAAS security realms for the applications that use SAML.


We should consider SAML collectively as an Enterprise community before our executive management provides another board room SSO solution that we can't deal with. While SSO is a very interesting issue that businesses are trying to resolve, we, as an open technical community, should develop and share a J2EE identity management service using SAML as the communication choice. SAML is formed using XML and can be wrapped with SOAP. This makes it perfect for a web service that can be hosted anywhere. Also, it creates a neutral source of security information to be used between businesses. SAML is the choice for identity management, however, a SAML service would not be a trivial undertaking. The point of this article is to convince you, the public, that SAML is the only choice for identity management. Why create something that has already been created for you?

The administration and management of security data within a SAML server would be a difficult task. The beauty of SAML is the interoperable communication and the neutrality of the service, i.e. the addition of new security measures or secure application partnerships don't require unusually high development costs. A SAML service would remove any implementation prejudices and each using Enterprise would interface to the service in the same manner. The communication methods would be very clear and well documented too.

SAML is free and is maintained by Oasis, a group of standards committee members and contributors. You can get more information at:


David Whitehurst is the Web Architect and Software Development Manager for iSKY LLC, a Real-Time Customer Care Company. He has spent the greatest part of his 22 year career creating new user interface system designs and making business systems better. David has been using object oriented systems and technologies for over 10 years David has leveraged both Java and the open source community for what is needed to accomplish his goals at a technical or development level. He spends most of his free time at night working on improving the use-of and implementation of open source software technologies. David can be reached by email at . His personal website is