1
Every company actively decides at some point in time how employees shall login to SaaS vendors. The typical answer for early stage companies is Google SSO, whereas later stage companies tend to switch to Okta SSO.
In the early SSO days Okta was the best option to get MFA and granular controls. However, nowadays Google is offering 2FA as well. It’s also often the default option with many SaaS vendors and therefore neither requires manually setting up SSO nor requires an enterprise-subscription (see [sso.tax](http://sso.tax) for reference).
Therefore, why do you believe people should still use Okta?
- Is the biggest reason to use Okta their SCIM-Provisioning, RBAC etc.?
- Are there any limitations in Google Workspace that only Okta solves?
- Or for the Google folks out there: What’s the reason you are sticking with Google SSO?
I am curious what you think about open sourcing a little tool I wrote. But before, let me give you some background: I was building two fintech companies before and we had several audits per year. As the financial industry is regulated, it wasn’t a “voluntary” audit like SOC2, ISO27001 or HIPAA. Hard findings posed the risk of not being able to do business anymore.
One of the high priority auditor items was having a proper access management process to ensure that user accounts of former employees are revoked and existing users follow least-privilege principle. Even when we used Okta, in many cases we couldn’t get the data in an automated way. Either tools were not covered or behind a (way too high) paywall. Thanks SSO Tax
Back then I wrote a little tool to download user lists with their permissions from our major SaaS tools. That helped us a lot to verify user lists. Later I even added functionality for some tools to create and delete user accounts as this was another pain we got.
However, I am thinking about making the tool open source with support for a bunch of applications that can be easily extended.
Would such a tool be useful for you? Are there any other information besides users and permissions you would find important? Would you see yourself contributing to a open source project like that?
imagine you could read out data of any SaaS application, what would it be? I’d like to understand use-cases you might have.
Here are some examples to get you going:
* Downloading invoices from Asana, Notion etc. * Get a list of projects from Asana as CSV * Get a list of users with their permission in Jira as CSV ...
What use-case for which application(s) would be interesting for you and why? Thank you.
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 tickets!) and always gets forwarded to the right stakeholders.
Step 2: Provisioning and permissioning. In the most basic workflow the tool owner receives the approved request with all the information to manually provision the account. If and when you arrive at the point where manual provisioning becomes a pain, you can let us automate it for you. The requestor will automatically get process updates and the access will be audit-ready logged in the background.
Prices start at $2.5 per employee per month and we charge a fixed premium for the automation of (de)provisioning based on the total number of employees.
We are excited for the opportunity to share AccessOwl with you! We would be more than excited to hear your thoughts and feedback and your own experiences with SaaS access management!