adding external claims after AzureAd Authentication

[fidou]

I have an application and I am doing authentication against Azure AD (by using the AddAzureAD extension)
I want to do the authorization, but this will be managed locally on the application self.
In the database, based on the username will be assigned some roles.
What I would like to have being able to add the information from the database as claims once the user is authenticated so dat I can use the standard authorization mechanism and alsi be able to call User.IsInRole().
the only way I found at the moment is indicated in this blog: https://joonasw.net/view/adding-custom-claims-aspnet-core-2 but it does not seem satisfying because using a service locator.
is there a way I can easily achieve this that also supports dependency injection?
thanks in advance for your help guys (and gals)

[SteveSandersonMS]

Could you clarify what you don't like about https://joonasw.net/view/adding-custom-claims-aspnet-core-2? When you say "service locator", are you referring to its use of ctx.HttpContext.RequestServices? If so, that is using the dependency injection system so I'm not clear on how it would be disadvantageous.

@javiercn Do you have any concerns about the approach mentioned in https://joonasw.net/view/adding-custom-claims-aspnet-core-2, or suggestions for a better way?

[fidou]

Hi thanks for taking the time to react to my discussion.
The service locator (ctx.HttpContext.RequestServices) is an anti-pattern in the sense that it hides a class dependencies. Writing unit tests is a headache already without having to dig into the details of each implementation to know which dependency is hidden inside.

What I would prefer is having a default implementation of a class where the claims gets constructed and be able to override.
Let's take the OpenIdConnectHandler. Through out the multiple functions o the class a couple of events are called.
How about having a

public class OpenIdConnectEventsHandlerDefault: IOpenIdConnectEventsHandlerDefault
{
	public OpenIdConnectEventsHandlerDefault(whatever it needs)
	
	// default implements of the events that will be called from the OpenIdConnectHandler class. the methods are virtual can can be overridden.
	// The name is probably not right since it infers an event.
	public vurtual async Task OnTokenValidated(TokenValidatedContext context) => Task.CompletedTask;
}

In my case wanting to add claims to the user means inheriting from OpenIdConnectEventsHandlerDefault and overriding the correct event ( + of course registering the class in the servicecollection)
This is a suggestion, and to be honest I have no idea if it makes sens or if it is feasible considering the breaking changes it introduces. so I am open to options and might even contribute.

N.B: The usage of events and service locator is quiet prevalent also in the identity package and the OAuth and I am guessing Cookies. For the sake of harmony whatever is decided must be standard to all of them.

[javiercn]

I believe you can replace the entire EventsType property with your own type on the options class and you can use DI on that class to inject any dependency you have. See https://github.com/dotnet/aspnetcore/blob/master/src/Security/Authentication/Core/src/AuthenticationSchemeOptions.cs#L39

[fidou]

Thanks for you answer. Spot on, obviously that's what I need.
For the sake of upgrade, will this also work with the microsoft.identity.web?

[javiercn]

I think it would, but You'll have to ask the Identity.Web folks on their repo

[fidou]

I will. from my side I think my question have been answered. I think this discussion can be closed