Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
Most of us use SaaS tools for work day-in and day-out. How do we get access to those tools? For the most part, through a colleague or IT admin who creates all accounts and sets permissions manually.
Here’s what it usually looks like for the unfortunate admin: (1) receive a request for a new tool via email, Slack, JIRA or face-to-face. Since you are busy with something else, you write a todo for later; (2) you log in to the tool and realize that the permission that was requested is way too high so you check in with the requestor’s manager; (3) you finally set up the account and document user, tool and permission in a Gsheet/Notion/Airtable.
This quickly becomes a 30m task for a simple access request! This is still the best practice for most people and it sadly also was for us. We were both founders before and experienced the same tedious process in different flavors at our own startups and other companies.
At some point we migrated to Okta and partially automated our provisioning and deprovisioning (permissioning, however, stayed painfully manual). Why only partially automated? Because Okta utilizes the SCIM API which was either not available in our tool stack or required an expensive upgrade to enterprise-subscription (thanks to the “sso tax”: https://news.ycombinator.com/item?id=31175300). And yet, we still missed simple things such as approval steps, a straightforward way to request access, and access reviews.
We talked to hundreds of organizations and saw the same manual processes and self-built scripts everywhere. The pain often starts at growing companies with around 50 employees. At this stage the CTO usually gets fed up with manually (de)provisioning and documenting it in a Gsheet. Another widespread cause of headache are IT security certifications (e.g. SOC2, ISO27001,...), requiring to know which employee has access to what tool, regular access reviews, and timely offboardings.
It seemed crazy that in a world where SaaS has become the norm, there was no great way to manage something as seemingly “trivial”, but also as critical, as user accounts. The core issues are, as always, missing integrations. Despite SCIM being the standard for over a decade, not all applications are utilizing it. Worse, many vendors lock it up in their enterprise plan.
This brought us to our core design principle: AccessOwl has to work with every tool, no matter what integrations are available. We generalize all the available ways of integrations in a single, simple interface. We take care of all the grunt work needed to coax each SaaS tool into doing the right thing. Whether it’s calling public APIs or resorting to Plaid-style automations as a last resort. Our first iteration was a simple workflow in Slack (Request -> Approve -> Manual provision). It covered all access documentation and solved back-and-forth communication between stakeholders. Since then, we have been adding more and more integrations to SaaS tools to directly (de)provision without the use of SCIM APIs. Taking a similar approach to provisioning as “Plaid” did in banking. We’re already covering 100+ tools and counting.
So what does a typical workflow look like?!
Step 1: Request an access, onboarding or offboarding. For this we piggy-back on whatever messaging tool is used in your org (we are starting with Slack, Teams will follow). It’s as simple as clicking a button to get your request started (no more manual JIRA ti...
44 comments
[ 3.5 ms ] story [ 107 ms ] threadI agree that we need to put more work into our website and list all integrations there. But I guess most of the applications you use, we're covering already.
That seems like an unnecessarily bold statement when your landing page mentions +100 integrations
“But I’m guessing we cover most of the applications you’d use”
I’ve read a couple other comments from them, and am pretty sure it’s a minor fluency thing. I’d give them the benefit of doubt :)
However, I agree we shouldn't solely rely on Slack as orgs without Slack just can't use us at the moment. That's a good point! We already provide an admin interface as web app for easier filtering, reporting etc.
A system like this lives and dies on the team actually using it, and by allowing them to drive it from where they already are (Slack), we’ve found the team are actually using it and don’t have many complaints about the workflows either.
We want to help startups and scaleups, basically focusing on the SMB market. These customers don't have good solutions as of now.
You’ll have to convince me to trust you and that the product actually does what you say it does and that you’ll be around in a year.
But the thesis is sound I think.
Also, I think the pricing is very low. For $2.5 per user, for an org of 100 users, ACV is $3000, that implies for a 1M ARR, you need around ~340 SMBs, which I think is possible but it is on the higher side and it is lot of effort. You are pricing implies Bottoms up, But for adoption you need the whole org's buys in which I think does align at scale. Just to put things to perspective, smaller orgs (20-50) pays $5000-$6000 to drata, vanta and others for SOC2/Compliance.
Again from customer point view it is cheap and great but economics may not workout.
Just food for thought. I wish you success.
Where they focus on the procurement process we focus on provisioning employee SaaS accounts with the right set of permissions. Thanks for sharing though
We don't plan to be come an own SSO provider as we believe authentication is solved good enough. But setting the right permissions for a user account is not. So you SSO provider does not have information which permission somebody has only that somebody has access to an app. That's we do differently basically.
We are definitely not shying away from working with existing solutions. We believe we can provide a great value even if you already use Okta/Rippling/Jumpcloud, as they typically focus on SCIM and therefore often only partially cover your SaaS tool stack.
I would ditch Okta tomorrow and throw money at you. One of the reasons I stay with Okta is their ability to automatically provision accounts with SaaS providers. It's not 100%, but it's more than 80% of the apps we use have integration with them and seem to provision/de-provision well.
Would love to understand your case better. Are you using Azure SSO and Okta SSO in parallel? Without knowing the specifics of your tool landscape I believe we can help you there. Here is my calendly in case you want to share more details: https://calendly.com/accessowl/30-minutes-pdt
My thoughts:
- The founding team seem to know what they're doing. I've put forward a number of feature requests / bug reports over the last 5 months and they've generally very responsive, often fixing bugs the same day
- They've added a number of larger feature requests over the last 5 months—one in particular being something to help with quarterly access reviews, which has helped to alleviate a real pain point we had
- Driving it from Slack seems to works pretty well for the team and people seem to be using it
- AccessOwl see themselves as a single source of truth for vendors, however, the reality is that it's the vendors themselves that are the source of truth. The accuracy of AccessOwl currently relies on the team using it 100% of the time.
- The design of the product is a little rough around the edges, however, as they seem on top of the product generally, I'm personally happy to work around that for the time being
- Most of the workflows work well enough. Offboarding users for example is better than what we had before.
- Onboarding a new team member is one area that currently falls short. You're able to setup templates to onboard people with, that contain a bunch of apps you want them to have access to, however, you're only ever able to select one template—in most cases for us, that means you can use a template to quickly onboard a new user with about 1/3 of the apps they need, but for the rest of them you're forced to do them one by one, and need to keep track of where you're at outside of the product—it's extremely slow and cumbersome and much worse than our previous method.
- On balance, they have got a promising product, and provided the new user onboarding issues were fixed, would generally recommend it
Onboarding is definitely one of the topics we want to iron out further. As of right now we only support RBAC (role based access control), basically one role/template for one type of user. Our goal is to offer ABAC (attribute based access control) in the future where one user carries several attributes (country, team, management level...) and applications + permissions are being matched to those attributed accordingly.
Hope to have it live for you to test it out sooner than later!
Was planning to open source the tool but didn't really get the time then - great to see you guys solving it well! Congratulations!!