SSO – Single Sign On

Early time-sharing systems provided a security model for the underlying file system that provided many services with a single log-in. Access to any branch of the file system was determined by its “ownership” via the familiar Read, Write, Execute flags for Owner, Group, World.

It wasn’t too long before Owner, Group, World was too restrictive and Roles/Groups were introduced where any user could belong to multiple Roles/Groups and access was determined by the least restrictive flag for the Groups to which that user belonged.

Clusters of very similar machine types and operating systems, often with a high speed interconnect between the machines and their devices permitted single sign-on to the systems in the cluster. Several system vendors provided proprietary clusters.

Microsoft Windows Domains pushed the cluster idea out to the LAN, where multiple LAN vendors had already pioneered single log on to the LAN. Microsoft Windows Primary and secondary Domain Controllers on the LAN synchronized user identity data to provide single log on to the domain for every user. We used Domains in our office when we still had a modem connection to the Internet. With time, however, the Internet eventually providing reasonable speed access to application/service servers around the world, such applications proliferated. There seems to be no end to the creativity of application developers on the web. But now users were having to provide separate log on authentication data for each application or service. In the small this was manageable, however it wasn’t too long before what NIST has called “password fatigue” set in. Internet users, wanting to access multiple services, started to

  • write down their (service or web site) usernames and passwords in documents, spreadsheets, and even on yellow Post-its stuck to their monitor.
  • re-use usernames and passwords
  • use overly simple passwords
  • cheat with the same username (often an email address) and simple passwords both of which are used across multiple applications and services
  • let their applications remember usernames and passwords, often in world readable cookies on the workstation.
  • Lose their usernames and password and ask system administrators (or special privileged software) to re-issue them for the user with imperfect memory.

Aside from being an expensive administrative mess, using multiple usernames and passwords was and still is decidedly insecure. Wouldn’t it be better if a user could sign on to a single service, which in turn could provide automated sign on to application/service servers? Well, yes and no. If such an “identity server” were compromised, then all of its user clients could be totally compromised. On the other hand, great care would probably be given to the construction of such a server, to the secure use of connections to it (e.g. via the latest SSL/TLS), and to the encryption of identity data held within it. With some care, this “IDaaS” could also support mobile devices, business partners (e.g. those in a supply chain), and even the Internet of Things.

The above diagram shows an Identity Provider, IdP, which services multiple application service providers, and multiple clients. This diagram implies that the multiple users belong to the same enterprise with a common Name Server and a common IdP. While it would make for a messier diagram, users from multiple enterprises that need to share applications could also be supported.

Provisioning. The users request application provisioning, either as an initial sign-up or as the first time the application is used. The IdP not only provisions the user, but also learns the protocols by which the user (and IdP) can communicate with the application. This includes learning the type of tokens the application will accept for authentication.

Such complexity tends to bloat IdP implementations, and different schemes for lightweight (or “lighter weight”) identity servers have been proposed that take advantage of existing name servers, identity managers, etc. Some vendors split up their implementation into multiple products. For example, some vendors define bridge products that translate one protocol or token format to a different one. History shows that this complexity will pass as standards converge and server speeds increase making full functionality in a single IdP product fast and scalable. Such optimism aside, there are at least a dozen vendors of Single Sign On identity providers today that address this complexity to varying degrees. Each product comes with its own system integration problems that an enterprise must weigh as it selects a Single Sign On vendor.

When a vendor collapses the IdP and the Name Server into a single product, the result can be interesting. When this product is placed in the cloud, it can be even more interesting. Some security companies have such a product, as does Microsoft with its Azure Active Directory.

I see a lot of “sign on with SocialSite” buttons on various vendor sites. The superficial idea is to allow your SocialSite to be an IdP for you. Pick your favorite half dozen social sites, and one is probably listed. There is a privacy issue here: Signing on with SocialSite gives the vendor access to all the information on your social site. This may be ok, but then again, you may not want that vendor or its customers to be grabbing information off your site or worse, posting information to your site. For me at least, I never log in using a social site.

My next IAM post is here.


Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: