Fix fetching claims from the UserInfo endpoint

[leppa]

I think that I finally found a solution for #1894.

For claims to be extraced from the UserInfo response, they must have corresponding ClaimAction defined. According to the documentation:

The ASP.NET Core client app uses the GetClaimsFromUserInfoEndpoint property to configure this. One important difference from the first settings, is that you must specify the claims you require using the MapUniqueJsonKey method, otherwise only the name, given_name and email standard claims will be available in the client app. The claims included in the id_token are mapped per default.

Any claims that were present only in the UserInfo response (which was the case with preferred_username and groups) and didn't have a corresponding ClaimAction were ignored. This also explains why, after creating a user and disabling the workaround, I was still able to login - name was still present and used for matching a user.

PS: Last time I touched .NET was in university, so I have no idea about the conventions and best practices. Feel free to refactor the code, if needed 😄

[ShreyasZare]

Thanks for the PR. I finally got authelia installed and the PR is working. Will see how this can be generalized and ensure that this does not break other SSO providers.

[leppa]

As far as I understand, this behavior is generic and not Authelia specific. As long as OIDC provider returns claims of interest only in the UserInfo, you must set ClaimActions for them to be extracted. I already tried to do it in a generic way:

• OnUserInformationReceived should only trigger when GetClaimsFromUserInfoEndpoint is true (this is assumed).
• ClaimActions are only added when they're not already present and only when corresponding claims are present in the UserInfo.

Which means that if OIDC provider returns everything that we need in the ID Token, GetClaimsFromUserInfoEndpoint is never enabled, the OnUserInformationReceived is never triggered, and the logic will behave exactly the same as before this change.

The only thing that might need tweaking is the list of claims that are tested in the UserInfo. I.e., the SsoLoginFinalizeAsync() also tries upn, nickname and some ClaimTypes.*, so if some OIDC provider returns those, they will still be "lost".