Oct 25, 2016, 8:55 AM
3 Posts

Trying to log out after SAML authentication

  • Category: Domino Server
  • Platform: All Platforms
  • Release: 9.0.1
  • Role: Administrator,Developer
  • Tags: saml,logout,authenticaion
  • Replies: 4

We were recently asked to incorporate a single signon to our web application (NOT notes client).   This went pretty well - we are now authenticating our users via SAML 2 using a 3rd party product.  However, an unexpected side effect came along with it:  I can't log users out.  If I try to use our standard logout URL (db.nsf?logout&redirectto=anotherdb.nsf) I can hit the back button and still have a session ID in the browser.  To be clear, I am not simply seeing the cached version of the page.  I can maneuver around and do everything that I could do in a normal session.  Also, I can see the session ID in Firefox's SSO tracers plugin.  Is there any way that I can manually kill the session?

Oct 25, 2016, 11:58 AM
93 Posts
Users need to log out of the SAML IdP as well as the Domino server to be truly logged out ...
Oct 25, 2016, 12:18 PM
3 Posts
Response from IBm

Thanks so much for your response.  I received the following email from IBM after opening a ticket with them.

 

Unfortunately, Domino does not currently implement a SAML 2.0 single logout feature. The logout of a session is configured in the identity provider side and it is configured in the idp catalog database.

Configuring the Single logout URL means that users are logged out of the identity provider side when they log out of IBM Domino
This is a known SAML configuration limitation that is planned to be addressed in an upcoming release but there is no exact timeline for it.

I have subscribed this PMR to SPR # XHXH994598 - Enhancement request for Domino to have a logout feature when using SAML authentication.

Oct 25, 2016, 1:55 PM
93 Posts
You can simulate that in your code easily enough
Just make the logout button in your application redirect the end user's browser to the IdP's logout URL after logging them out of your application. The drawback to this angle is that if the IdP serves multiple applications, the end users might be annoyed that they now need to retype their password to get into, say, the expense reimbursement system.  In this model, you need a shift in mind set -- logging out of an individual application is meaningless, you need to log out of the IdP directly, kill your browser window, or lock your workstation in order to protect your system.

Another approach that some folks use is to configure their IdP to not generate session cookies and require the end user to log in each time. This provides a central point of authentication, but still requires the end user to type and retype their username and password again and again and again. Some people consider this to be a good thing.
Oct 25, 2016, 6:34 PM
3 Posts
Customer IDP

Thanks again Dave.  Yeah, the problem here is that the users are customers of our and our coming from their intranet.  Doubtful that they would want to be logged out of their system :-).

I've decided to try to track a change to the DomAuthSessID as I've noticed that changes when a ?logout is executed.