Feb

14

SaaS and the Case for Single Sign-On

Posted by Keith McMillan

February 14, 2008 | 1 Comment

Corporate IT departments are incorporating a new way of meeting corporate IT needs, called Software as a Service (SaaS).  SaaS promises outsourced application management, reduced infrastructure costs, and easily terminated services if needs change. Whether SaaS delivers on these promises is the subject of another post, but it’s certain that SaaS presents some compelling reasons, to both the providers and consumers of services, to adopt cross-domain single-sign on (SSO).

The SaaS Model

SaaS was popularized by services such as SalesForce.com, and has been making slow and quiet inroads into the corporate environment. The fundamental SaaS business proposition is this: rather than purchase a software package and install it within the corporate enterprise, I lease access to the services provided by the software on a month-to-month or yearly basis. For me as consumer, this has a number of attractive features:

This business vision is compelling, but SaaS presents challenges around security, challenges to both the provider and the consumer of the services. These challenges are best answered by the use single sign-on, where the user’s credentials are managed by the consumer rather than the provider of services.

Single Sign-On

Single sign-on allows users to enter their credentials once (at the start of the day) and then have systems coordinate so that the user’s identity is passed from one system to the next. Single sign-on solutions are built on trust relationships between systems. Users aren’t asked to enter their logins and passwords again, the systems keep track of who they are.

SSO has been around for a while now, probably the best known systems being CA’s Siteminder, Oracle’s CoreID, and IBM’s Tivoli Identity Manager. There are also a couple of interoperability standards in play as well as pure proprietary solutions, OASIS’ Security Assertion Markup Language (SAML) and OpenID.

I blogged earlier about the addition of some large players to the OpenID board, which makes it an interesting protocol to consider, and I provided a custom implementation of the OASIS Security Assertion Markup Language (SAML) for a company that was providing business-to-business services on line over the Internet. I also wrote an article for CSO Magazine’s online column Caveat in 2006, explaining the fundamentals. Beware of that article, it’s dense reading: there was a word limit, and lots of facts to get across.

To date, single sign-on solutions have not gained widespread adoption because they didn’t really provide a compelling business proposition. The advent of Sarbanes-Oxley in the United States has provided some incentive to implement SSO, as it mandates strong controls on access to information, and this is most easily achieved with SSO in place. The move towards SaaS provides organizations moving this way with compelling reasons for single sign-on as well.

SaaS Consumers Want SSO

SaaS presents security professionals within the business with a new spin on existing challenges. Security professionals talk about two concepts: authentication and authorization. Authentication is the process of proving a user is who they say they are. Users present some form of credentials to authenticate themselves. In many enterprises, these credentials are your login and a password.

User authentication credentials are one of the most important things that an IT department manages. The logins and passwords, or other authentication components are literally the keys that unlock information within the enterprise. It’s no surprise that IT departments want to exercise strict control over these credentials. This includes enforcing such things as

IT departments don’t want to provide copies of the authentication database to anyone, even their own employees, let alone an outside provider of services. Providing this information to anyone is asking that they abuse it, and the right to access it is usually extremely limited.

IT departments want to be able to quickly and easily remove access for an employee who no longer needs it, for whatever reason.

All of this argues for these departments keeping close control over this information, and so it would be much simpler for the consumer if the SaaS service provider simply could accept their assurances that a user is authenticated, and to allow the consumer to provide what their rights are. This is the definition of single sign-on.

Service Providers Want SSO

SaaS providers also want single sign-on, for many of the same reasons that subscribers do, and some additional reasons of their own.

While providers could create their applications with all the same sorts of rules around password complexity, reuse and other controls that we outlined above,  frankly those are a lot of rules, with a lot of permutations to get right. That increases the risk to their product, and in turn increases their liability should they get something wrong in the implementation. Then there’s always that next subscriber, with yet another control that you don’t already have, such as “password must contain mixed case” or “password must contain at least one non-letter”. Since the subscriber has already implemented these rules for themselves, and they want to take responsibility for authenticating their employees, better to let them.

As we already mentioned, IT departments are justifiably hesitant to provide copies of their database of authentication credentials. It simply runs against the grain for a corporate security officer to allow a complete copy of their authentication information out the door, under any circumstances. It’s like sending someone a copy of all the keys to your building. Implementing an SSO solution makes this unnecessary.

Finally, without an SSO solution, the SaaS provider faces a significant challenge in trying to synchronize their subscriber’s database (all of their subscribers’ databases, in all the various forms they can take) with their own database of users, and to keep it up to date with regular additions, terminations, and changes in access rights. This challenge is fraught with peril, and there is a much easier way, let the subscriber manage the information.

Single sign-on is a nice tool for an enterprise, in the sense of “that’s nice, but do we really need it”? Once that enterprise starts to use SaaS, single sign-on moves from a nice tool to an essential one. Without it, you’re only making life difficult for yourself and your subscribers.


Comments

RSS feed | Trackback URI

1 Comment »

Comment by Peter H Coffin
2008-02-14 20:36:36

Heck, employees want SSO. All those bullet-tick requirements for passwords, combined with an ever-increasing number of things wot want authentication means that some employees will spend literally hours several times a year just changing passwords, and (the worst of all possible sins) writing them down as there’s no possibly way to remember 20 different passwords on different systems and applications, some of which may not have been touched since the LAST password dance. As a wild guess, any corporation that can manage to roll ALL of its authentication into a single system will probably end up saving at least a man-day per employee of time spent otherwise dealing with passwords, including remembering, resetting, changing and updating password-related documentation.

Reply to this comment
 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll