OIDC claim_mappings will not override 'name' nor store it in metadata

So I have setup authentication using OpenID Connect client (namely Gitlab) but I can’t make newly created Entity Alias to have email of the user as a name.

I have defined claim_mappings as map[email:name] but this doesn’t change entity’s name to the user email, instead it uses user’s ID (from gitlab). It also doesn’t store this email in Entity’s metadata.

What I also noticed is that if I set mapping to something bogus, such as map[xyz:name] it’ll still allow the user to sign up, which shouldn’t happen as per the documentation

If a claim is configured in claim_mappings, it must existing in the JWT or else the authentication will fail. (it mentions JWT, but it’s from JWT/OIDC documentation)

in this case key xyz certainly doesn’t exist, so the login should fail?

did you get anywhere with this ? I have the same issue. I’d also like to know what data from the oidc token I can stuff into the entity alias / metadata

Hi @jmls

Yep. So gitlab OIDC token doesn’t return anything but sub and_legacy in the token itself, and I quote

Only the sub and sub_legacy claims are included in the ID token, all other claims are available from the /oauth/userinfo endpoint used by OIDC clients.

(reference: https://docs.gitlab.com/ee/integration/openid_connect_provider.html)

Thus you can’t retrieve any additional information such as email or name from this token without calling this endpoint, which vault won’t do for you. Also vault will silently ignore that the key you requested is missing. Why? No idea

The solution which I used was a middleman between vault and gitlab. I know, cumbersome, but what can you do when gitlab doesn’t return the information you need in the token (yet, it’s still OIDC-compliant as all other fields but sub are optional) and Vault doesn’t allow you to query any resource to get more data.

You can either go with Auth0, but they pissed me off quite quickly so I went with self-hosted, really easy to setup and use https://github.com/dexidp/dex

With the middleman you can authorise yourself with gitlab using oauth2 and let the middleman include whatever you need in the OIDC token. Dex has some limitations there but I didn’t need more than it offers by default. Still, it’s open source so you can always add some logic here and there.

good luck