Single-signon #64

Open
opened 2024-07-14 00:10:45 +00:00 by lukegb · 2 comments
Member

Are we sticking with Lix's SSO? There are good reasons to - we can leverage their moderation decisions, etc. The obvious downside is that Lix infra team members who are not Distro infra team members can still break into our stuff.

Even if we don't, do we want to stick an intermediate IdP in the middle to give us more flexibility and sovereignty over our group-assignment? This can be another Keycloak (sigh). Then if we later want to disassociate ourselves from Lix SSO it isn't a huge PITA to make sure everything is reconfigured, but it's another thing we'd have to run.

That is:

  • Stick with Lix SSO (y/n)
    • If yes: Stand up an intermediate IdP? (y/n)
Are we sticking with Lix's SSO? There are good reasons to - we can leverage their moderation decisions, etc. The obvious downside is that Lix infra team members who are not Distro infra team members can still break into our stuff. Even if we don't, do we want to stick an intermediate IdP in the middle to give us more flexibility and sovereignty over our group-assignment? This can be another Keycloak (sigh). Then if we later want to disassociate ourselves from Lix SSO it isn't a huge PITA to make sure everything is reconfigured, but it's another thing we'd have to run. That is: * Stick with Lix SSO (y/n) * If yes: Stand up an intermediate IdP? (y/n)
Owner

Are we sticking with Lix's SSO? [...] The obvious downside is that Lix infra team members who are not Distro infra team members can still break into our stuff.

I'm less worried about this than the opposite: Distro infra team members not having the right access level to change stuff on the Lix SSO. If we can get find a solution to this I don't think I care whether we use the Lix SSO or not. How likely is it for example that we'd have to do a change that involves changing Keycloak settings via the Nix config for the service, in Lix's infra repo?

I don't have strong opinions on the rest of the questions because I have 0 experience running anything IdP related and can't really judge how annoying it will be to run our own. I suspect "not too much", in practice? Especially if we can bootstrap from Lix's config.

> Are we sticking with Lix's SSO? [...] The obvious downside is that Lix infra team members who are not Distro infra team members can still break into our stuff. I'm less worried about this than the opposite: Distro infra team members not having the right access level to change stuff on the Lix SSO. If we can get find a solution to this I don't think I care whether we use the Lix SSO or not. How likely is it for example that we'd have to do a change that involves changing Keycloak settings via the Nix config for the service, in Lix's infra repo? I don't have strong opinions on the rest of the questions because I have 0 experience running anything IdP related and can't really judge how annoying it will be to run our own. I suspect "not too much", in practice? Especially if we can bootstrap from Lix's config.
Author
Member

Are we sticking with Lix's SSO? [...] The obvious downside is that Lix infra team members who are not Distro infra team members can still break into our stuff.

I'm less worried about this than the opposite: Distro infra team members not having the right access level to change stuff on the Lix SSO. If we can get find a solution to this I don't think I care whether we use the Lix SSO or not.

Yeah, I think that's fair - that was somewhat what I was alluding to with the "sovereignty over group-assignment", but there's potentially other stuff we'd want to do (like creating new clients, and changing what claims get released and how...)

> > Are we sticking with Lix's SSO? [...] The obvious downside is that Lix infra team members who are not Distro infra team members can still break into our stuff. > > I'm less worried about this than the opposite: Distro infra team members not having the right access level to change stuff on the Lix SSO. If we can get find a solution to this I don't think I care whether we use the Lix SSO or not. Yeah, I think that's fair - that was somewhat what I was alluding to with the "sovereignty over group-assignment", but there's potentially other stuff we'd want to do (like creating new clients, and changing what claims get released and how...)
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: the-distro/infra#64
No description provided.