Despite not being even minutely related, passwords and zippers have loads of similarities. They are both quite old and, despite their respective ages, have survived the onslaught of time. They are ubiquitous and extremely hard to replace though half attempts are only being made now.
Let’s cast the zipper aside for now because it’s quite irrelevant here. But the password, or rather the proliferation of it fuelled by personal and work related web transactions and the need for multiple user accounts, has made it quite a pain. How much ever your IQ is, it’s so difficult to remember tens of passwords leading to a situation called password fatigue. You find a workaround and it weakens security. It does seem like a minor issue but can spawn big problems for enterprises and businesses. Particularly, because almost three out of every four customers are affected by forgotten passwords.
That brings us to the two most widely used solutions to the riddle which are also the subject being discussed here today: Federation and Single Sign-On. They are two related solutions but starkly different although most people like to term one as a part of another. Because the two have found wide acceptance only in recent times, there is a certain iota of confusion that still remains as to how these two differ, if they differ at all. Some use the term Federated Single Sign-On. But the fact is that there are several fundamental differences between the two.
The most basic difference between Federation and Single Sign-On is that realm of their implementation. Federation is cross-domain structure implemented by multiple enterprises after establishing a trust relationship. Single Sign-On, on the other hand, is typically implemented within one enterprise or organization to provide single login access to multiple websites and applications at the same time. Remembering this basic difference can make things simpler for people who are not very good with their memories.
But more importantly, Federation removes the need for maintenance of a separate identity mechanism for each of the trusting enterprise. In an ecosystem of enterprises, one acts as the identity provider and others just trust the former to authenticate, on their behalf, any login requests. So users possessing identities provisioned by one enterprise use the same identities to access resources maintained by other enterprises. Social Login could be an example of Federation. Single Sign-On though is mostly an intra-enterprise affair. But fundamentally, mostly there is no sharing of identity data here. Single Sign-On is an automation of the login process in which the Single Sign-On agent presents a user’s credentials on his or her behalf without promoting one web property as the sole authentication authority.
But Single Sign-On is not a uniform implementation either. There are stark differences between various implementations of Single Single-On, notably, between Enterprise Single Sign-On and Web Single Sign-On. While the latter suits the definition mentioned above, Enterprise Single Sign-On involves having software installed on every workstation to remember and enter login credentials on behalf of the user.
With so many iterations available, it is important to understand your requirements first before choosing a Single Sign-On product. While every business’ requirement is different, a typical consumer facing business would require a combination of Web Single Sign-On and Mobile Single Sign-On considering that customers tend to prefer a cross-channel, cross-device access to the business resources.