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.
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.
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".
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?
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...
(Certainly that's not always possible, but for many systems it is).
It's not fun to administer.
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.
I would log in to the main page where we can view government services. Then I would click through to the ATO (our IRS) to see some statements or whatever. I would then close the window and log out in MyGov then log back in with my wife's account. Click through to the ATO would show my details instead of hers. IIRC logging out wouldn't work either since that would mess up the session, I'd have to come back later.
Couldn't find anywhere to report this so I ignored it. I think they fixed it now.
https://www.smh.com.au/technology/revealed-serious-flaws-in-...
I was at Centrelink's IT department for just a couple months, and that was the only time in my decades-long consulting career that I had seen an adult man cry. Not for personal reasons. Work-related reasons. Several men, on multiple occassions, for different reasons.
That place crushed their spirits, and the tears just had to come out...
This one guy I knew told me that he had seen meetings dedicated to working out how they could spend money since they hadn't spent the whole budget yet. Services run over hundreds of servers when it could be done in one just to keep the whole team of system admins employed.
Government departments are filled with bloat to a level you wouldn't believe.
I think this is fairly common in government outside of Australia as well. With the budget it’s use it or lose it, so you better find ways to spend it, or you’ll have less margin next year when you might actually need it.
Almost all the higher ups are paid out of budgets based on how much you spend- so the supervising agency gets their 15 percent admin fee, your managers are part of the indirect cost pool etc.
If you spend 50% of budget it is game over upstairs. And you lose the money at year end, and future allocation is dropped. And all the budgets in long chain up get messed up. Almost nothing gets more attention and priority than this.
Imagine fixing an issue on a Model 204 mainframe, with a perpetually dwindling number of people you can rely on for help, knowing that if you don't fix it, people don't get their welfare cheque.
High stress, low reward. Unsung heroes in my books.
A "fun" anecdote I heard was that every 1 day of outage of Centrelink's mainframe would result in 5-7 children with broken bones.
You see, some alcoholic high-strung fathers in rural communities were spending their welfare cheques mostly at the local bottleshop. If the cheques stopped, their booze supply stopped, and their withdrawal symptoms would send them into mad rage. All too often, they'd take it out on their kids.
Apparently someone at Centrelink was tracking this kind of stuff by gathering paediatric admissions data from hospitals.
While I was there they had a 3-day outage that everyone just laughed off. You do the maths.
I asked about implementing logout cause I saw it was a thing in the SAML docs. The customer didn't care so our app trashed it cookies as usual and didn't report it to the IdP. It just wasn't worth the time.
In practice, logout in a federated environment seems to be
* A user logs into apps A, B, C (...)
* While using app C, the user clicks logout. App C trashes their cookies
* With luck(!) the IdP provides a low friction logout endpoint – think "GET /logout?redir=http://foo.bar/logged-out".
The app redirs to that endpoint, the IdP trashes cookies and directs back to the apps "you have been logged out" page.
Apps A and B? Go with god, and good luck. Keep your sessions short.