Single-signon #64

New issue

Closed

opened 2024-07-14 00:10:45 +00:00 by lukegb · 4 comments

lukegb commented

2024-07-14 00:10:45 +00:00

(Migrated from git.lix.systems)

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)

delroth commented

2024-07-14 00:32:22 +00:00

(Migrated from git.lix.systems)

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.

lukegb commented

2024-07-14 01:06:54 +00:00

(Migrated from git.lix.systems)

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...)

k900 commented

2025-04-05 09:41:29 +00:00

(Migrated from git.lix.systems)

The current setup works for now, we can revisit if it ever becomes an issue.

raito commented

2025-08-24 00:36:19 +00:00

(Migrated from git.lix.systems)

AFNix SSO exist: https://id.afnix.fr.

As for Floral: The Floral project will not be tracked anymore here and is not the priority of AFNix for the immediate future.

AFNix SSO exist: https://id.afnix.fr. As for Floral: The Floral project will not be tracked anymore here and is not the priority of AFNix for the immediate future.

No milestone

No project

No assignees

1 participant

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: afnix/infra#64

No description provided.

Rows
Columns