Hacker News Reader

Comment by grinich | Hacker News Reader

SLO is such an incredible pain in the ass. I'm the founder of WorkOS[0]and I have been struggling with how to address this problem for 2 years now. There's no elegant solution.

We've taken the approach of building a second API that integrates directly with the directory systems of record (Workday, Gusto, BambooHR, SCIM, etc.). These are often the actual "source of truth" and a more dependable source for the group membership changes that should trigger de-provisioning. But unfortunately even SCIM isn't well enough supported yet to be considered a base standard. (It's worse than SAML.)

Enterprise authentication and authorization is totally fvcked. Trying to fix it brick-by-brick.

[0] https://workos.com

View on HN

I think it's a pain because it's one of those things you just can't guarantee. I can (try to) promise you as an IdP that website X can't just randomly ask for your information and be given it without your consent.

But once I've given that information away, it's irreversible. You can't unsend data. You can ask nicely for it to be deleted, or revoke future access, but unless you have a time machine, federated SLO for all parties in a session ought to just be considered an impossibility, and planned for accordingly with short sessions.

> But once I've given that information away, it's irreversible.

In an enterprise environment all software has a basic level of trust of "this will try to do what it claims to do". That means the ID provider can directly ping the server of whatever service was issued the data or login cookies and say "this data should be deleted please".

If you administer every SP, it starts to become a possibility. But as TFA mentions right off the bat, that's atypical.

And even if you do exclusively use SPs that support SLO, is the user supposed to wait while the IdP does all of that outreach in order to know that it worked, or 97% worked because one timed out? That depends on whether the user should even care about the outcome -- if they should care, then do they get an email when it achieves 100% hours/days later when that down-at-time-of-SLO SP is back up? Should they report an incident if they never see a success report?

> But as TFA mentions right off the bat, that's atypical.

So atypical that it borders on inconceivable. There's almost always an external party in there.

But if you somehow end up totally internal sure, try the back-channel binding. You get to toss SOAP messages around, and it might work. Of course now one of the invariants you built around no longer holds ("SAML works without having to let the IdP talk to the SPs" oh my sweet summer child...)

Just don't try SLO over the front channel, or else you'll have the joyous UX of a user clicking "log out" and all of a sudden they're bouncing logout messages back and forth between the IdP and two dozen internal applications. Hope the ninth app in line isn't down for maintenance or your <LogoutResponse> never makes it back to the IdP and the user wonders why they're staring at a server error page for an app they haven't used in hours and why half their environment is logged in and the other half isn't...

Dealing with auth, including single lockout, is all much easier if you can put all your systems behind a single reverse proxy on a single domain.

(Certainly that's not always possible, but for many systems it is).

Like https://www.forgerock.com/ formerly known as OpenAM / OpenSSO.

It's not fun to administer.

There's a reason huge enterprises still pay big money for stuff like CA's Siteminder: it's way easier to bolt an agent along side your crappy internal app that thinks about this stuff for you.

All the SLO solutions struggle with the fact session IDs are disassociated with the IdP except by policy. Policy is insufficiently strong.

The session ID needs to be cryptographically associated with the IdP so if you blow away the IdP session unilaterally you cannot decrypt or access any SPs session.

For instance but probably not sufficient as a solution, you could imagine IdPs running a JavaScript inside the SPs client session that provides half of a key pair and the SP providing the other half that combined form the session ID. Then once SLO is initiated the IdP script no longer provides its key.

I have not deeply thought further about how to completely design a flow like this but I strongly believe this kind of cryptographic session ID is the likely idea that will lead to a solution.

Yeah, it seems kind you want a refresh token that you periodically validate against the source of truth to handle these cases.

Reply on news.ycombinator.com