Identity management and the protection of one’s identity are critical on the internet and in the cloud, unfortunately even with new technology being developed in this area we still have a long way to go in making the user experience a better one. When we started FrontBridge in 2000, identity management wasn’t something that was top of mind to me, I was more focused on providing a great platform to protect email services and a great admin experience to our users so that they could see exactly what we were doing to their email. The implementation of the FrontBridge admin console was before the rollout of standards like SAML and other SSO frameworks and as such we often used more custom solution to integrate our admin experience into customer’s intranets. In most cases an admin would just have a separate identity in our system vs. their corporate system and this is still the norm for most cloud services today.
To address the identity problem in the FrontBridge service at some point, post our acquisition by Microsoft, we added the ability for customers to federate with us using Microsoft’s ADFS 2.0 product and theoretically if you had a SAML 2.0 aware directory service you could do SSO with us. Originally there was a significant customer “ask” around this but when we shipped it in beta it became very hard to get people to use. Since we were a Microsoft shop, as we were now owned by Microsoft, getting folks who weren’t using ADFS 2.0 to federate with us became impossible. While we were SAML 2.0 compliant we only supported ADFS 2.0 and as anyone who has worked at an enterprise knows you’re not going to go ahead and federate with someone in an unsupported way to a production application (good luck getting that by your IT department). Because of this our federated identity offering never got off the ground. In reality the only place where this is used today in the Forefront Online service, as FrontBridge came to be known, is the federated login that now exists between Forefront Online’s administrative console and their quarantine applications, which is a bit depressing given all the work that went into this.
With the rollout of Office 365 federation was taken more to heart since having federated identity with enterprise customers is critical to success and as long as your organization is running ADFS 2.0 you can make it work.
Directory and identity services have always been a bit of a black art. Back in the day you may have been running NIS (FKA Yellow Pages), or Novell’s NDS, or Banyan VINES, or Microsoft’s Active Directory, or one of the many other implementations of LDAP that was available from everyone from IBM to Oracle to open source. In almost all cases having these systems interoperate with each other was hard to impossible. Things like SAML were created to allow organizations to be able to more easily interoperate with each other. Using SAML two organizations could federate with each other so that when they used applications that required identity between orgs, each org could use their own credentials and the user wouldn’t have to create another set of credentials and sign in again.
In a perfect world things like SAML 2.0 would fix all identity problems. Unfortunately there are a few issues:
1. SAML based systems are hard to set up to interoperate with each other cross vendor
– Microsoft’s ADFS 2.0 is SAML 2.0 compliant and will work with other SAML 2.0 compliant systems however getting support from folks like Microsoft in making ADFS work with other SAML compliant systems is hard to impossible. Microsoft engineers are experts at ADFS but aren’t expert at whatever other compliant SAML system you’re using
2. SAML based systems are really slow on high latency links
– Because of the number of SSL based round trips that need to occur in SSO systems, web logins can be very slow when using protocols like SAML. In the event that service provider and identity provider are separated by significant geographic distances users can become frustrated with how long it takes to log in with federated infrastructures
3. Complexity. Managing a lot of federations can be difficult and federated identity systems require expert level knowledge on the part of company administrators in order for successful federations to work.
Other types of identity solutions like OpenID have also been put forward. The advantage of OpenID is that it’s not tied to any one commercial platform and is easy to implement. Anyone who can host statically available servers on the internet can become an OpenID provider. OpenID however is subject to a variety of Phishing attacks to grab user credentials and your credentials are really only as secure as how secure your credential provider is.
Even though there have been major industry wide efforts like SAML and OpenID identity in the cloud today is more fractured than ever. Efforts like this imagine that sites and organizations will federate themselves across all or many sites. If this occurred than a user using a single login could traverse these sites without having to log in again and the user could be assured that the management of their identity was happening in a single place. The reality is that given different technologies, geographies and security concerns it is impossible to believe that this sort of federation will ever be able to exist. People who use many online accounts like myself end up having dozens if not a hundred different accounts across a variety of sites. Some of the sites may require very low security but others may have identity frameworks in front of banking or other sensitive personal or financial information.
One of the newest trends in identity is called “User Centric” identity management. In reality this isn’t a new model at all as the concept of a “password safe” (which is user centric) goes back many years. With the continued fracturing of identity, management tools around the user centric model have become much more sophisticated. These tools now help a user manage their multiple identities by having a central store of identity and help ensure that the user creates secure passwords and sync their identities between the multiple screens that they use. Simple tools like LastPass, Keypass or Apple’s keychain will work with all sites and in the cause of LastPass and Keypass can force or help the user make sure they actually use cryptographically strong password. There are issues to work out with the user centric models and there are threats around these applications such as stolen devices, keyloggers or the security of the software itself.
Unfortunately there isn’t a silver bullet to any of these problems. In the old corporate world identity was clear, your IT Pro would assign you a username and set a temp password. Because you sat in an office people were pretty sure that you were who you said you were especially after you filled out all the requisite hiring paperwork and perhaps had a background check done on you.
TeleSign can help in all parts of these ecosystems. A username and password is great but in all the cases above it relies on something you know (a username and password). By sending a PIN code to your mobile or landline phone TeleSign takes something you have (a phone) and turns this into a second factor security device. Given the fractured nature of identity management today a username and password isn’t sufficient to protect your online identity. Your identity should be validated with something you have to ensure that when you traverse the many sites that make up the profile of a user online today that the person logging in is actually the person who they say they are.
In later blog posts I’ll go deeper into issues with SAML, OpenID and User Centric identity models. I’ll also talk about recent hacks that have been seen and the various approaches that have been taken to prevent hackers from accessing unauthorized data.
To learn more about the different types of identity management out there and about User Centric Identity Management here’s a paper worth reading by Auden Jøsang and Simon Pope: http://folk.uio.no/josang/papers/JP2005-AusCERT.pdf