It's been agreed by the KAI that a logoff button is acceptable, however we haven't really gotten specs for how this should work. I sent the following email to try and extract some of this information and provide some options for how we can approach it. Hopefully will hear back soon on how best to proceed from an implementation perspective:
The backdoor functionality as it exists currently is meant for the kind of testing scenarios that you are describing Kenton. You can enter a different principal’s name into the backdoor login text field and then hit the “login” button to switch to that new user. Is this a matter of the KC testers not being aware of this functionality or it not providing what they need?
Now I think I had heard that part of the problem here was that the backdoor didn’t transfer from KC (where the backdoor is performed) into Rice when Rice is running standalone. This can actually be fixed fairly easily if it’s a problem by ensuring that links from the KC portal into Rice include a “backdoorId” request parameter in the URL. And that can actually be done automatically by the portal framework if it’s not doing it already in KC.
Regarding implementing a “logout” function, I think we (on the Rice team) will need some more information on how this should work before we can proceed. I’m not sure if the functional specs for how this should work have been identified (please let me know if I missed it or if it was discussed in the meeting that I missed). If not, I see some options:
Option 1 – Log off button performs a “backdoor” logout first, and then performs a “session” logout the next time it is clicked.
This option would work as follows:
If the user is logged in and is currently “backdoored” as someone else, then the logout button will “un-backdoor” them and return the session to the original authenticated user
If the user is not “backdoored” (or if this is a production environment where backdoor is disabled and prohibited), then the logout button will invalidate their session, effectively performing a “full” logout
Option 2 – Log off button will perform a full “session” logout, regardless of what the current state of backdoor is.
This option would work as follows:
If the user is logged in and “backdoored” as someone else, then the logout button will invalidate their session, performing a “full” logout
If the user is just logged in, but not “backdoored” it will do the same as above
We (here at IU) had a request to provide the ability to un-backdoor, so we implemented something simple for our IU rice implementation where someone can leave the backdoor login field empty and click the “login” button and that would effectively clear the backdoor. I think Option 1 above would provide for this kind of requirement as well, but I’m open for how others might want to handle this. The “blank” login is one way, a special “backdoor logout” button is another way (I think that will probably be a bit of a kludge though), and what’s proposed in option 1 is another way.
Beyond this, there are a couple of other things we will need to clarify about the requirements in order to implement this.
What should happen when the user clicks the “logout” button? Should it take them to a screen telling them they should close their browser to be safe? Or should it immediately take them to the login screen again? Many applications that I’ve seen do the first of these and then provide a link to close the window, to log in again, or to perform a logout of the SSO (this doesn’t necessarily fulfill the requirements of a “single logout” from an SSO but at least any new applications they come into will require them to re-authenticate). Do we want to do something similar?
I’m assuming that the logout button should show up in the portal next to where the login button shows currently?
Is it a requirement at the current time to make access to the backdoor login based on a permission? I remember discussing it, but I don’t think it was necessarily a requirement for what KC needs. If not then we can jira it up and tackle it later (I think it’s a good enhancement).
Are there any other preferences on how this looks in the UI or how things from from the perspective of the end user?
If we can get answers to the questions above then we can work on getting this implemented.