So many large companies over the years have struggled with information being spread (synced) all over the damn place within their corporate network boundaries. This system, that system, another system, all have different pieces of info or subsets of each others info etc being synced all over the place. Entire product lines are dedicated to this syncing of data around like FIM/MIM. This has been one of the biggest banes of IT in large companies for many many years.
Oh that system isn’t working because it hasn’t synced…
Oh it takes 24 hours to use that app because of the sync schedule…
Oh if it isn’t working wait for the next sync schedule tomorrow morning…
This app says this, that app says that, this third app says another thing, they are all wrong… Ok we will put in a change and you will have to wait x minutes, hours, days, etc for it to get changed to the same thing. If it doesn’t get there by next week let us know…
Anyone in a large org has probably seen, heard, or said one of those things at some point…
So those of us in the large orgs work hard trying to centralize and collapse all of these disparate systems down to fewer and fewer systems… SSO, SAML, centralized Identity, we fight for and in many cases achieve some level of these things and slowly make the world better and better.
And now enters Cloud providers who want you to sync everything up into their space…. Basically saying hey you used to be irritated about shit being spread all over your internal network, now you can be pissed with your stuff being spread all over the internet as you use 2,3,4,++ Cloud providers who aren’t really true Cloud providers, they are people on the Internet who provide on their premises services which is why they need everything synced to them… How about we all say hell no and tell them to fully support SAML that we provide from our giant Identity systems we built and offer JIT provisioning? Why do I have to sync users and groups up to you? If I sent you a SAML assertion for a user, that is their token, map it to what you need to map it to and use it. Why do we need to tell you in advance someone is coming? If we sent you a SAML assertion that says this user is ok to use the services you provide for us, they are ok, literally… That is what we meant when we said they were ok. Go ahead and provision them now and let them work. Oh wait… you accept SAML? Oh you don’t accept the authorization assertions?? WTF. Seriously Cloud dudes. Get a clue, here let me help you… http://bfy.tw/Ib0e
joe
You are missing one problem. LDAP allows for provisioning and de-provisioning. SAML JIT allows only for provisioning. So you can assert that a user is ok to use a service and then keep paying the monthly fee even though they are no longer a valid user.
That is a good call out Robert. Deprovisioning is NOT generally native in JIT systems (that I have seen) but this can be handled in various ways without full syncing (via LDAP or any other data sync API). I will outline a couple of the most obvious (to me) methods.
One of the first methods I would look for and would require little involvement from the consumer/customer once configured would be automatic timeout of accounts if they aren’t used in an X period. This is done in many cases with on premises software as well to free up licensing in larger orgs. You archive or even outright delete a JIT provisioned account if there is no use of it in some X period. Resource cleanup could be re-assignment to the manager of the person (or other defined receiver tracked in the JITed “account” data) or just defined to be wiped when the original consumer is gone. To this you can add some “hey you are about to time out of our system” emails. For example Confluence and Jira are handled that way where I work, if I don’t log on, I will get a notification that my account will be disabled. I even let it happen once, when I logged back in a week or so later when I actually needed something it set me back up and I was off and running within 5 minutes.
Another possible method is to use standard credential analysis / UAR / attestation processes and get a current listing of all accounts in a given Cloud service and have automation check it against authoritative systems for whether something is a valid account anymore and then if so could push requests for validation of need for the services to the appropriate management resources and anything that turns out to need to be scrubbed can be pushed back up into the Cloud service for cleanup via a deprovision request. You could also “reverse the flow” here and when someone is pushed into the deprovision process on premises that could result in pushes sent to all possible Cloud services[1]. However I still wouldn’t depend on that 100% and would want a UAR/Attestation process. I think many (perhaps most) companies fail miserably in UAR/Attestation and that really is something that has to be come Enterprise Class sooner versus later.
Regardless, I really don’t believe we need full syncing and I absolutely believe that Federation + JIT is the way forward for Cloud Service providers who actually want to play in the Enterprise Class company space. When you have hundreds of thousands or millions of users it doesn’t make a lot of sense to be pushing all of that data and the related changes across the internet to the Cloud providers just because they want to be lazy with the services they provide. It works fine for tens or hundreds or even a few thousands of users, groups, etc.
For example with Google Cloud, I have my joeware.net email hosted through it, it works great for the handful of IDs I have set up there. I don’t even want to think of syncing hundreds of thousands or millions of users. Azure AD is a bit different because it is more tightly fused with AD which pretty much forces a sync model (which IMO I know for a fact is hurting them with many companies) but if you have ever used AADC to sync many hundreds of thousands or millions of users you know how painful it is, especially the resyncs when you have to tell your management that a small change in AADC is going to force a resync that is going to plug up all changes from replicating up to the cloud for 72-96 hours or longer and that is fast compared to what it used to be where it could take a week or more for a resync in a large org.
joe
[1] This will get tougher and tougher IMO as a wide variety of disparate Cloud Services become more and more a part of the services used by large companies. I think homogeneous cloud service provider use is going to be the exception in any large companies versus the rule. This is despite anything Google, AWS, MSFT, and other providers would like you to think when you chat with them.