Ask HN: How to handle user management for a SaaS without SAML support?

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.

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

Okta is exactly what the OP is looking for.

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.

SAML and SCIM achieve two different use cases.

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.

Your product and pricing page are super confusing to me. You talk about "users" but don't you mean "employees".

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.

[Disclaimer: I work for Okta]

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...

Wow, that developer site linked by in the comment I responded to is advertising a WAY different (more specific) product than your normal website (from what I understand at least).

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.

If you expect to understand identity in 10 seconds, you don’t even know what you don’t know.

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.

> If you expect to understand identity in 10 seconds, you don’t even know what you don’t know.

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/

I’d caution you against ever visiting the websites of Microsoft or Google.

Note: I'm not connected with the GP in any way and do not have any financial or material interest in Okta.

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.).

Or consider the case of a university: users can be staff, students, contractors, alumni, and various other random categories. For example, at the university I used to work for, any member of the general public could purchase a library borrowing card, and that meant they had to have a login to the university library systems (to see what books they had borrowed).

I think you're trying to solve two problems:

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

In a past life as a solutions engineer at a SaaS company, I'll address a couple points specific to a unified solution.

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.

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.

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.

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.

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.

It sounds like something like Okta is what you're looking for to help with provisioning, authentication and deprovisioning

BetterCloud does something like this.