PhLR's comments

On: SSO Tax, Cut

[PhLR]

Looks like a candidate for https://ssotax.org/friends-of-sso.html

[infogulch → PhLR]

Someone's already on it: https://github.com/ssotax/ssotax/issues/34

On: Tailscale SSH is now Generally Available

[PhLR]

Sounds like Tailscale is now a candidate for the "Friends of SSO" list https://ssotax.org/friends-of-sso.html

Respect for pushing that through the org!

On: Ask HN: Is there still a reason to use Okta for SS...

[PhLR]

When talking about controls are you referring to provisioning? What are some examples for missing controls?

[warrenm → PhLR]

Pretty sure he means audit compliance, proper RBAC, etc

[mathiasn → warrenm]

Hmm audit compliance? Google gives you a log of who logged in where, doesn't it? And with "proper RBAC" you mean that you can put somebody into the "Developer" role, hence he gets AWS, GCP, Datadog, right?

[warrenm → mathiasn]

I don't know how extensive Google's logging is - heck, didn't even know they offered Enterprise SSO until a few days ago (every organization I know uses either Okta or M365/AD) :)

Proper RBAC is as granular as necessary, but no more

Proper RBAC also links everything needed by a certain role together

Merely knowing who logged-in where and when, though, is not enough - you also need to know what they did while there (and that they did not do anything they were not supposed to be able to do (which links back to proper RBAC'ing))

CIS, HIPAA, FISMA, SOX, STIG and all the other alphabet soup compliance rules, frameworks, etc are a lot more extensive than just "who logged in where" :)

--------

See NIST's page on RBAC for some of this: https://csrc.nist.gov/Projects/Role-Based-Access-Control

On: Ask HN: Is there still a reason to use Okta for SS...

[PhLR]

Do you have some examples on what granular controls are provided with Okta but missing with Google?

On: Show HN: Skip the SSO Tax, access your user data w...

[PhLR]

Great approach. Wish there would be more vendors like that. This way we wouldn't even need to talk about SSO-Tax, availability of SCIM/SAML etc.

On: Show HN: Skip the SSO Tax, access your user data w...

[PhLR]

Thanks! Happy to chat if you want to share some of the ideas you had

On: Show HN: Skip the SSO Tax, access your user data w...

[PhLR]

'Auditing user accounts in SaaS applications' is a pretty good summary of what the current version is about. The 'SSO-Tax' has become a synonym for the extra charges of SaaS vendors in which they usually bundle 3rd party SSO, SCIM and SAML.

What other tooling would you want it to integrate with?

On: Show HN: Skip the SSO Tax, access your user data w...

[PhLR]

Great to see that we were not alone with the struggles! Let me know if you are up for a quick chat. Would love to learn more about your situation and how OpenOwl could help fix it. If you are up for it, my contact is in the bio

On: Show HN: Skip the SSO Tax, access your user data w...

[PhLR]

That's the spirit! Thanks for the kind words.

Indeed, ease of use is incredibly important. After all this is a tool that needs to be used non-developer IT admins as well.

On: Show HN: Skip the SSO Tax, access your user data w...

[PhLR]

In future versions it will be possible to do the same with, for example, your Google SSO sign-in and 2FA enabled. The reason for the limitation is that we simply wanted to get it out into the world and see if anybody is as excited about it as we are.

[tracker1 → PhLR]

For reference, the azure client, opens a browser for the login, which redirects to a dns address that equates to "localhost" on a port that will effectively get the final auth tokens to the local instance, which then persists and shuts down the service. Should be able to do very similar.