[HN Gopher] Launch HN: AccessOwl (YC S22) - Automating SaaS Prov...
___________________________________________________________________
Launch HN: AccessOwl (YC S22) - Automating SaaS Provisioning and
Permissioning
Hey HN, we are Mathias and Philip, co-founders of AccessOwl
(https://www.accessowl.io/). AccessOwl automates your employees'
access to SaaS products. We give you a simple way to provision and
deprovision any SaaS tool, as well as to configure permission
levels. See a demo here: https://www.accessowl.io/productdemo.
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!
Author : mathiasn
Score : 73 points
Date : 2022-08-11 08:09 UTC (14 hours ago)
| rsstack wrote:
| You base your pitch on other companies' SSO Tax, but you have an
| Enterprise Tax just like them: We are an org with ~10 users and
| would like features from your Enterprise plan, and it doesn't
| even have pricing posted without meeting a sales rep. Even if we
| had 50 users, which isn't so far in the future, we wouldn't be an
| "Enterprise" but we'd still like to purchase your products.
| mathiasn wrote:
| Oh yeah, you're right we haven't seen it like this yet.
| Although the point about SSO Tax is that you need to have the
| highest Enterprise plan to get SSO functionality at every SaaS
| tool. We just sell more features (not SSO) in another plan. But
| I see your point. We should split and reorganise our plans a
| little bit. What's the feature you're interested in Enterprise?
| rsstack wrote:
| The main feature missing is automatic user provisioning (your
| version of SCIM?). Access review is nice and also not just
| for enterprises, as many businesses today need to be SOC 2 /
| ISO 27001 compliant, but since its a quarterly process it's
| less critical.
| mathiasn wrote:
| I agree with you. SOC/ISO27001 became more popular. Even
| quarterly access reviews are already pain the more people
| you have. Documenting all the things is a lot of work.
| However, feel free to try our product or contact us to get
| a live demo :-)
| jn31415 wrote:
| Are you hiring customer service agents or support engineers by
| any chance?
| mathiasn wrote:
| Unfortunately not at the moment. But this might come. Feel free
| to send something via https://www.accessowl.io/career and we'll
| reach out when this changes :-)
| debarshri wrote:
| Very relevant tool for this SOC2 compliant org. I have seen lot
| of general purpose automation tools pitch this but I think domain
| specific automation like this gives you much better value for
| money.
| mathiasn wrote:
| Absolutely. We are big believers in best-of-breed software,
| where you really do ONE good job instead of trying to do
| everything.
| debarshri wrote:
| Just to add, There are bigger competitors in the space like
| Bettercloud and other. Going upmarket will be a problem for
| you guys because these companies have already acquired orgs
| that will have a larger ACV. Problem is real though. Also,
| when an org starts growing, a dedicated IT team is hired to
| manage these roles, entitlements, value stream, networking
| etc. That means, you have a small window when the org is not
| too small and not too big probably Series A to C (100-500
| people org), implies the TAM might be small. Food for
| thought.
| mathiasn wrote:
| Indeed, we're aware of Bettercloud and others. But that's
| the point, they're focusing on the enterprise market. When
| we worked in our startups before we couldn't use solutions
| like Bettercloud as they were just not affordable
| (especially when you need to upgrade all your tools to the
| highest plan) or didn't even talk to us when we don't bring
| them 100k per year.
|
| We want to help startups and scaleups, basically focusing
| on the SMB market. These customers don't have good
| solutions as of now.
| CPLX wrote:
| It's definitely a market that will have some interest. I
| have a company with 20 people that's doubling year over
| year and could use something exactly like this.
|
| 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.
| mathiasn wrote:
| Yes, I mean in the end the startups from today are the
| enterprises of tomorrow. And we can learn and build while
| growing with them. I see your point about trust. That
| definitely takes time to build up. Companies like Zeplin
| already work with us. It would be amazing getting the
| opportunity to convince you too!
| debarshri wrote:
| That's true, but lot of startups actually die before they
| become enterprises. That implies your churn might be
| high. You might be in a situation where you allocated
| support resources for an org that runs out of money.
|
| 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.
| cupachabra wrote:
| I was just speaking to a customer yesterday and they have the
| problem that you are solving. I have forwarded the link to your
| post.
| mathiasn wrote:
| Amazing, thank you!
| cocoflunchy wrote:
| Hello, this solves a real problem for me as a growing startup CTO
| (~70 people) still handling most account creation / removal
| manually. I couldn't find a list of your integrations on your
| website? Seems like it should be a top level menu entry!
| mathiasn wrote:
| Great to hear that this would solve a problem for you! Do you
| have somebody else helping you with account creation/removal or
| are you still doing it on your own?
|
| I 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.
| HemingwAI wrote:
| Seeing how the founders do EVERYTHING to create value gives me
| absolute excitement
| kayfhf wrote:
| kayfhf wrote:
| kayfhf wrote:
| kevinmm wrote:
| Congratulations on the launch. How do you compare to Tunza
| (https://tunza.co)?
| mdaniel wrote:
| As someone who hadn't heard of either company before today,
| AccessOwl has an informative website, and your link has a login
| button without any docs saying why I should bother
| philipeller wrote:
| Thanks! Tunza seems to be a SaaS management/procurement tool,
| similar to the likes of vendr and saastrify.
|
| Where they focus on the procurement process we focus on
| provisioning employee SaaS accounts with the right set of
| permissions. Thanks for sharing though
| kiechu wrote:
| That's very good and any ISO 270001 certified small-medium
| company would need that. But it would be better to have stand
| alone web interface and not only relay on Slack.
| mathiasn wrote:
| Funnily we started with a pure web interface. But after testing
| it with a bunch of orgs we quickly noticed that some people
| have issues finding the URL where to request accesses or when
| they found it to finally sign in. So we came up with the idea
| of bringing it to Slack: Cool thing is that the user is already
| logged in and can just interact with AccessOwl. We can easily
| keep him up2date about his/her access request.
|
| 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.
| wlj wrote:
| Organisations that don't use Slack aside, driving this from
| Slack is a real benefit in my experience.
|
| 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.
| dyeje wrote:
| Do you plan to integrate with SSO providers or become one? This
| is cool, but seems like kind of a limited market because why
| would I want to maintain this information in two places
| (AccessOwl and my SSO provider).
| mathiasn wrote:
| Currently AccessOwl works well with "Sign in with Google". More
| to come.
|
| 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.
| dyeje wrote:
| IME people define roles and groups in Okta which then
| translate to how auto provisioning works. As you know,
| support for these features via SCIM varies wildly which is
| where y'all come in. That's why I'm curious if you plan to
| integrate with Okta, because you fill in the gaps which seems
| really valuable and it's a market segment that obviously
| isn't a afraid to spend money on this problem. I'm not sure
| if other products like Rippling or JumpCloud already fill
| this gap though.
| philipeller wrote:
| We currently have customers that are using Okta/Rippling
| but, as you say, wanted a solution with easier to use
| workflows and the support of non-SCIM provisioning.
|
| 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.
| frellus wrote:
| When do you plan on implementing Office365 / Azure SSO?
|
| 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.
| philipeller wrote:
| In regards to de-provisioning we are not relying on a SSO
| provider. The SSO provider plays a bigger role for us when
| onboarding an organization to read out what applications
| have been used by whom.
|
| 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
| wlj wrote:
| We've been using AccessOwl since March (came across them via the
| Slack app store while searching for something to help with SOC
| 2).
|
| 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
| philipeller wrote:
| Thanks for the kind words and your constant feedback!
|
| 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!
___________________________________________________________________
(page generated 2022-08-11 23:00 UTC)