Semaphore OpenID Connect authentication - Role mapping and project assignment

[Guear]

Hello team,

First of all, thank you @s3lph for your amazing work on OpenID Connect authentication module with Semaphore.

I was able to correctly configure OpenID Connect on my Semaphore instance with Authentik IdP. The authentication process is working fine but the fresh new user has no authorization (no user role and no project assigned) on his account.

I know that user role and project assigment to this account can be done later by another admin account. Is the possibility to have authorization (user role and project assigment) process through group mappping or custom attributes could be implemented (or in roadmap) ?

Thank you

[SamB-GB]

I am just chiming to ask if this has been considered at all?

[pasettifabio]

Hi everybody, I'm trying to do the same thing: pass the role or the group attribute to the user during the first login with OIDC (keycloak) but it seems to be impossible, am I wrong?

[hagaram]

@pasettifabio wondering the same

[depau]

Hi, I was looking into this functionality since we would like to adopt Semaphore at my company and we would really like to have this feature.

We are willing to implement this ourselves, so I wanted to ask if you're willing to accept contributions before we start working on it.

Looking at the source code I was thinking it could be implemented like this:

• Add an ExternallyManaged field to the ProjectUser relationship table to track whether this relationship has been created manually by an admin or automatically by the IdP mapping logic
• Add a config option that allows admins to select a JWT claim and find a project based on a regex, like this:

"oidc_auto_membership": [
  {
    "claim": "groups",                   // claim, JMESPath or similar JSON query
    "match": "^(?<proj>[\\w-]+)-admin$", // regex with named capture groups
    "project_key": "${proj}",            // named capture groups are expanded here
    "role": "admin"                      // maybe even here, although it's not necessary
  },
  {
    "claim": "groups",
    "match": "^(?<proj>[\\w-]+)$",
    "project_key": "${proj}",
    "role": "member"
  }
]

• Finally, add some code to oidcRedirect that adds new memberships with the specified roles based on OIDC claims, removing any ExternallyManaged ones that are missing in the claims.

@fiftin, does this sound reasonable to you? Let me know what you think :)