Everything you access on the web, on-prem or in the cloud requires a user account and I know I’m preaching to the converted when I say it’s a night-mare.
SCIM 2.0 is poised to solve this problem by providing an identity provisioning lingua franca that eliminates the need for creating a bespoke connector for every single identity provider and cloud application in the world.
In this real training for free event, I’ll introduce you to SCIM and show you the actual REST API and JSON schema. First though a little perspective.
20 years ago, we were belly-aching about the security risks and user experience horrors of all the accounts and passwords one user had to maintain for accessing on-prem systems. That improved with AD but it was short-lived because the cloud came along and we are seeing it all over again. But in a new, bigger and more complicated way.
Integrating on-prem applications and systems to a single, central identity provider like AD turns out to be in some respects simpler than the cloud. In this legacy scenario you have lots of different applications, databases and systems but they are all under your control, you own them, and everything’s on one big more-or-less trusted network. Once a system was connected to AD for authentication and group membership as what I call a “reliant party” not much else was needed. You just logged on to that system, db or application as your AD account, the system, being assured you were you by authentication by the DC, then determined what entitlements you had based on your individual identity and the AD groups to which you belonged. The point is that for many systems relying on AD there wasn’t anything you needed to do on those systems for each and every user. The user showed up to the reliant system, AD vouched for their authenticity (password) and identity (username and group memberships) and got to work.
In today’s cloud-based world it could theoretically work that way but in practice it’s more complicated. You can get single or at least consistent sign-on by federating in some way back to a central identity provider (cloud-based or on prem) but the user normally has to be provisioned ahead of time in each application. That led to the rise of “connectors” but that required a different connector for every tuple combination of identity provider and cloud app. And of course, the quality of each connector varies. And sometimes they are temporarily down because of API changes.
What we need is a common protocol and schema for provisioning users and groups that every cloud and identity provider speak. That lingua franca of identity provisioning is the System for Cross-Domain Identity Management – SCIM.
SCIM defines a standard schema for describing users and groups in JSON and it defines a REST API that uses HTTP verbs for the basic CRUD operations necessary for maintaining those users and groups.
SCIM defines all objects as some type of resource. So, User and Group both derive from the abstract Resource. And an Enterprise User derives from User – adding additional attributes necessary for a corporate user as opposed to a generic application user. Attributes like employee number, department, manager. If it reminds you of LDAP that’s understandable. There’s a degree of overlap. But SCIM is far, far simpler and streamlined. You might also be reminded of SPML – which never really took off – again being more complicated and based on SOAP and XML.
We will look at the SCIM API operations and how HTTP POST is used for Create user, PUT for updating a user, etc. And you’ll learn how trust and authentication is setup between SCIM clients and SCIM endpoints – and what SCIM clients and endpoints are for that matter.
At the end of the day however, SCIM is only useful as far as it is supported. And SCIM support is still a little soft out there. That’s where our sponsor, One Identity, comes in and their cloud based SCIM bridge – Starling Connect which Alex Binotto will briefly show you.
Please join us for this real training for free technical education devoted to an important trend in cyber security.