-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix UserContext SSO detection in UI for Okta Users #47944
Conversation
This pull request is automatically being deployed by Amplify Hosting (learn more). |
lib/web/ui/usercontext.go
Outdated
isSSO := user.GetUserType() == types.UserTypeSSO || | ||
len(user.GetOIDCIdentities()) > 0 || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me. just curious if user.GetUserType()
is enough without checking other identities?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It only checks for the CreatedBy.Connector != nil
.
I did that, but some tests started failing so I'm not sure we should be changing that.
On the other hard, maybe user.GetUserType()
should check not only for the CreatedBy.Connector
but also for the OIDC and SAML identities.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ended up moving the check to user.GetUserType
I'm pretty confident we could remove the SAML/OIDC checks but playing on the safe side here.
Okta imported users are not being properly identified as SSO users. Okta does not set any of the Users' identities and instead only sets the User.Connector.CreatedBy field. When building the UserContext, which is used by the WebUI, it was returning `local` user type for Okta users.
5caea60
to
cc605f4
Compare
@marcoandredinis See the table below for backport results.
|
* Fix UserContext SSO detection in UI for Okta Users Okta imported users are not being properly identified as SSO users. Okta does not set any of the Users' identities and instead only sets the User.Connector.CreatedBy field. When building the UserContext, which is used by the WebUI, it was returning `local` user type for Okta users. * move usertype check to types.User
* Fix UserContext SSO detection in UI for Okta Users Okta imported users are not being properly identified as SSO users. Okta does not set any of the Users' identities and instead only sets the User.Connector.CreatedBy field. When building the UserContext, which is used by the WebUI, it was returning `local` user type for Okta users. * move usertype check to types.User
…7959) * Fix UserContext SSO detection in UI for Okta Users (#47944) * Fix UserContext SSO detection in UI for Okta Users Okta imported users are not being properly identified as SSO users. Okta does not set any of the Users' identities and instead only sets the User.Connector.CreatedBy field. When building the UserContext, which is used by the WebUI, it was returning `local` user type for Okta users. * move usertype check to types.User * remove User.Status field which only exists on 15+
Okta imported users are not being properly identified as SSO users. Okta does not set any of the Users' identities and instead only sets the User.Connector.CreatedBy field.
When building the UserContext, which is used by the WebUI, it was returning
local
user type for Okta users.As an example of what this fixes in the UI: when setting traits during the Discover flows, User is now correctly asked to change the Teleport Role instead of being allowed to enter principals but then getting an error.
Before
After
Fixes #47901
changelog: During the Set Up Access of the Enroll New Resource flows, Okta users will be asked to change the role instead of entering the principals and getting an error afterwards.