Ask HN: User Provisioning at Startups

I'm actually building a simple tool that allows you to provision accounts, manage permissions and delete accounts. I haven't figured out yet if I want to market this directly to companies, or as an API for big HR companies so that they can build this into their product offering (what sucks is maintaining all the different integrations and adding more and more, so it might make sense to offer this to other companies so that they don't have to build it themselves.

Would you be interested in a SaaS (yes, another SaaS...) with the only purpose of provisioning accounts, even though at some point (when your company grows), you will probably get a bigger more complex SaaS for handling HR?

Contact me at daniel at carmona.email if you want to talk about it.

Problem: IMO the current problem is largely with SaaS providers, not necessarily with SSO solution providers / provisioners. Saas Vendors often don't support SSO / Provisioning, at all, or if they do, on more expensive plans. Almost like auto-trim levels, SSO/Provisioning are lumped in with "Enterprise" security features, you've gotta pay for a larger package to get just the security features. I think this will likely change over the years as SaaS vendors realize security is worth providing to all customers independent of what they pay because it reduces Total Customer Cost over time / reduces churn.

Solutions on Creating/Provisioning: TBH there aren't great solutions that I have found to this problem other than the following, I'm interested in other ideas here as well:

SSO/Provisioning - Solutions I've looked at (Okta (Medium+), ServiceNow (Enterprise)) and used (OneLogin, Google "SSO", Rippling) in the past year, are all fairly easy to use and once you understand the mechanics, easy enough to hook up to your source of truth and provision user accounts. An additional challenge is that they don't all support the same level of provisioning (IE - It sets the account up, but doesn't set up or provide an ability to setup the permissions project access in an automated way). I've found this really hard to understand until you actually try to implement.

1Password - If the above fail (IE SaaS provider doesn't support it or you just don't want to pay for the premium trim SaaS plan) (Zoom - Looking at you here), we've used 1Password with fairly good success. You can write up a best practice or list of the accounts that you need to manually provision, and as long as you have access to their email in advance, you can sign up accounts to their email, create their password in 1Password, and store in their personal vault. This requires you to obviously trust the person setting the accounts up, but we've done this and it saves a ton of time and energy onboarding employees because you can do it ahead of their onboarding.

Solutions on Deleting/De-Provisioning: SSO - Obviously the best way. 1Password - This can work because you can "lock" the 1Password account which removes the employees ability to access their 1Password account, but retains your ability as an admin to see / handle their accounts. Where this breaks is if the employee changes the password on their own, and doesn't store it in 1Password, either maliciously or unintentionally, then you better hope the SaaS vendor has an admin view.

Hope this helps, there is absolutely a gap right now that you have identified, and I agree with.

Prior to a federated identity solution, I'd suggest a corporate / enterprise ready password manager. Check 1Pass or LastPass.

I think my company uses lastpass but it was kinda of a pain so I just save my passwords into chrome.

Rippling does a nice job with this, albeit as part of a larger product offering.