What We Mean By Federated Identity & What It Means To You

Introduction

An identity federation consists of a group of companies that agree on common standards useful to online authentication, authorization, and single sign-on (SSO). In a federated SSO environment, a user can authenticate into multiple sites within this agreed-upon federation.

Take “Facebook Connect” as an example. This is a federation where people can use their Facebook accounts to log in to multiple websites. Sites like Storylane, TechCrunch, Mashable, and several cloud-based applications around the world tune in to Facebook for their authentication processes.

We have an ever-growing need for multiple accounts on different websites, creating a situation where it becomes nearly impossible to remember every URL, username, and password required to log in. Many people often recycle the same password across the board, and others – with security in mind – keep a “cheat sheet” on Microsoft Notepad to jot every credential down.

To resolve this issue, the federations mentioned above were developed. But how do they maintain your privacy intact?

What the most prevalent Federation Protocols?

1) Social Logins And The OAuth Protocol – Social logins provide us with the most convenient way to authenticate through a federation. If you use Twitter, Google Plus, iCloud, Windows Live, or Facebook accounts to log in to any third-party website, you’ve used federated SSO. Most users don’t fully realize what this does to their privacy by opting into this framework. By using a social login, you are entrusting the control of your username and password to these services rather than managing the security on your own. These federated login providers all compete to manage your credentials with the goal of “locking in” the most people. Social login provides access of your personal data to third-party sites, which allows them to consider new marketing strategies, advertisements, content, and product recommendations.

In a social login, an “OAuth” authorization code is sent from the social website to the third-party website through your browser. It’s rather easy for a hacker to ultimately intercept this information, impersonate the user, and gain full access to the account.

Even more, if the service providing the social login (i.e. Facebook, Twitter, Google+) is hacked, your entire social identity across the Web becomes compromised. Can you trust these people with your credentials when they’ve all been compromised at one point or another? It’s likely to happen again.

2) OpenID And The OAuth Protocol – OpenID, although slightly less popular, presents a fantastic solution within the development community to help users reduce the amount of passwords that they’re obligated to remember. In fact, you might have an OpenID and not even know it. Check out the OpenID providers. The only inconvenient factor in this is that it works only on a few sites. And OpenID providers aren’t keen on your security or privacy either, much like social logins.

But there’s also another problem: OpenID isn’t well-understood by its users. The authentication method uses a unique strategy: It eliminates the need for credentials by utilizing a URL for login. Simply enough, if someone gets a hold of the data, that person can access your account without breaking a sweat. As for privacy, you basically have none. All the websites using OpenID have access to every piece of information you configure.

3) Federated Identity & SAML – SAML, or Security Assertion Markup Language, is an XML-based standard that gives organizations the possibility to utilize Single Sign-On (SSO) to authenticate into their online applications inside and outside their firewalls.

It’s a very safe way to communicate, since authentication isn’t done through your browser. Rather, a large amount of transactions happen on the server end between an “identity provider” and a “service provider.” Since it doesn’t use cookies, and doesn’t store any information in your browser, this makes it more difficult for hackers to infiltrate within your connection.

The problem with SAML is that it hasn’t been accepted by many companies since it requires them to adopt similar technologies and systems. Federated technology like this requires all the companies in agreement (and their competitors) to agree upon a directory structure that would store the usernames and passwords of every user within their databases. This would be a nightmare to implement and the process is too tedious for SAML to become widespread.

Online applications, such as those that are federated, need to locally manage their users’ identities. This makes user management challenging, since they have to store all the data on their servers and deal with password resets and account registrations on their own.

While the cloud has presented some solutions, apps still manage their users in different manners internally, meaning that the way they interact with the outside world isn’t predictable nor is it consistent.

Ideally, developers tend to use something similar to SAML for account management, known as Service Provision Markup Language (SPML). This still isn’t lucrative, though, as SPML is not widespread, either. SPML basically works in a similar manner: It authenticates users through a technology agreed upon between two or more organizations. We still end up where we started.

Because of the lack of collaboration between different companies, it’s difficult to imagine the possibility of a general tool that just “does it all.”

Craig Burton – a highly renowned analyst at KuppingerCole – puts it very simply at the Cloud Identity Summit in Vale, CO: “SAML is the Windows XP of Identity. No funding. No innovation. People still use it. But it has no future.” He made his point further: “There is no future for SAML. No one is putting money into SAML development. NO ONE is writing new SAML code. SAML is dead.”

New applications all over the web and interfaces that help those applications communicate (Application Programming Interfaces, or APIs) are appearing everywhere. SAML cannot keep up with this because it’s not designed for such massive online application integration. It also doesn’t allow the user to have control over his/her identity.

Mike Schwartz, the founder and CEO of Gluu, had the following words to say about SAML, regarding its death: “[I]t’s a ‘when’ not an ‘if.’ SAML does not support user authorization – trust is managed exclusively by the organization, and this model does not solve the use cases we are facing today.”

4) SCIM – The System for Cross-domain Identity Management actually presents a viable solution in which an organization can put its entire identity (all its usernames and passwords) in the cloud. This makes is virtually effortless to add and remove online and cloud applications.

Because of a lack of standards, SCIM stands a bit above all the other online SSO solutions. According to its IETF protocol schema, SCIM intends to “reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols.”

Basically, SCIM aims to make the integration challenges mentioned earlier disappear. Companies with a number of technologies can continue to stick to their original standards of operations. Your usernames and passwords move into a sphere of the Internet that is practically untouchable.

SmartSignin – our service – has been developed according to this protocol. With SCIM, SmartSignin has the capability to leverage a higher level of security and establish logins without the need for a federated system or a certain standard of technology. Because of this flexibility, users no longer need to be confused in a tug-of-war between different adaptations of technologies that no longer protect their privacy. This, hopefully, is where the questions of identity management, privacy, and security are answered.

Conclusion

Federation is one of the ways in which people like you can sign into multiple applications with just one password. However, the convenience has a trade-off in safety. It’s like having one single key for your house, your office, your car, your vault, and letting that key act like a debit card that makes payments. If that key’s stolen, you’re pretty much done for, and the person with that key can do an immense amount of damage to your reputation, your finances, and your dignity. Would you rather have one key for everything, or a keychain that binds everything together?

Federation also demands that large companies with all sorts of technologies and histories collaborate in some way or another. It’s so much easier to just say that we have to collaborate, but getting down to the task is an immensely difficult process. Moreover, the widespread adoption of federation would matter the most to keeping it alive. Besides TCP/IP and a few others, there seldom have been protocols that really took off in that manner. It’s doomed to fail if no other solution presents itself.

This isn’t the only problem, though. We’re living in an era where regulations just keep piling up with no end in sight. The burden stands on top of your shoulders, especially if you’re shifting around any number of digitized financial or health records. In any employee portal or consumer account, there’s bound to be some sort of confidential data you need to protect. Global companies bear the highest burden, since the privacy laws around this little blue planet are so mixed up from country to country.


The question now isn’t “how,” but “when” you will adopt the right strategy to ensure a strong future and the safety of your consumers, your employees, and your company.

Leave a Reply