We are building a ASP.net core Web API with Angular SPA client. For Authentication we have implemented Azure AD with multi tenants. For the Web API authentication/authorization we have followed this Microsoft sample. This uses the Microsoft.Identity.Web
MSAL library for authenticating the authorisation code that originated from the Angular SPA. On the Azure AD application registration we manage the correct scope of the application, but we are not able to understand how claims are managed.
In previous applications I had run the authentication server IdentityServer4
as middleware in my application, allowing the authentication and issuing of claims in my application. I was using UserManager
to add or remove claims on the User. Claims information was stored in the User tables of my database, and were then included in the issued cookie and available to the SPA and the Web API.
In the current application we are fully relying on Azure AD, and now I feel I am missing a piece of the puzzle to manage the user claims (and their inclusion on the cookie/token). Question: How can I manage claims that are specific to our application while user management and authentication takes place on Azure AD rather than in my application?
To clarify: This Microsoft document mentions three ways of using application roles: Azure AD App roles, Azure AD Security Groups and Application Role manager. It's the last one I feel is the correct functionality I need:
With this approach, application roles are not stored in Azure AD at all. Instead, the application stores the role assignments for each user in its own DB — for example, using the RoleManager class in ASP.NET Identity.
A small selection of the documentation I have reviewed but didn't give me the answers:
This previously linked Microsoft document does mention using the RoleManager class in ASP.NET Identity, but does not explain how to implement this as integration with Azure AD such that the cookies/tokens include the roles (or roles converted to claims).
I have read about using MS Graph schema extensions and including these in claims however, the article also states that any application with consent can read and write these extended properties. Implying this is not a secure way to provide any claim to the application as the values could be touched from outside the application
Documentation explaining how to verify user claims.
Tailspin scenario, mentions using roles on the application rather than security groups. But there is no indication or hint how this is included as claims in Azure AD. And following this it's clear that it's not controlled in the application.
This document and this explains about transforming claims or adding custom claims, but this is basis conditions on the user account rather than the application setting the claims. These conditions would also need to be managed on the domain rather than in the application.
Similar question? But no answer.