Phil Hunt is an active member of multiple industry standards groups and committees (see brief bio at the end of the post) and has spearheaded discussions, creation and ratifications of industry standards including the Kantara Identity Governance Framework, among others. Being an active voice in the industry standards development world, we have invited him to share his discussions, thoughts, news & updates, and discuss use cases, implementation success stories (and even failures) around industry standards on this monthly column.
Author: Phil Hunt
When work started on SCIM (originally Simple Cloud Identity Management), the objective was to define a simple way for enterprise customers to push their employee identities to cloud service providers in a standard REST format to enable access to cloud applications. Enterprise customers wanted a way that leveraged the IT managed identities they already had and to propagate them to the cloud. Likewise, cloud service providers needed a way to acquire those identities in order to gain new customers quickly and with low cost. A pretty straight forward use case.
Soon after IETF adopted SCIM, its acronym changed to System for Cross-Domain Identity Management. The new name didn't mean there was an expansion of use cases and scope, but rather a broader understanding emerged of multiple administrative domains, mixed data sources.
SCIM will remain relatively simple for many enterprises as they seek to push identities two a cloud provider. But for others, the concentration of their identity management efforts will spread and potentially even shift the center of gravity for enterprise identity to the clouds. Here are some influencing factors to consider:
- Many cloud service providers are building identity platforms (directories) much in the same way that enterprises used directories. These directories support the service provider's applications much as LDAP directories did for enterprises. But, as well, cloud providers are architecting their systems as platforms for identity to enable customers to provision to other cloud service providers.
- Bring-your-own-device/Mobile-device-management -- There is a growth in devices, mobile software, and containers to manage. It seems unlikely these will be managed inside internal corporate directories since there seems to be little interest in expanding the role of classic LDAP directories to cover these devices. In addition to expanding LDAP's 20 year old schema, LDAP's data model seems limited in the types of data it can manage. Today's smart phone address books backed by the vCard standard already have a richer data model.
- Multi-factor authentication services are de-rigueur for many cloud service providers. While many internal enterprise systems relied on password authentication and a huge dependence on VPNs in castle moat style security architecture, this likely not sufficient for cloud based applications. Cloud based applications depend on TLS coupled with strong authentication and authorization systems to provide greater levels of assurance or LOA. Many enterprises already have sophisticated strong authentication supporting high LOA and will continue to use their own federation systems to authenticate their users to cloud services. For those that do not, will enterprise IT departments upgrade their internal sign-on systems to provide enhanced LOA for authentication, or will they begin to rely on cloud service providers for improved authentication services?
- New applications and domains. Many enterprises already use external services like web conferencing, but now enterprise social networking and many others are becoming popular. Employee benefits providers are now online too. The suite of "enterprise" applications that employees are using is growing and is not just a mirror of what used to be on the enterprise Intranet. Further, it is clear the full set of applications won't come from a single cloud provider, they will come from multiple cloud providers -- making identity standards even more crucial.
- Multiple identity sources. In the enterprise world of 10 years ago, life was simple. Employee identities and related information that are widely used were placed in the enterprise directory making it the sole source for authoritative identity information. In the cloud, some identity assertions may be federated from the enterprise, while other identity attributes and assertions will originate in cloud providers. The relationship between cloud services and the identity sources will initially be diverse using different protocols and APIs. SCIM is part of the puzzle for keeping this information up-to-date, but expect federation solutions like SAML, OAuth2, and OpenID Connect to fulfill the role of providing identity information for on-the-fly scenarios.
For provisioning systems, there will be some flux as authoritative data sources become more numerous and the number of "hubs"of identity information increases and the center of identity shifts away from traditional enterprise directories. What will drive a lot of this forward will be how the economics works. Cloud providers are already figuring how out to do stronger authentication for consumers in a cost effective way. Expect the same for enterprise cloud service providers.
Where we are headed with enterprise identity is a set of cloud services that are both cheaper and high-quality but with a lower center-of-gravity, distributed with different information across many domains. Enterprise provisioning through SCIM will allow for cross-domain co-ordination keeping user information accurate while the service provider is able to provide scale and security features.
Note: For more technical details on the recent updates to SCIM, check out the Draft 03 details here.