Closed ghudgens closed 3 years ago
This might occur when you still have a valid webbrowser session, although it looks like a new browser login was triggered. Can you please remove cookies in your browser and try again?
@ghudgens When you clicked the "Renew Session" button, and the browser opens up, did you see a login page where you enter username/password, or did it go straight to the "Approve" page?
As @efef said, if you did not see a login page and it went straight to the "Approve" page, then it means the browser session was still active, and the app wouldn't be able to actually renew the session (which is a bug).
@fkooman: Could this be because maybe the session expiry was shorter than 1 week, so we show the "Renew Session" button all the time, even in the first 30 mins, when the browser session was still valid?
@fkooman: Could this be because maybe the session expiry was shorter than 1 week, so we show the "Renew Session" button all the time, even in the first 30 mins, when the browser session was still valid?
Yes. It seems nobody closes their browser anymore, either because they don't, or because it is not possible, e.g. iOS, so this can happen if you try to 'reauthorize' within 30 minutes of getting the initial authorization.
I wonder whether it is possible to log the user out immediately before redirecting to the redirect_uri
...
Update: no, because there is all kinds of difficulty regarding external authentication sources... technically it would be possible, but soooo messy.
Yes, I am going straight to the "Approve" page, because I still have a valid SSO session cookie.
Just so I understand, the actual cert renewal is attached to the authentication flow? If that is the case, I agree that logic is a bug. As a workaround, shouldn't I be able to configure the SP to force authentication every time?
Yes, I am going straight to the "Approve" page, because I still have a valid SSO session cookie.
Thanks for confirming.
Just so I understand, the actual cert renewal is attached to the authentication flow? If that is the case, I agree that logic is a bug.
Yes, it's related to the auth flow, but it's by intent, per my understanding. If the user logged in afresh with username/password, it's a new session, so the server will give the app a new cert. If the user logged in using the previous browser session, the server will give the app the same cert from the existing session.
The browser session cookie is meant to be valid for 30 mins, so if you try to renew the session in that time, the browser would open and go straight to the "Approve" page.
We are using a Shibboleth SP for SSO. Is the eduVPN providing an additional cookie to what the IDP provides? As this is a proof of concept that we setup for testing, we set the session expiry to sub 30 minutes, so that would make sense.
As this is a proof of concept that we setup for testing, we set the session expiry to sub 30 minutes, so that would make sense.
Okay, yes, that makes sense.
In practice, there's no need to renew the session in the first 30 mins, so this is not really a problem. We'll consider if we can hide/disable the 'Renew Session' operation in the first 30 mins.
If you'd like to verify that it works correctly in practice, you can increase the session expiry to >1 hour and verify that the 'Renew Session' operation works correctly after 30 mins. (I suggested >1 hour because the notification pop-up is shown 30 mins before session expiry.)
We'll consider if we can hide/disable the 'Renew Session' operation in the first 30 mins.
This is implemented in PR #422.
When I click the "Renew Session" button, during an active session, either in the notification pop-up or in the app window, I go through the "Authorization required" flow, the client connects again, but appears to be using the old certificate. The Valid time left counter inside the app picks up where it left off, and the "Your session is expiring" pop-up notification has a "Session expires at" timestamp of the old certificate.
This is with MacOS 11.5.1 and eduVPN 2.2.2 from the Mac App Store.