Identity Providers (IdPs) and Identity Management

The identity management problem is complex and getting more and more complex as the Internet evolves. Within a corporation there are multiple users that have multiple roles. Any given user needs to access several public, multi-tenant resources on the Internet, e.g. public clouds, public backup systems, public SaaS applications, and other services. A user most likely has multiple devices from which such access is needed from multiple locations around the world. In addition each individual user may have several security contexts from which authentication is needed; for example, the user’s company, personal use, charitable organization, little league sports team, etc. As we’ve discussed before, a username and password for each combination of device, context, resource is a totally unmanageable situation from many perspectives. Throw in privacy concerns and bad actors who steal and misuse identities, the computing industry has a serious identity problem.

Inside a federation of multiple Service Providers, multiple corporations of users, multiple types of name directories, and multiple Identity Providers, what makes for a good Identity Provider? More generally, in the context of the federation, what makes for a good Identity Management System?

At the highest level, users want unfettered (and secure) access to lots of Service Providers (SPs). When you see a commercial IdP advertised, usually the first marketing statement is the number of “applications” it supports, and of course, there are a few big ones like Saleforce.com, Office 365, and Google Apps that are essential. It is not unusual for an IdP to advertise “thousands” of applications. Some applications want strong authentication, some use only certain protocols or data formats, etc. A user’s corporation may insist on the integration of a particular name service, e.g. Active Directory, LDAP, RADIUS, Tivoli Directory, etc. The IdP is in the middle and must support at least those combinations that the customer needs.

Thus, at the next level, the key things one wants an Identity Provider to do are also listed in the marketing material for various IdPs:

1. Authenticate a user in multiple ways, e.g. extra security questions, hardware frobs, difficult passwords, email, SMS, Telephony, X.509, PIN, Common Access Card (CAC), government Personal Identity Verification (PIV) card, smart card, bio-metric readers, Yubikey, LastPass, KeePass (open-source), etc.
2. Pass this authentication around (“credential mapping”) the federation without having the user re-authenticate unless additional authentication is needed (as opposed to re-authentication); support OpenID Connect, SAML 2.0, WS-Trust Security Token Service (STS), and others
3. Allow service providers to require different levels of authentication based on risk or on the importance of the service: user IP address, IP reputation, group membership, geo location and geo-velocity. Support black and white lists to override risk algorithms
4. Support multiple user devices, incl. Mobile
5. Multiple application types (SaaS, Web, Internal, Mobile, …)
6. Support various name services: AD, LDAP, JDBC, ODBC, Sun One, Novell eDirectory, Tivoli Directory, JBoss Web services, RADIUS, etc.
7. Support Single Sign On (SSO) via SAML 2.0, OpenID Connect, Kerberos Key Distribution Center (KDC), …
8. Security auditing, XDAS
9. Identify anomalous user activity
10. Participate in the enterprise disaster recovery with high redundancy

Some final thoughts about security: Many users, myself included, have been skeptical about the security of an Internet-wide Single Sign On facility. Such a service would be a juicy target for nefarious hackers. Passing around tokens on semi-secure channels appears to invite “pass the hash” and “man in the middle” exploits. The more functionality that an IdP product has, the more opportunity for bugs that open security holes. The more personal identifying information that a product holds, no matter how encrypted, the more inviting a target the IdP becomes. In addition, users should worry about who owns the encryption keys and how they are managed. Some vendors are obtaining security certifications such as SSAE 16, SOC 2 or ISO/IEC 27001. A vendor that gets such a certification is not only thinking about security, it is doing something about it.

My next IAM post is on SAML.  It is here.

Tags: Active Directory, AD, CAC. x.509, federation, Google Apps, KeePass, Kerberos, LastPass, LDAP, multi-tenant, Office 365, OpenID Connect, PIV, Radius, SaaS, Salesforce.com, smart card, Tivoli, WS-Trust, XDAS, Yubikey