oidc-frontend: email claim not part of userinfo

[ctr49]

Code Version

7.0.1

Expected Behavior

email claim being part of userinfo

Current Behavior

email claim not part of userinfo

Possible Solution

Steps to Reproduce

1. Setup oidc-to-saml proxy as per instructions
2. Get access token, fetch userinfo

For some reason the email claim (also being defined in the standard profile) is not returned by the userinfo endpoint. I already enabled some additional debugging (see #342 ) and can observe the 'mail' attribute coming from SAML [satosa.attribute_mapping]: backend attribute ['mail'] mapped to mail (['[email protected]']) and also this being mapped to the fronted: [satosa.attribute_mapping]: frontend attribute email mapped from mail (['[email protected]']) but email ist not part of the returned object when fetching userinfo.

The (oidc frontend) provider is configured to support openid, profile, email

[Torrien]

I am having this same issue. Do I need to configure some type of permission for the client to have the email and name delivered?

[vladimir-mencl-eresearch]

Hi, what scopes do you request in the OIDC request? The openid and profile scopes do not include the email claim, you have to explicitly request also the email scope to get the email claim.

Hope this helps.

Cheers, Vlad

[Torrien]

@vladimir-mencl-eresearch Thanks for the update. And yes, I got to this solution earlier in the week.

I had to add extra_id_token_claims for this to work. The email was already being mapped to internal attributes but not being delivered to the client. By adding email as an extra_id_token_claim for the specific client_id the attribute was delivered.

I did find it a bit out of place a client_id configuration configured at the frontend configuration file. Is there a more sensible place to do this?

[vladimir-mencl-eresearch]

Hi @Torrien , In my deployment, I configure clients in a cdb.json file which is referred to by name in the frontend config file (as client_db_path).

As for passing the email, you should be able to access it via the email scope without having to configure extra_id_token_claims (which should however work as well). I've just checked and in oic/message.py, the email scope is mapped to the email and email_verified claims. (However, it expects exactly these claim names, so it would not work if your mail attribute has an openid name different from email in internal_attributes.yaml.

Hope this helps.

Cheers, Vlad