search

SAML-Toolkits / ruby-saml

SAML SSO for Ruby
MIT License
908 stars 567 forks source link

Enforcing Session Timeouts or Continuously Re-authenticating Against the IdP? #464

Closed acontero closed 2 months ago

acontero commented 6 years ago

Hey, this is sort of a general inquiry rather than an issue with particular code. But in your Best Practices Docs for SAML it talks about enforcing session timeouts. https://developers.onelogin.com/saml/best-practices-and-faqs And it says:

Don’t let a user be signed on indefinitely: expire idle user sessions. Use the session timeout value from the SAML response or have a setting per account. When a user clicks a link in the app after the session has expired, your app should send a SAML request to the identity provider to see if the user is still authorized to sign in to your app.

I have a customer who is concerned about the session never expiring so I was looking into the SAML token expiration and this advice in your docs. However, they would ideally like us to authenticate with their IdP on every request in our app, which is too much for us. So if not on every request, at least a few times a day. It doesn't seem sufficient to them to just timeout based on the SAML token expiration. And in the above advice, it says "your app should send a SAML request to the identity provider to see if the user is still authorized to sign in to your app." I'm wondering if this suggests to do this without user interaction? Don't we only make SAML requests upon user initiation? Does anyone do this behind the scenes without the user seeing it? Is that even possible, and I didn't realize? Also, this seems to go against the SSO flow, no?

Anyways, wondering how others are handling this sort of thing, and if there is a best practice solution that I'm not aware of. Thanks!

pitbulk commented 6 years ago

If your IdP supports it, you can execute AuthNRequest with Passive="true" to verify if you get back a SAMLResponse on your ACS endpoint with Status="Sucess", otherwise, the SAMLResponse will have a different status that means that the IdP session was closed and re-authentication is required, then on the app side you can close the session and redirect the user to start a SP-initiated SSO.

About "SAML SLO best practices", I can't suggest you any good read. Maybe you can find interesting this read:

acontero commented 6 years ago

@pitbulk Thanks so much for this info! It's possible that my customer wants SLO which we have not yet implemented. But I think the passive flag sounds more along the lines of what they are requesting. I had no idea you could make a passive SAML auth request. Fascinating! So do you know if it is customary for people to make regular passive auth requests in order to ensure that the user is still valid/authenticated according to the IdP? Assuming their IdP supports passive auth of course. I certainly don't want to do this all the time, with every request in my company's app, but I'm wondering what the standard practice is for companies who offer SSO with their product. My customer is claiming that this feature is offered by other software companies. Identity and authentication management is just not our specialty which is why I'm turning to you and this community. Thanks again! :)