“Every solution to every problem is simple. It’s the distance between the two where the mystery lies.” ― Derek Landy, Skulduggery Pleasant After my first blog on how to make logging out possible for a single service within the SURFconext platform, we got some feedback on the proposed solution:
- nice job, this works for us
- we don’t like this solution, because it’s not single sign-out
- will there be a ‘real solution’ for the single sign-out problem instead of this ‘work around’?
The involved IdP and SP are quite happy with the solution described and our help with the implementation. The proposed solution is not a ’work around’; it is simply one way of making sure logging out by users works for your service. It is not the same as federated single sign-out and was never intended as such. Furthermore, the reason why SURFnet does not support single sign-out in SURFconext is because we feel it cannot be implemented in a reliable way. Due to the feedback we received, I decided to write this blog on another solution for the logging out issue also supported by SURFconext. This second solution also does not solve single log-out, but if you want to make sure users are logged out from your service after they’ve hit the logout button, maybe this is the solution for you: Simply turn off the single sign-on functionality within the SURFconext platform for your service.
Turn off the single sign-on
This means that when a user wants to log in to your service, they always have to use their institutional credentials. Even if they have logged in to other services connected to SURFconext before going to your service (in the same browser session), they will have to authenticate again. If they log out at your service and come back, they will also have to log in again. This means that you, as a Service Provider, have more control over the user session, and that you are able to reliably log out a user from your service. This functionally only influences your own service; other services connected to SURFconext that have single sign-on enabled, will still work the way users are used to. So, why would you connect your service to SURFconext if you don’t have the convenience of single sign-on? The answer to this question is: it’s user friendly. Users will still be able to log in with their institutional credentials. Advantages of this are that they don’t have to remember multiple usernames and passwords and you don’t have to manage (lost) user accounts. How it works technically is described in the Get conexted wiki:
If you set the ForceAuthn parameter to true, single sign-on is disabled (default value is false). If the user had a previously established session with SURFconext, this will be ignored and the user will be requested to authenticate again. This will most likely result in the user needing to select his Identity Provider in the SURFconext WAYF selection page and a subsequent authentication at that Identity Provider. There is at least one connected Service Provider that has successfully implemented this option within SURFconext. Depending on what you’re going for, it will work if you want to be sure users are logged out after hitting the log out button. Both this solution as the one explained in my previous blog are relatively simple to implement, you just have to figure out how you want to serve your users. We’re always interested in your experiences and questions, so please feel free to leave your comments below and/ or contact me directly.