Open corban-beaird opened 1 week ago
Attention: Patch coverage is 33.33333%
with 74 lines
in your changes missing coverage. Please review.
Project coverage is 52.89%. Comparing base (
547a4c4
) to head (8dba3ec
). Report is 11 commits behind head on main.
Name | Link |
---|---|
Latest commit | 8dba3ec8d0832e6b912dcf683d8694c0ee9f5b3a |
Latest deploy log | https://app.netlify.com/sites/determined-ui/deploys/66904c78e6a408000804fe62 |
Deploy Preview | https://deploy-preview-9613--determined-ui.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
If the user doesn't have an expired session token will they see the login page still? If so, could a user create a fake session token to ensure they don't see the login page at all?
If the user doesn't have an expired session token will they see the login page still? If so, could a user create a fake session token to ensure they don't see the login page at all?
@BOsterbuhr If the they don't have an expired token, they'll be sent directly in to the app, since they're already authenticated. Also if a user provides a fake session token that isn't within our system, we won't report it as an expired token & they'll be directed to the login page to authenticate
If the user doesn't have an expired session token will they see the login page still? If so, could a user create a fake session token to ensure they don't see the login page at all?
@BOsterbuhr
If the they don't have an expired token, they'll be sent directly in to the app, since they're already authenticated. Also if a user provides a fake session token that isn't within our system, we won't report it as an expired token & they'll be directed to the login page to authenticate
If they don't have a token at all (first time logging in) how can they avoid hitting the login page? We need a way to avoid the login page completely in all instances.
If they don't have a token at all (first time logging in) how can they avoid hitting the login page? We need a way to avoid the login page completely in all instances.
@BOsterbuhr Currently that's not what's being done in this PR. However, I'm happy to add in a new config to the master to allow for auto-redirect to the SSO provider by default for every user regardless of if they have a token.
Currently that's not what's being done in this PR. However, I'm happy to add in a new config to the master to allow for auto-redirect to the SSO provider by default for every user regardless of if they have a token.
@corban-beaird That would be perfect, thank you 🙏🏼
@corban-beaird 👋🏻
Currently that's not what's being done in this PR. However, I'm happy to add in a new config to the master to allow for auto-redirect to the SSO provider by default for every user regardless of if they have a token.
Is this being worked into the PR? This is critical. Also, sorry if I missed the explanation: if the user has an Okta token that hasn't yet been "seen" by MLDE, will the user be re-directed to the requested page?
Is this being worked into the PR? This is critical. Also, sorry if I missed the explanation: if the user has an Okta token that hasn't yet been "seen" by MLDE, will the user be re-directed to the requested page?
@dougdet Yep, I pushing up a PR to add in the ability to always redirect to the designated SSO provider; with the exception of cases where users perform a hard logout (i.e. clicking the logout button).
@dougdet Yep, I pushing up a PR to add in the ability to always redirect to the designated SSO provider; with the exception of cases where users perform a hard logout (i.e. clicking the logout button).
Great!
"i.e. clicking the logout button". Is there no way around this? The user may logout that way and may still be auth'd in Okta (have its token). If no way around, we'll just have to make this very clear to the customer that if a user does this they'll bump into the Login page. I'll bet they'll ask to hide the Logout button if the master.yaml
is set to "always redirect".
"i.e. clicking the logout button". Is there no way around this? The user may logout that way and may still be auth'd in Okta (have its token). If no way around, we'll just have to make this very clear to the customer that if a user does this they'll bump into the Login page. I'll bet they'll ask to hide the Logout button if the
master.yaml
is set to "always redirect".
@dougdet If we aren't sending folks to the the determined login page & they still have an active session with Okta that we don't manage, they'll immediately get logged back into determined after hitting sign out. Is there ever a case where a user would ever want to log in under a different account?
@dougdet If we aren't sending folks to the the determined login page & they still have an active session with Okta that we don't manage, they'll immediately get logged back into determined after hitting sign out. Is there ever a case where a user would ever want to log in under a different account? @corban-beaird I think you have it covered. Not sure a "regular" user would ever be logging in under a different account.
with always_redirect: true
, it always go to OIDC/SAML
page instead of det login page, is it expected? otherwise lgtm
https://github.com/user-attachments/assets/03d8e27e-5679-4d66-a58f-5865c695e2ab
with
always_redirect: true
, it always go toOIDC/SAML
page instead of det login page, is it expected? otherwise lgtmScreen.Recording.2024-07-12.at.2.50.03.PM.mov
Yep that's the expected behavior!
Ticket
DET-10392
Description
Detect when an SSO user is attempting to leverage an expired session token, and rather than redirect them to the SignIn page, instead directly call the SSO provider & send them back to the requested page.
Docs
Test Plan
Setup:
Launch a devcluster that is configured to with at least on SSO provider
always_redirect: true
in the OIDC/SAML config to test the alwaysRedirect behavior.SSO User Token Expiration
UPDATE user_sessions SET expiry = current_timestamp WHERE user_id = <your user id>;
Non-SSO User Token Expiration
UPDATE user_sessions SET expiry = current_timestamp WHERE user_id = <your user id>;
Always Redirect Enabled
/det/tasks
/det/workspaces/<workspace_id>/projects
/det/projects/<project_id>/experiments
Checklist
docs/release-notes/
See Release Note for details.