Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: KC Release 3.0, 1.0.3
    • Fix Version/s: KC Release 3.0, 1.0.3
    • Component/s: Development
    • Labels:
      None
    • Rice Module:
      Rice Core
    • Application Requirement:
      KC
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      This was approved by the KAI

        Attachments

          Issue Links

            Activity

            Hide
            gtaylor Garey Taylor added a comment -

            Scott has a patch for this one. We're planning on looking at it next week at the face-to-face.

            Show
            gtaylor Garey Taylor added a comment - Scott has a patch for this one. We're planning on looking at it next week at the face-to-face.
            Hide
            jjhanso Jeremy Hanson added a comment -

            Assigning to you because of Scott's patch for now.

            Show
            jjhanso Jeremy Hanson added a comment - Assigning to you because of Scott's patch for now.
            Hide
            ewestfal Eric Westfall added a comment -

            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.

            Show
            ewestfal Eric Westfall added a comment - 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.
            Hide
            sgibson Scott Gibson (Inactive) added a comment -

            Here is the list of functional requirements after circling back with the SME to get some feedback:

            1. Logoff Action: The system shall provide a Log Off action that exhibits the following behavior:

            a. Log Out From Initial Login: If the user is logged in to the application through the initial login only (the primary login - not the “backdoor), the Log Off action causes the following:

            i. Authentication and Authorization is Terminated: All authentication and authorization associated with the user’s credentials and session is terminated.

            ii. Return to Start Page: Logging out of the application shall return the user to the application “start” where the user can execute the Log In action.

            iii. Authentication Required for Access: The user must successfully re-enter their login information the using the Log In Action to gain access.

            b. Log Out From Backdoor Login: If the user is logged in through the backdoor login and s/he executes the Log Off action

            i. The Log Out action shall terminate all the authentication and authorization the user received through the backdoor login but shall not terminate the user’s application session.

            ii. The user shall remain authenticated and authorized based using the credentials from their initial or primary login.

            iii. A second execution of the Log Out shall behave as in a Log Out From Initial Login (see above).

            Other points:

            · The Log Out/Off button should be located as displayed in the your Mock Screens: <https://wiki.kuali.org/display/KULRICE/September+16%2C+2010+meeting> https://wiki.kuali.org/display/KULRICE/September+16%2C+2010+meeting

            · Adding a permission that would govern access to and display of the backdoor login can be considered a desirable, future enhancement; it is not required at this time. In the case where the user did not have the backdoor permission, only a single button would be displayed with the text changing appropriately.

            Show
            sgibson Scott Gibson (Inactive) added a comment - Here is the list of functional requirements after circling back with the SME to get some feedback: 1. Logoff Action: The system shall provide a Log Off action that exhibits the following behavior: a. Log Out From Initial Login: If the user is logged in to the application through the initial login only (the primary login - not the “backdoor), the Log Off action causes the following: i. Authentication and Authorization is Terminated: All authentication and authorization associated with the user’s credentials and session is terminated. ii. Return to Start Page: Logging out of the application shall return the user to the application “start” where the user can execute the Log In action. iii. Authentication Required for Access: The user must successfully re-enter their login information the using the Log In Action to gain access. b. Log Out From Backdoor Login: If the user is logged in through the backdoor login and s/he executes the Log Off action i. The Log Out action shall terminate all the authentication and authorization the user received through the backdoor login but shall not terminate the user’s application session. ii. The user shall remain authenticated and authorized based using the credentials from their initial or primary login. iii. A second execution of the Log Out shall behave as in a Log Out From Initial Login (see above). Other points: · The Log Out/Off button should be located as displayed in the your Mock Screens: < https://wiki.kuali.org/display/KULRICE/September+16%2C+2010+meeting > https://wiki.kuali.org/display/KULRICE/September+16%2C+2010+meeting · Adding a permission that would govern access to and display of the backdoor login can be considered a desirable, future enhancement; it is not required at this time. In the case where the user did not have the backdoor permission, only a single button would be displayed with the text changing appropriately.
            Hide
            sgibson Scott Gibson (Inactive) added a comment -

            Logoff button was added which will clear session and redirect to a configurable url aftwards. The url can be set as a Parameter NS:KR-NS, Detail:ALL, Name:LOGOFF_REDIRECT_URL or as a config property: rice.portal.logoff.redirectUrl. The parameter takes precedence.

            Specs match the prior comment (the backdoor permissions were not implemented).

            The backdoor login will be cleared if the user click login with an empty id or id matching the non-backdoor user.

            Show
            sgibson Scott Gibson (Inactive) added a comment - Logoff button was added which will clear session and redirect to a configurable url aftwards. The url can be set as a Parameter NS:KR-NS, Detail:ALL, Name:LOGOFF_REDIRECT_URL or as a config property: rice.portal.logoff.redirectUrl. The parameter takes precedence. Specs match the prior comment (the backdoor permissions were not implemented). The backdoor login will be cleared if the user click login with an empty id or id matching the non-backdoor user.
            Hide
            sgibson Scott Gibson (Inactive) added a comment -

            The redirect config param for the logout is actually

            rice.portal.logout.redirectUrl

            Show
            sgibson Scott Gibson (Inactive) added a comment - The redirect config param for the logout is actually rice.portal.logout.redirectUrl

              People

              • Assignee:
                sgibson Scott Gibson (Inactive)
                Reporter:
                tschneeb Travis Schneeberger
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: