We would like to implement SAML based SSO for our organization. We do not want employees to be able to access specific accounts outsides of specific hours and IP ranges. (We do not want to setup a VPN for that use-case for multiple reasons)

Question: Is it possible to somehow log the user out of a specific account that he signed into via SAML when his IP changes and is not part of the allowed range anymore?

Things we want to avoid: - Browser extensions - Polling of any kind - No additional infrastructure if possible

I really don't know if this is possible but would really appreciate your help.

  • IP ranges? That's going to backfire in amusing ways. Why can't you set up a VPN? – Fund Monica's Lawsuit Jul 8 at 1:37

Pure SAML - no, it's not possible.

This is a frequent scenario in regulated industries, e.g. user comes to work in the morning, signs on to a sensitive service, performs tasks, does not sign out at the end of the work day, then takes their device home..and they're able to access the sensitive service. It's a tougher problem to solve if the sensitive service is hosted outside of company "walls". Tougher but not impossible, the devil is in the details.

Assuming you're going with Web Browser SSO profile in SAML, your control point where you can apply your IP/hours constraint is limited to the identity provider. To be more precise, it's limited to the authentication event, i.e. when a user signs in to the identity provider. Subsequent clicks by the user that may launch or target a particular application (acting as a SAML service provider) will bypass the identity provider most of the time. The identity provider will not see the request so you have no way of applying your policy.

If you're okay with doing this at the identity provider during authentication, some SAML identity providers will allow you to implement a policy that looks at hours of operation and/or IP ranges to allow or deny authentication. Some identity providers with more sophistication will allow you to use the change of IP (and/or date/time) as triggers for requiring reauthentication...which would then deny access as the next step.

The usual solution to this problem involves multiple layers where SSO is just one brick in the proverbial wall.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.