On accidental user role demotion/promotion with Okta SSO #2372
Conversation
Doc update as a result of troubleshooting https://secure.helpscout.net/conversation/2328484756/55510
|
Preview URL: https://2372--bk-docs-preview.netlify.app |
|
@pzeballos please take a look when you can so we could finish and merge this. Many thanks! |
| @@ -55,3 +55,6 @@ This can be done one of two ways: | |||
| ## SAML user attributes | |||
|
|
|||
| <%= render_markdown partial: 'integrations/sso/saml_user_attributes' %> | |||
|
|
|||
| >🚧 Accidental user role demotion/promotion | |||
There was a problem hiding this comment.
Not sure about the title, I would leave it to @mbelton-buildkite for suggestions. The idea is to explain a reason of why the user is experimenting a demotion of roles.
| @@ -55,3 +55,6 @@ This can be done one of two ways: | |||
| ## SAML user attributes | |||
|
|
|||
| <%= render_markdown partial: 'integrations/sso/saml_user_attributes' %> | |||
|
|
|||
| >🚧 Accidental user role demotion/promotion | |||
| > Note that if SSO via Okta is enabled and configured, Buildkite will receive the information about user roles from Okta and match it. So if you manually user change roles in Buildkite but not in Okta, then every time a user logs into Buildkite via Okta, the role type in Buildkite will be rewritten to match the information provided by Okta. This can cause unintended user role demotion or promotion. | |||
There was a problem hiding this comment.
Yeah, this is the idea of the issue... I leave it to @mbelton-buildkite to check the wording :)
| >🚧 Accidental user role demotion/promotion | ||
| > Note that if SSO via Okta is enabled and configured, Buildkite will receive the information about user roles from Okta and match it. So if you manually user change roles in Buildkite but not in Okta, then every time a user logs into Buildkite via Okta, the role type in Buildkite will be rewritten to match the information provided by Okta. This can cause unintended user role demotion or promotion. |
There was a problem hiding this comment.
I think we can avoid using a warning callout here. Instead, we can add an additional sentence to the intro paragraph of this section:
Buildkite accepts a subset of the SAML attributes from identity providers. Your identity provider is the source of truth for these attributes, so any changes you make directly in Buildkite are overridden during a sync.
And then add a new "Troubleshooting" section focussed more on this issue, if you think it's common:
## Troubleshooting
Resolve common issues with using Okta and Buildkite.
### Unexplained permission changes for users
If you notice a user's permissions changing unexpectedly and have SSO set up with Okta, it's likely because permissions are overridden during a sync. When users log into Buildkite through Okta, Okta sends user attributes and Buildkite updates to match them.
For example, consider the situation where you grant a user admin permission in Buildkite but not Okta. When they next log in, they'll lose the admin permission because Buildkite updates to match the information from Okta (where they don't have admin permission).What do you think?
There was a problem hiding this comment.
I like having this in the Troubleshooting section :)
Doc update as a result of troubleshooting https://secure.helpscout.net/conversation/2328484756/55510