Ask HN: How to handle user management for a SaaS without SAML support?
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.
The big issue appears when the employee is leaving the company. That is the main reason for this Ask HN.
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.
I think that this problem is faced by many companies. Maybe this is a free startup idea.
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?
19 comments
[ 3.2 ms ] story [ 52.7 ms ] threadI 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.
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.
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.
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?
The best solution is to look for companies that offer the API option or that support SAML.
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.
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.)
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.
I do 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].
0 - https://en.wikipedia.org/wiki/System_for_Cross-domain_Identi...
1 - https://developer.okta.com/signup/
edit: clarified SAML vs SCIM
I just looked up their integrations before answering because I couldn't remember for Github, but they support Github and DockerHub, plus AWS, Jira, Slack, G-Suite and more.
SCIM is specifically used for identity management (hence the name: System for Cross-domain Identity Management, or "SCIM"), whereas SAML is used to securely pass user information from an IDP to an application.
The product I am looking for is one where I manage all of my employees access to all of our relevant SAAS applications. Employees log onto this 1 single service and then can log onto all of our tools federated by this 1 service. If an employee leaves, then I simply remove them from this 1 centralized service and they are removed from all of our SAAS services.
Sorry about the confusing product and pricing page.There are typically two different scenarios for pricing: Users can be employees, consultants, contractors etc. or Users can be consumers, customers etc. Depending on the context, the pricing differs.
Not only can you remove the user/employee from the centralized service (Okta) but you can also hook-up to various HR systems (if you so desire) like AD, Workday, Ultipro, BambooHR etc. and have them act authoritatively to determine if an employee is employed, on-leave or has terminated their employment.
[1] If you work for a Startup, you may want to consider https://www.okta.com/blog/2017/12/okta-for-startups-launches...
The regular website is advertising something that makes more sense to me but there are still dozens of pages advertising dozens of different features and different prices. I guess that might work for larger corporations that have already solved internally some of these problems and can pay for bureaucratic solutions but I just want a solution to a known problem.
I'm not saying catering to enterprise customers is a bad thing (they have lots of money so you probably should), But there is a reason VC's ask for a vision. What problem does okta solve because I have spent over 10 minutes trying to read through all of your web pages and I still don't know why I should use you guys.
I'm not a marketing person, but as a customer, i generally want to know what problem a company solves in 5-10 seconds and know how they solve it within a minute. If you cannot convey that simple information, then I think your product is crap and you are just marketing your product with vague/complex/buzzword terms.
You know how we hear about dopey password disclosure breaches every month? Using a service like Okta, Azure AD, etc lets you avoid that type of embarrassment/liability and lets you control the dozens of SaaS and other accounts that your employees use.
I'm not asking to "understand identity in 10 seconds" whatever that means. I literally just want to know what problem they are solving in a simple abstract use case so i can tell if their product relates to the problems that I have. If so, I will gladly spend more time researching your product. Telling me that I have to spend hours just to figure out if my problems even relates to the solutions marketed by your products is your failure in marketing your product.
> You know how we hear about dopey password disclosure breaches every month? Using a service like Okta, Azure AD, etc lets you avoid that type of embarrassment/liability and lets you control the dozens of SaaS and other accounts that your employees use.
Go read Y combinator's "how to apply blog" [0] with the relevant text starting with "The first question I look at is, ". I recommend reading all of it because it is pretty good but that section explains how conveying a product quickly in a concise matter is crucial.
Here is some relevant text:
"We are going to transform the relationship between individuals and information."
That sounds impressive, but it conveys nothing. It could be a description of any technology company. Are you going to build a search engine? Database software? A router? I have no idea. One test of whether you’re explaining your idea effectively is to ask how close the reader is to reproducing it. After reading that sentence I’m no closer than I was before, so its content is effectively zero. Another mistake is to begin with a sweeping introductory paragraph about how important the problem is:
Information is the lifeblood of the modern organization. The ability to channel information quickly and efficiently to those who need it is critical to a company’s success. A company that achieves an edge in the efficient use of information will, all other things being equal, have a significant edge over competitors.
Again, zero content; after reading this, the reader is no closer to reproducing your project than before. A good answer would be something like:
A database with a wiki-like interface, combined with a graphical UI for controlling who can see and edit what.
[0]: http://www.ycombinator.com/howtoapply/
Users don't necessarily have to be employees, although for many smaller companies the employees may be all the users. For example, say your company buys computers for your employees from a vendor and gives the vendor access to one of your applications to send invoices and manage orders (with appropriate controls and privileges). You would want to manage this external vendor user in a way similar to how you manage employees' access to applications. For a system like Okta, this external person is also a user, though not your employee.
For your use case described above, a system/platform like Okta may be a good fit — all your user identity management and application access management would be on Okta alone.
Keep in mind that individual applications may still have copies of user identity and profile records and their own (closed) mechanisms of storing user privilege information. Those cases would have to be managed separately anyway, even though it generally may not cause any harm as such to keep such "junk" around when the main user identification record has been purged from a central system like Okta (the same can be said of AD, LDAP, etc.).
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
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.
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
Clarification: it wasn't that persons only responsibility, just one of many assignments to help automate Ops in the company.