search

Azure-Samples / ms-identity-aspnet-daemon-webapp

A web application that sync's data from the Microsoft Graph using the identity of the application, instead of on behalf of a user.
MIT License
131 stars 52 forks source link

How to protect web api accessible from multiple daemon apps? #48

Closed V4A001 closed 8 months ago

V4A001 commented 3 years ago

This example is that the SAAS application needs app permissions to multiple tenants. But how to implement the opposite?

  1. Have the multiple tenants register their own app registration and validate that on the web api?
  2. Register multiple client certificates/ secrets on 1 app registration on the SAAS app?
  3. Register multiple app registration with their own client certificate/ secret, however the web api does need to understand multiple client id's.
  4. Use own key+secret pair, not using tokens (I guess most of the time implemented as it is quite straight forward, but maybe less secure).

I guess only scenario 2 or 4 is possible. It will give 5000 client secrets for 5000 daemon apps. Is there a limit on the number of secrets?

V4A001 commented 3 years ago

Friendly bump.

jmprieur commented 3 years ago

@V4A001 : would you have an architectural diagram of what you are trying to do? I don't understand your request

  1. are these app registration for daemon apps? each in its tenant? where is the web API? would it be a multi-tenant one?

  2. The web API can look at the claims in the token and know which app called, and I guess could control that the client ID is in a pre-provided list (maybe in a database) ?

What about having a multi-tenant daemon app instead?

V4A001 commented 3 years ago

I tried to illustrate the process of scenario 3 with 1 customer.

The idea is to have multiple customers for which users can sign-in to the SAAS. That is doable. However, for every customer also a daemon app should be able to sent to the SAAS web api, and receive data in its own service bus. So the SAAS can access a service bus per customer. But that is less relevant.

The customer 1 administrator signs in the SAAS and creates there (through code) a new clientid and clientsecret which are linked to his tenant. The clientid and client secret he/ she updates in the app which runs locally (d365 app). The d365 app is deamon 1 and is now able to connect to the multi tenant web api. The web api must be able to receive secure web api calls from multiple tenants. The SAAS needs to know who is who. As the SAAS tenant azure ad is used to automatically create clientid and clientsecret the clientid can be used to identify a customer uniquely.

However, the web api with the standard libraries do not understand multiple clientid's. So scenario 2 is about 1 client id with a new secret key per customer. Then the Saas cannot uniquely identify the customer as they all have the same client id. Managing all those client secrets is also a thing.

Another option would be scenario 1 in which an own web application registration is done, the SAAS webapi must then lookup if the tenant id/ clientid is known and provide access yes/no. In this case no secret keys are to be exchanged and only the tenantid must be validated...and must not be spoofable.

The same challenge also holds for the opposite way, in case the SAAS want to sent a message to the service bus of the customer. That key is fixed and not a token which is less secure. Maybe an clientid/ clientsecret is a securer option there, but the overhead of accessing the service bus is a disadvantage.

Saas Multi Daemon subscription

V4A001 commented 3 years ago

What about having a multi-tenant daemon app instead?

Its the opposite of a multi-tenant deamon app.

V4A001 commented 3 years ago

friendly bump

jmprieur commented 3 years ago

This is a multi-tenant web API. Provided each daemon client app uses the app role accepted by the multi-tenant web API this would work. See