Friday, May 20, 2016

Considerations for your next centralized Identity Provider

It is no secret that cloud adoption is hitting new record rates.  The number of SaaS applications has exploded and the value they provide is so tempting that many businesses are jumping on board.  Unfortunately, this has caused some severe headaches for IT departments.  One such headache is how to manage authentication and authorization concerns on those SaaS applications in a scale-able way.

When choosing a centralized identity provider, there are a few considerations I like to look at.  More specifically, there are a few key capabilities that I like to assess as part of my decision making process.  It is important to note that a holistic identity management solution requires both the identity provider and the target application to support certain capabilities.

Consideration 1: Single Sign-on

A centralized idp wouldn't be much if it couldn't facilitate single sign-on capabilities.  What I would generally look for here is something that is capable of all the latest standards (read SAML 2.0).  Further, I am looking for some type of password vaulting technology that allows me to share passwords between multiple team members without actually giving them the password.  This is an important use case for scenarios such as corporate facebook or twitter accounts.

Consideration 2: Authorization

Not only am I looking for authentication capabilities, I also want to be able to authorize my users from a single place.  While heavily dependent on the target application, I want my idp to be able to set custom claims to help govern access to target applications from a centralized spot.  This reduces the load on IT and business super users for maintaining and managing access.  It also allows for one centralized spot for auditing of access across the enterprise.

Consideration 3: Provisioning

A lot of headway has been made in the automatic provisioning space.  In an ideal world, however, all applications would comply with the SCIM standard for cross-domain identity management.  This would make it really easy to CRUD users into those systems from a central source.  For this capability, I'd expect my idp to be flexible.  Ideally there are built-in integration with providers, but also an opportunity to add in custom integration to API endpoints to facilitate the provisioning process.  

Consideration 4: Attribute Exchange

There is generally more to configuring a target SaaS application than user data exchange.  In a lot of cases, the provisioning and authorization process will provide access to a subset of company data based on something like store locations, or departments, or some sort of hierarchy relationship.  Ideally, I can pass that information as part of some sort of attribute exchange during the provisioning of that SaaS application.  Further, I'd hope that my idp can do this for me, providing once again, a single point of management.

This capability is a little bit more pie-in-the-sky and I haven't seen too many idps meet this need.

Consideration 5: Audit and Compliance

Lastly, an idp should have really strong audit, compliance, and security components.  For example, the idp could integrate threat intelligence to help determine potentially compromised credentials.  Reporting should be able to answer compliance questions as required (who has access to what), and each login should be audited and tracked.

In short, there are a few key considerations when looking at centralized idp mechanisms.  The big names out there are making large strides in this area.  One area that needs consumer help is putting pressure on the 3rd party applications to comply with the latest industry standards such as SCIM and SAML.