ID provisioning with clouds

The architectural ideal is to have a single source of authority for identity and AuthN/Z claims, hopefully based on something nice and open like LDAP. Then we began to see lots of federated identity solutions entering with SAML type federations. This, and SaaS solutions in the cloud take us back to the days of multiple identity silos maintaining duplicate (at least partially) records of identity. SaaS providers even see this identity that they maintain as a business asset with which they can create stickiness with their platforms. Questions arise in terms of comparisons of internal provisioning with cloud use models, typical workflows and functions required for cloud provisioning, synch of id profiles and attrs, and what motivates SaaS providers in terms of identity stores.In a modern context, onboarding and offboarding are now a major theme. This couples with the value that people see in leveraging SaaS applications, with lower upfront costs, shorter time to implement, faster ROI, reduced risk, empowerment for the organization, and more frequent, automated upgrades (from the client’s perspective anyway, but perhaps not from the MSP’s perspective). SaaS also provides additional value in times of recession and bull markets, since they can allow value proof before commitment, and they scale up and down. This is classic risk transference.

##Cloud provision data and actions (onboarding included):

* user identity – name, employee id, unique id
* credentials
* privileges/entitlements – roles, groups, entitlements
* profile – DOB, email, contact info, dept
* flows/triggers – enrollment, terminations and deprovisioning, CRUD, data reformatting, recertification

##Internal vs Clour provisionsing

###Traditional/Internal

* tight/heavy integration
* compliance drivers
* batch enrollments
* direct data store access, LDAP and agent connectors
* integration i/fs slow to change
* very high costs – timeline in months
* push based provisioning – batch flows

###Cloud

* loose coupling
* federated access is driver
* ad hoc
* API driven
* frequent API changes due to SaaS app immaturity
* Not as complex as internal for now-shorter timeline

## Issues with provisioning

* unwillingness to let go of security credentials
* integration issues (especially provisioning of fine grained entitlements)
* SaaS providers not always willing to adopt user stores to match client user store attrs
* BC/DR and SLA issues
* staffing problems – when setting up SaaS solution, who will look after the org side of admin

##SaaS apps present security and compliance issues

* what happens to stale/dormant users?
* how can you prevent users walking away with valuable information
* how do you show compliance with SaaS app users (who has access to what in a SaaS app?) – MSP receiving conflicting user information from client
* How do you move away from spreadsheets based user information exchange?

##and also IT efficiency issues

* admins need to manually set up users in the SaaS app
* and entitlements
* and prepare an access recertification round manually and compile results
* all manual and time consuming, as well as error prone

##and also technology challenges

* federation (SAML) not designed with provisioning in scope – there is implicit creation, because you know the user authN successfully with the IdP, but not as efficient as others like SPML
* Lack of standards adoption like SPML
* inconsistency of corporate user repositories – users live in many different repos, and their attrs come from other repos
* Lack of internal auth stores at many companies still….

##Legacy provisioning solutions are sub-optimal

* Arch inclues HR feeding a provisioning engine, which feeds ->
* WF/Policy and a unified store representing user identity from Metaverse/ID Valut/Identity Store/Global User Store

##Legacy provisioning solutions are difficult to implement
* licensing costs
* connector development
* WF development
* architectural complexity
* talent availability and cost – could be $150K-$180K / year, possibly 2-3 resources dedicated
* internal ownership and support of the solution

##How are orgs solving these problems?

* hosted services
* legacy provisioning
* lightweight on premise provisioning appliances
* no provisioning: claims based authZ. SAML assertions remove needs. But does it scale to large numbers of attrs?

##Provisioning Arch for Cloud

* Enterprise Sources – LDAP, File, DB, WS, IdM
* Cloud Provisioning Abstraction Layer – Virtual Meta Directory (supports pull)
* Cloud Provisioning Engine – CRUD Batch, JIR, Policy Integration, Audit, SCIM

A BrightTALK Channel
twitter
twitter

Leave a Reply

Your email address will not be published. Required fields are marked *