5 ms·

SLO is the nightmare nobody touches. In practice, logout in a federated environment seems to be * A user logs into apps A, B, C (...) * While using app C, th

SLO is the nightmare nobody touches. 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 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.

mooreds 6y ago
Doesn't it depend on who controls apps A and B? If they are COTS or created by different parties, then all best are off. But if all three apps are created by the same org, which can specify standards, doesn't one have some hope?
- emodendroket 6y ago
  The whole point of SAML is that you can manage your users for third-party applications in your normal user store instead of needing to provision accounts in multiple places.
- pionar 6y ago
  Somewhat, but it still requires a lot of storage of state and coordination between systems. This isn't SAML specific, it's a property of any federated login (SSO) protocol.
varikin 6y ago
I had to implement a SP SAML logic at a previous job. The customer who wanted it just kept telling us to enable some apache mod and it works, except when you have a java fat jar without Apache, you have to add your own endpoints and we had to add integration for native clients. 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.
hnick 6y ago
I ran into a bug like this in Australia's MyGov system. 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.
- mjthompson 6y ago
  Not the first time they've ignored issues in myGov. This guy tried endlessly to contact them about a XSS vulnerability to deaf ears: https://www.smh.com.au/technology/revealed-serious-flaws-in-mygov-site-exposed-millions-of-australians-private-information-20140514-zrczw.html https://www.smh.com.au/technology/revealed-serious-flaws-in-...
  - jiggawatts 6y ago
    You've got understand that the orgs involved in myGov, such as Centrelink, Medicare, and the ATO are special bad. They're dysfunctional to a degree most people simply cannot believe. 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...
    - deleted 6y ago
      [deleted]
    - mjthompson 6y ago
      I should have said that I don't blame any individual dev or sysadmin for failing to respond. It's a deeply entrenched organisational issue. 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.
jcims 6y ago
Cookies need an alias mechanism. Combined with explicit cross-origin entitlement you could just keep a single cookie to satisfy all of those sessions.
- grinich 6y ago
  A merkle tree for cookie validation would be cool.
grinich 6y ago
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 https://workos.com
- sunir 6y ago
  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.
- ec109685 6y ago
  Yeah, it seems kind you want a refresh token that you periodically validate against the source of truth to handle these cases.
- andrewstuart2 6y ago
  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.
yread 6y ago
Apps A and B could just keep a list of expired cookies and the IdP could add to that list using a server-to-server call.
- bandie91 6y ago
  the main idea of SAML is not to do direct server-to-server communication.
- kevincox 6y ago
  This is how it should work. But I don't think any popular system implements this.

mooreds 6y ago

Doesn't it depend on who controls apps A and B? If they are COTS or created by different parties, then all best are off. But if all three apps are created by the same org, which can specify standards, doesn't one have some hope?

emodendroket 6y ago
The whole point of SAML is that you can manage your users for third-party applications in your normal user store instead of needing to provision accounts in multiple places.
pionar 6y ago
Somewhat, but it still requires a lot of storage of state and coordination between systems. This isn't SAML specific, it's a property of any federated login (SSO) protocol.

varikin 6y ago

I had to implement a SP SAML logic at a previous job. The customer who wanted it just kept telling us to enable some apache mod and it works, except when you have a java fat jar without Apache, you have to add your own endpoints and we had to add integration for native clients. 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.

hnick 6y ago

I ran into a bug like this in Australia's MyGov system. 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.

mjthompson 6y ago
Not the first time they've ignored issues in myGov. This guy tried endlessly to contact them about a XSS vulnerability to deaf ears: https://www.smh.com.au/technology/revealed-serious-flaws-in-mygov-site-exposed-millions-of-australians-private-information-20140514-zrczw.html https://www.smh.com.au/technology/revealed-serious-flaws-in-...
- jiggawatts 6y ago
  You've got understand that the orgs involved in myGov, such as Centrelink, Medicare, and the ATO are special bad. They're dysfunctional to a degree most people simply cannot believe. 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...
  - deleted 6y ago
    [deleted]
  - mjthompson 6y ago
    I should have said that I don't blame any individual dev or sysadmin for failing to respond. It's a deeply entrenched organisational issue. 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.

jcims 6y ago

Cookies need an alias mechanism. Combined with explicit cross-origin entitlement you could just keep a single cookie to satisfy all of those sessions.

grinich 6y ago
A merkle tree for cookie validation would be cool.

grinich 6y ago

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 https://workos.com

sunir 6y ago
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.
ec109685 6y ago
Yeah, it seems kind you want a refresh token that you periodically validate against the source of truth to handle these cases.
andrewstuart2 6y ago
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.

yread 6y ago

Apps A and B could just keep a list of expired cookies and the IdP could add to that list using a server-to-server call.

bandie91 6y ago
the main idea of SAML is not to do direct server-to-server communication.
kevincox 6y ago
This is how it should work. But I don't think any popular system implements this.