Add skeleton of IDP interface for resolving friendly names

[evankanderson]

See discussion in #2326. The goal here is to enable the following:

1. Preserve existing relations in OpenFGA and avoid needing a migration.
2. Support minder project role grant -r viewer -u JAORMX (which should look up the "JAORMX" preferred_username in Keycloak (populated from GitHub), and then store the (stable) Keycloak ID in the OpenFGA grant. We don't want to store JAORMX, because he might change his account name later.
3. Support listing JAORMX as the username coming back from ListRoleAssignments, so that we can read the output. We can also include the Keycloak userids in the RPC response, but no one will read them. 😁
4. Add an IdentityProvider for KeyCloak + GitHub that will call getUsers with a filter and/or create a user and set their GitHub federated identity information
   • This will allow us to resolve users to KeyCloak identities when the role grant is made, rather than at a possible later date when GitHub identities have shifted.
5. In the future, add an actions IdentityProvider for GitHub actions which would be distinct from KeyCloak + GitHub users in 2
   • The syntax for this would be something like minder project role grant -r editor -u actions/repo:stacklok/minder-rules-and-profiles:ref:refs/heads/main. (Yeah, action names are pretty awesome...)

To fit the interface into existing code, we'll need to replace:

• ParseAndValidate (4 calls, handlers_token.go and 3x handlers_user.go)
• Calls around authzClient (default_project.go, handlers_authz.go, handlers_user.go) which will need to use the canonical Identity.String() for Write, Check, and ProjectsForUser, and Identity.Human() for AssignmentsToProject.

[JAORMX]

This abstraction makes sense to me. Is the idea also to abstract the OIDC token validation into the implementations here?

[JAORMX]

Do we want to add email to this? For some IdPs we wouldn't quite have a preferred user name and the email would be more relevant.

[evankanderson]

I think email is the preferred username (HumanName) for some providers. For others (e.g. GitHub Actions) users may not have email addresses.

[JAORMX]

Makes sense, I think that's fine

[JAORMX]

is IdentityProvider assumed to be OIDC-compatible? if so, let's mark that in the docs.

[evankanderson]

I'm not sure that we want to require it. I imagined this as being decoupled from specific identity provider implementations, so we'd still need something like OIDC (or x.509 client certs) to assert the user's identity. Once we have their identity, we can then go through this interface to map it to/from database representation.

[evankanderson]

Looking at zitadel.RelyingParty, that interface looks a lot bigger (and more OIDC-specific) than what I was looking for here, but I could be convinced to expand to include that if we find it generally useful; it looks like it covers a lot more OIDC functionality. (The URL method is admittedly a bit OIDC-specific at the moment.)

[evankanderson]

I got some email comments from Ria that didn't show up here, adding them and then I'm going to polish this a little tonight and finish tomorrow.

[evankanderson]

Looking at zitadel.RelyingParty, that interface looks a lot bigger (and more OIDC-specific) than what I was looking for here, but I could be convinced to expand to include that if we find it generally useful; it looks like it covers a lot more OIDC functionality. (The URL method is admittedly a bit OIDC-specific at the moment.)

[github-actions]

This PR needs additional information before we can continue. It is now marked as stale because it has been open for 30 days with no activity. Please provide the necessary details to continue or it will be closed in 30 days.

[github-actions]

This PR needs additional information before we can continue. It is now marked as stale because it has been open for 30 days with no activity. Please provide the necessary details to continue or it will be closed in 30 days.

[evankanderson]

We did this in #3155