As a company the usage of various SaaS is quite common (e.g. DockerHub, Github, Google Analytics for techblogs, ...).
Some of those services offer auth interfaces like SAML (LDAP, Active Directory). Github is one. Some services offer nothing in this direction. DockerHub is one.<p>Often the usage of a private account (eg in Github) make sense to keep history, resume and so on. Even google is doing this. See https://opensource.google.com/docs/github/#accounts
The issue here: You are not able to get a mapping to the employee because their username, email or avatar can be quite wired/different.<p>The big issue appears when the employee is leaving the company. That is the main reason for this Ask HN.<p>I "dream" from a kind of engineers self service center.
A web ui that has several "plugins". Each plugin related to one service (Github, Dockerhub, GA for techblog and so on).
Every person who wants to see the analytics of the techblog requests access via this web ui. In the background a mapping between their google account and the company email / employee identifier is maintained. And the user is connected to your GA account via an API call to google. This could be done with various services.
In the background a cronjob is running and asking the LDAP / Active Directory if this user is still active (i assume that when an employee is leaving that the AD account is disabled/deleted). If the user is not active anymore, access on all services will be revoked automatically.<p>I think that this problem is faced by many companies.
Maybe this is a free startup idea.<p>How you deal with this in your company? Or what solution you use / suggest / refer to?
Or is there already a open source version of my dream service center?
Or any reason why this is a dumb idea and you have a better alternative in mind?
The official terminology for this is "provisioning" and "deprovisioning" or overall "lifecycle management" and is a pain for lots of companies in lots of different contexts.<p><i>For example, when I left [then startup, now publicly traded] in Nov 2013, it took them 15+ months until they turned off my Github access.. in the meantime, I had access to all the private repositories. (Yes, I notified them multiple times.)</i><p>SAML is pretty widely supported but yes, it's a pain. SCIM[0] is less painful approach for the provisioning side and maps to the API mindset better. Unfortunately, it hasn't seen mass adoption so far but I think we'll get there as more people understand it and/or realize that companies will pay for it. But you'll still need SAML or OIDC for the SSO piece.<p>I <i>do</i> think there's a business need for this which is why I joined Okta in 2016, which does exactly this. I'll refrain from a sales pitch but you can explore it on your own[1].<p>0 - <a href="https://en.wikipedia.org/wiki/System_for_Cross-domain_Identity_Management" rel="nofollow">https://en.wikipedia.org/wiki/System_for_Cross-domain_Identi...</a><p>1 - <a href="https://developer.okta.com/signup/" rel="nofollow">https://developer.okta.com/signup/</a><p>edit: clarified SAML vs SCIM
I think you're trying to solve two problems:<p>1. Single-Sign On (SSO) - Log in once for access to many services. SaaS with SAML and OpenID Connect support are ideal in this space, but services without support can be used with a browser plugin<p>2. User/Lifecycle Mgmt - CRUD operations for users. SCIM support is ideal in this space, but many companies offer services beyond simple CRUD using bespoke APIs. Without support for either, it's very difficult to integrate a service. The bespoke APIs mean that you'll see varying depths of integration across services. For example, one service may allow you to control whether a user is in a group in Dropbox, while another won't.<p>There are several companies in this space (known as IDaaS), so I'll leave the Googling to you. Of those, some do User Mgmt. I'm not aware of any companies that do User Mgmt without SSO
In a past life as a solutions engineer at a SaaS company, I'll address a couple points specific to a unified solution.<p>Problem 1: Not every SaaS platform has a company with an API to manage user accounts. Even then, I would be skeptical of a company that offered it and didn't offer it via oauth tokens.<p>Problem 2: Automating the task within the browser also fails when it comes to uniformity. Any company that lacks an API endpoint for user management means you need to interact with a browser or some other hacky nonsense. With that solution comes the problem of understanding the site structure, login forms, and action menus.<p>Problem 3: Even if you did the above 2, you now have additional points of failure within your offboarding. If a failure occurs in the automation process, is it silent? What if the API changes (not that it should) or the UI?<p>The best solution is to look for companies that offer the API option or that support SAML.
From experience: after company grew to more than .. 200-300 people and user management/termination became a big burden we hired a person that would write tools to automate user management, and if something wasn't supporting SAML we did manage users via its API. If API was not available then we reverted to "Termination checklist" aka manual work.<p>Clarification: it wasn't that persons only responsibility, just one of many assignments to help automate Ops in the company.
This is a common problem with more and more companies relying on SAML federation. A part of this problem is solved by using SCIM provided your IDP and service supports it.
Ironically even though SCIM is a protocol, the implementations vary across different IDP,s.<p>A second common issue is ability of changing the email addresses in AD, this breaks the mapping cause most of the times email is primary identifier.
The only way I could see you doing this is by automatically scanning an employee's email archive and producing a list of services.<p>I do not see how introducing yet another standard solves the problem. SAML and similar standards already solve this problem; just many SaaS do not support SAML.