4 ms·

How does the logout process work? Or what happens when the user is removed from the idp? How does service provider know the user is supposed to be logged out?

ak217 7y ago
http://xacmlinfo.org/2013/06/28/how-saml2-single-logout-works/ http://xacmlinfo.org/2013/06/28/how-saml2-single-logout-work... The scenario you describe would be addressed by a logout request or session expiration.
maxymajzr 7y ago
In most cases, SP doesn't know user is removed from IdP. If there's a need for such feature, you resort to shared sessions - IdP has control of storage service where SP's save sessions (say, Redis). Once user is removed from IdP, IdP deletes the session record in Redis and SP loses all user info. This implementation happens rarely. The single logout process is often flawed since it depends on SP's accurately processing the request and returning the user back to IdP if a session has been successfully destroyed. This often fails due to network connectivity, problems with session destroying at the SP, SP's not implementing the SingleLogout properly etc. What I've experienced and seen in many cases is that IdP simply kills the session it has on the user and stops right there, then the rest of the SP's handle it through back-channel. I work in this area so I'm relaying my experience through past 10 years of implementing SSO for various enterprises. In reality, the SAML protocol is quite straight-forward but something odd happens when people hear the term SSO. It's not magic, it's quite trivial but takes a bit of discipline to grasp it fully and implement properly.
- recursive 7y ago
  > it's quite trivial I've been tasked with authenticating in an existing application via SAML 2.0 I've got the whole SAML 2.0 specification printed and sitting on my desk right now. It sure doesn't look trivial.
  - deleted 7y ago
    [deleted]
  - CaliforniaKarl 7y ago
    When people say "Don't roll your own encryption" or "Don't implement $ALGORITHM, just use libsodium", I think that also applies to web authentication (be it OAuth or SAML). If you are the 'client' that wants to authenticate an incoming user, then I'd point you to an existing SP like Shibboleth or SimpleSAMLPHP or even CILogon (which bridges SAML and OAuth). If you are handing out authentications, then you are an IdP and I'd point you to something like Shibboleth or ADFS or Okta. It is good to have the relevant RFCs to hand, but I would not make an implementation from scratch, unless there was a very good reason for it.
    - recursive 7y ago
      I'm trying to build an "SP" or "relying party" as I've learned in the jargon of the domain. Building an implementation from scratch is the last thing I want to do. I feel like I'd rather pull out my own teeth. But a difficulty of finding any information about it has lead me to start reading all the official specs as a kind of last resort. In my initial research, I did discover Shibboleth, but was under the impression that it was an IDP only. I will check out the SP component, because I would love to not implement it from scratch. At first glance, I see this: https://www.shibboleth.net/products/service-provider/ https://www.shibboleth.net/products/service-provider/ It basically seems pretty opaque. The downloads at https://shibboleth.net/downloads/service-provider/latest/ https://shibboleth.net/downloads/service-provider/latest/ don't really provide much clue of how to build them or incorporate them into my app, which is written in a different language than any of these source files. I'll keep looking.
      - danellis 7y ago
        If you're willing to use PHP, there's also "the award-winning" SimpleSAMLphp (https://simplesamlphp.org/ https://simplesamlphp.org/), which can operate as IdP or SP. I can tell you that many big names in the TV Everywhere space are using it.
- i2shar 7y ago
  What's the best practice on when a user session is destroyed at the SP's end? After receiving the LogoutResponse from IdP or before sending the LogoutRequest to IdP?
dcosson 7y ago
The other responses answer your direct question, but I was confused about similar flows when learning about SAML so I'll comment in case this is helpful. SAML is just an authentication protocol, it doesn't really handle user provisioning. Which was confusing to me, because any time you'd use it you typically also need some kind of provisioning mechanism. SAML does have a concept of "just in time" provisioning, which is what I've seen small SAAS companies typically support when they say they have SAML support. But basically all it can handle is creating accounts in the SP the first time a new person logs in (with valid credentials signed by the IDP). For user provisioning though what you really need is full programmatic CRUD access for accounts in the SP, which is outside the scope of SAML. I don't really understand why the SAML protocol bothers having such half-baked support at all, because you immediately run into issues. For example, giving some users different permissions than others in the SP, or updating accounts in the SP that already exist. For user provisioning, for SPs that support it you can use the SCIM protocol alongside SAML, which gives you full control over provisioning accounts the way you need to. Then for instance instead of just logging someone out of the SP when they were removed from the IDP, it can fully deprovision the account in all your SPs as well so you're not left with orphaned accounts sitting around.

ak217 7y ago

http://xacmlinfo.org/2013/06/28/how-saml2-single-logout-works/ http://xacmlinfo.org/2013/06/28/how-saml2-single-logout-work... The scenario you describe would be addressed by a logout request or session expiration.

maxymajzr 7y ago

In most cases, SP doesn't know user is removed from IdP. If there's a need for such feature, you resort to shared sessions - IdP has control of storage service where SP's save sessions (say, Redis). Once user is removed from IdP, IdP deletes the session record in Redis and SP loses all user info. This implementation happens rarely. The single logout process is often flawed since it depends on SP's accurately processing the request and returning the user back to IdP if a session has been successfully destroyed. This often fails due to network connectivity, problems with session destroying at the SP, SP's not implementing the SingleLogout properly etc. What I've experienced and seen in many cases is that IdP simply kills the session it has on the user and stops right there, then the rest of the SP's handle it through back-channel. I work in this area so I'm relaying my experience through past 10 years of implementing SSO for various enterprises. In reality, the SAML protocol is quite straight-forward but something odd happens when people hear the term SSO. It's not magic, it's quite trivial but takes a bit of discipline to grasp it fully and implement properly.

recursive 7y ago
> it's quite trivial I've been tasked with authenticating in an existing application via SAML 2.0 I've got the whole SAML 2.0 specification printed and sitting on my desk right now. It sure doesn't look trivial.
- deleted 7y ago
  [deleted]
- CaliforniaKarl 7y ago
  When people say "Don't roll your own encryption" or "Don't implement $ALGORITHM, just use libsodium", I think that also applies to web authentication (be it OAuth or SAML). If you are the 'client' that wants to authenticate an incoming user, then I'd point you to an existing SP like Shibboleth or SimpleSAMLPHP or even CILogon (which bridges SAML and OAuth). If you are handing out authentications, then you are an IdP and I'd point you to something like Shibboleth or ADFS or Okta. It is good to have the relevant RFCs to hand, but I would not make an implementation from scratch, unless there was a very good reason for it.
  - recursive 7y ago
    I'm trying to build an "SP" or "relying party" as I've learned in the jargon of the domain. Building an implementation from scratch is the last thing I want to do. I feel like I'd rather pull out my own teeth. But a difficulty of finding any information about it has lead me to start reading all the official specs as a kind of last resort. In my initial research, I did discover Shibboleth, but was under the impression that it was an IDP only. I will check out the SP component, because I would love to not implement it from scratch. At first glance, I see this: https://www.shibboleth.net/products/service-provider/ https://www.shibboleth.net/products/service-provider/ It basically seems pretty opaque. The downloads at https://shibboleth.net/downloads/service-provider/latest/ https://shibboleth.net/downloads/service-provider/latest/ don't really provide much clue of how to build them or incorporate them into my app, which is written in a different language than any of these source files. I'll keep looking.
    - danellis 7y ago
      If you're willing to use PHP, there's also "the award-winning" SimpleSAMLphp (https://simplesamlphp.org/ https://simplesamlphp.org/), which can operate as IdP or SP. I can tell you that many big names in the TV Everywhere space are using it.
i2shar 7y ago
What's the best practice on when a user session is destroyed at the SP's end? After receiving the LogoutResponse from IdP or before sending the LogoutRequest to IdP?

dcosson 7y ago

The other responses answer your direct question, but I was confused about similar flows when learning about SAML so I'll comment in case this is helpful. SAML is just an authentication protocol, it doesn't really handle user provisioning. Which was confusing to me, because any time you'd use it you typically also need some kind of provisioning mechanism. SAML does have a concept of "just in time" provisioning, which is what I've seen small SAAS companies typically support when they say they have SAML support. But basically all it can handle is creating accounts in the SP the first time a new person logs in (with valid credentials signed by the IDP). For user provisioning though what you really need is full programmatic CRUD access for accounts in the SP, which is outside the scope of SAML. I don't really understand why the SAML protocol bothers having such half-baked support at all, because you immediately run into issues. For example, giving some users different permissions than others in the SP, or updating accounts in the SP that already exist. For user provisioning, for SPs that support it you can use the SCIM protocol alongside SAML, which gives you full control over provisioning accounts the way you need to. Then for instance instead of just logging someone out of the SP when they were removed from the IDP, it can fully deprovision the account in all your SPs as well so you're not left with orphaned accounts sitting around.