0
votes

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.

3

3 Answers

1
votes

This document should be what you want.

You should add the app role into the manifest of Azure AD app which represents your Web API (here should be the service app TodoListService) by following the first example.

"appId": "8763f1c4-f988-489c-a51e-158e9ef97d6a",
"appRoles": [
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "Writer",
      "id": "d1c2ade8-98f8-45fd-aa4a-6d06b947c66f",
      "isEnabled": true,
      "description": "Writers Have the ability to create tasks.",
      "value": "Writer"
    }
  ],
"availableToOtherTenants": false,

Then you need to assign users to this app role.

After the user sign in, you will get the app role in the token and you can verify it easily.

HttpContext.ValidateAppRole("Writer");

This app role is specific to your Web API application. When the user sign into other applications, app role Writer won't be available.

1
votes

After discussing with Microsoft Azure AD support, I conclude that this is not possible.


The below are the alternative approaches I have recognised. Happy to hear about others that would be possible:

Following this article from Microsoft we can add roles with custom information, by using:

  • Azure AD App Roles
  • Azure AD Security Groups
  • Or adding an Identity within the application, and then implementing RoleManager class. This means the application database would hold an identity, somewhat defeating the purpose of Azure AD.

Other information can also be added to Microsoft Graph as described in this blog post by rasmustherkelsen. However I don't think this appropriate for any security related items (such as permissions, or paid-for module licenses) as Microsoft explains in this article that:

extension properties are accessible by any consented application in an organization, not just for the application to which they are registered.

And so other applications could read and write to this properties if the tenant provides consent to this.

Edit: The Graph API has the ability to update the Application Roles. This can be called by the application to securely update the Application Roles.

My research leads me to conclude that Azure AD cannot realistically be used by a multi tenant SaaS solution, as the sole identity provider. The application needs to provide some identity to manage additional claims, such as detailed application permissions and paid-for module access.

0
votes

Don't have rep for comment but I am running into the same issue while trying to move authentication to MSAL. If you run across the answer to using Role Manager please let me know.