Hey, if I add SSO to my Pulumi org, will existing ...
# general
l
Hey, if I add SSO to my Pulumi org, will existing users that signed up via linked GitHub account be able to login? (I do not care about any user/permission mapping, just want to be able for new users to use SSO and existing users GitHub to log in).
b
hi @lively-answer-93856 we dont support organizations with multiple identities. if ya could reach out to us via support, folks can help ya figure out a way to move over to sso without disruption. https://support.pulumi.com/hc/en-us
l
Hey @brainy-church-78120 thank you for your response. Does it mean that pulumi access tokens generated before enabling SSO will also stop working?
b
access tokens are tied to users not organizations. so if that user still has access then it shouldn't stop working.
l
To be more specific - I have CI/CD GitHub user that was added to pulumi org. Now we would like to enable SSO for the org. I need to know if that CI/CD user will still be able to authenticate into Pulumi via existing access token. CI/CD user will not have to login via UI (for a while, it will get replaced by another user from SSO later on).
c
Hey Pawel, I'm an engineer on the Pulumi team and these are good questions! Let me explain what to expect in this situation... But the TL;DR is that yes, things will work for now.
@lively-answer-93856
I have CI/CD GitHub user that was added to pulumi org. Now we would like to enable SSO for the org.
Enabling SSO for the organization changes the so-called “membership requirements” for all organization members. In order for a Pulumi user to have access to an organization’s resources, we perform two checks: 1. Is the Pulumi user account a member of the organization? 2. Does the Pulumi user meet the organization’s membership requirements? So for this CI/CD robot account, the answer is yes. You added them to your Pulumi organization. And I presume the robot account is also a member of the GitHub organization that is the “membership requirement” for your Pulumi org. So far so good. But when you switch the Pulumi organization to using SAML SSO, your existing organization members will lose access! When you change the organization’s membership requirements to using SAML SSO, then every existing organization member (*) will no longer have access to the Pulumi organization. Because they haven’t established a connection between the SAML SSO identity provider and their Pulumi account. So, just like if we couldn’t confirm a user was a member of the backing GitHub organization, we cannot confirm they have a valid SAML SSO login, and block their access. (*) An exception is made for the person who sets up and configures SAML SSO. So that they have access to the organization to configure SAML SSO and/or change settings if the SAML configuration is broken in some way. To regain their access, organization members need to log into Pulumi using their existing GitHub identities (like today). And then on the Profile page, click “Connect SSO”. That will lead them through the SAML SSO login flow, and connect the new SAML identity to their existing Pulumi account. ## Sounds bad? Can I switch to SAML SSO from GitHub without disruption? Yes, you can. There unfortunately isn’t a smooth way to do this in the Pulumi Service yet. But if you file a support ticket, we can work together so that you can switch to using SAML SSO without any of your existing organization members losing access.
I need to know if that CI/CD user will still be able to authenticate into Pulumi via existing access token. CI/CD user will not have to login via UI (for a while, it will get replaced by another user from SSO later on).
Like any other Pulumi user account, they won’t be able to access the Pulumi organization until they’ve “connected their SAML identity”. (i.e. meeting the organization’s membership requirements.) However, just like before, if you file a support ticket we can work with you to flip a few bits so that we exempt that CI/CD-only user from the regular SAML SSO checks. And once we’ve done that, the existing Pulumi access tokens for that user will still work as-is, even for the SAML-backed organization. This is definitely a known problem of sorts, and you aren’t the first person to need help to get this scenario working. (Sorry about that.) But the good news is that we are actively working on some security improvements that will help smooth out the experience here. So hopefully soon you can manage things like “CI/CD access tokens” for an organization without needing to create pseudo-user accounts. If you have any other questions please let me know!
l
Hey Chris, thanks a lot for your reply. Without checking slack I emailed you while ago. Feel free to copy/paste ^ as a response so other people in a chain will get that as well and move that conversation there. Many thanks!