Seeing how the founders do EVERYTHING to create value gives me absolute excitement
Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
21–30 of 45 posts
Re: Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
#22[dead]
Re: Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
#23Do 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).
Re: Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
#24We'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
Re: Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
#25Do 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).
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.
Re: Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
#26[dead]
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
Re: Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
#27We'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 m…
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!
Re: Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
#28[dead]
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
Re: Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
#29Do 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).
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.
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.
Re: Launch HN: AccessOwl (YC S22) – Automating SaaS Provisioning and Permissioning
#30Earlier quoted context omitted.
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.
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 produ…
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.