Skip to content
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.

Sign up for GitHub

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

On accidental user role demotion/promotion with Okta SSO #2372

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

On accidental user role demotion/promotion with Okta SSO #2372

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions pages/integrations/sso/okta.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

> 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is the idea of the issue... I leave it to @mbelton-buildkite to check the wording :)

Comment on lines +59 to +60
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like having this in the Troubleshooting section :)