Hallo zusammen,

gibt es eine Möglichkeit einen AuthenticationHandler zur Laufzeit hinzuzufügen?

Ich habe eine SaaS-App mit mehreren Mandanten.
Will sich nun ein Mandant auch gegen sein eigenes AzureAD authentifizieren, erstellt dieser in Azure eine AppRegistration und übermittelt uns ClientId/TenantId etc. Der entsprechende Eintrag von mir in der appSettings.json hinzufügt, welcher dann beim Startup in den ConfigureServices aufgerufen wird: services.AddAuthentication().AddMicrosoftIdentityWebApp("add1".…

Soweit funktioniert das alles, allerdings möchte ich nun, dass meine Mandaten ClientId/TenantId etc. in einem Adminbereich selbst eintragen können und dann irgendwie services.AddAuthentication().AddMicrosoftIdentityWebApp() zur Laufzeit aufrufen wird, damit nicht immer die komplette WebApp neu starten muss. Nach Stunden des Suchens und probieren konnte ich keine Lösung finden.

Dein Vorgehen ist im Sinne von Multi Tenancy und Azure AD konzeptionell falsch, daher findest auch nichts: denn Deine Multi Tenancy App muss als solche in Azure aufgesetzt werden, als Enterprise App.
Diese Enterprise App kann dann der Kunde in seinem AAD aktivieren; er muss das nicht von Hand irgendwie erzeugen und euch irgendwelche Settings geben.
Multitenancy and identity management - Azure Architecture Center
So funktioniert OpenID und OAuth ;-)

Deine App selbst muss dann auch Tenant-fähig umgesetzt werden.
Dazu wird die Audience Deiner Applikation beibehalten, aber der Tenant in der Registrierung ändert sich auf common.

   "AzureAd": {
        "Instance": "https://login.microsoftonline.com/",
        "ClientId": "DeineIdHere",
        "TenantId": "common", <<<<----
        "Audience": "DeineAudienceHere"
    },

Es ist in ASP.NET Core bzw. der gesamten Middleware und Auth-Pipeline nicht vorgesehen, dass sich diese Daten zur Laufzeit ändern.
Weil: es eine schlechte Idee ist, die im Konzept schon falsch ist.

Einzig die Validatoren können durch Delegates dynamisch umgesetzt werden, was konzeptionell so auch gedacht ist.
Configure protected web API apps - Microsoft identity platform

PS: Dein Szenario ist geläufig; baue ich auch oft so. Meine aktuelle Tätigkeit ist genau der Aufbau einer solchen Multi Tenant Admin Portal Geschichte inkl. Kundenzugriff etc.
Wir haben dazu die User, eigene Rollen, eigene Permission Mechanismen in einer eigenen Datenbank.
Das funktioniert mit dem Azure AD Multi Tenant Konzept sehr gut; muss man nix eigenes erfinden.

Authentication Provider zur Laufzeit zu ändern ist durchaus Möglich (wertfrei), es gibt da eine passende Implementierung:
https://github.com/Aguafrommars/DynamicAuthProviders

Meines Wissens ist diese entstanden um IdentityServer 4 zur Laufzeit weitere Federations zu ermöglichen.

@Abt
Vielen Dank für den Input, ich werde mir das im Detail ansehen.
Unsere Marktbegleiter lassen laut Doku ihre Mandaten in Azure immer eine eigene AppRegistration mit eigener AppId anlegen, daher bin ich überhaupt auf diese Vorgehensweise gekommen.

@Papst
Danke für den Link, sieht auch interessant aus.

Zitat von Savage

Unsere Marktbegleiter lassen laut Doku ihre Mandaten in Azure immer eine eigene AppRegistration mit eigener AppId anlegen, daher bin ich überhaupt auf diese Vorgehensweise gekommen.

Das umgeht halt das vollständige Prinzip von Multi Tenancy auf Azure bzw. mit Azure AD.

Auch wenn das konzeptionell geht (in dem man viel in ASP umbaut), hat das System dann zwangsläufig Lücken, weil:
- Managed Identity dann nicht mehr funktioniert (weil die Identity dann Teil eines anderen AADs ist); Du kannst also keine Services Passwordless umsetzen, was aber die absolute Empfehlung bzgl. Sicherheit auf Azure ist
- On Behalf Flows funktionieren nicht (außer der Kunde würde noch ein Secret weiter geben, was ein absolutes Sicherheits-Nogo wäre)

Btw., hier ist mir noch ein aufschlussreiches Video untergekommen: https://www.youtube.com/watch?v=B416AxHoMJ4

Ich denke, ich habe es soweit mal verstanden. Ich habe eine EnterpriseApp angelegt und habe diese bei anderen ADs provisioniert. Ohne etwas an der Core-App-Config zu ändern kann man sich nun aus verschiedenen ADs einloggen und im Event OnTokenValidated kann ich auch die tenantid des jeweiligen ADs auslesen.

Allerdings klemmt sich noch ein Punkt in meinem Kopf, nämlich die Redirect-URIs.
Wenn der User zum AD-Login umgeleitet wird, muss man ja den redirect_uri Paramater mitübergeben, welche bei der AppRegistration definiert werden müssen. Tut man das nicht bekommt man ja 'The redirect URI xxx specified in the request does not match the redirect URIs configured for the application'
Bei unserer bestehenden Asp.NET-App hat aber jeder Mandant eine eigene Domain, welche ich unmöglich alle eintragen kann.
Wie bekomme ich das zusammen? Oder habe ich schon wieder einen Gedanken-/Konzeptfehler?

Zitat von Savage

Bei unserer bestehenden Asp.NET-App hat aber jeder Mandant eine eigene Domain, welche ich unmöglich alle eintragen kann. Wie bekomme ich das zusammen? Oder habe ich schon wieder einen Gedanken-/Konzeptfehler?

Der OpenId-Standard erfordert bei der Validierung, dass die Redirect URL dem Authentifizierungsprovider (hier Azure AD) bekannt ist. Das ist einfach ein Sicherheitsaspekt, der im Rahmen der OWASP Kriterien festgelegt ist, um eine redirect attack ("open redirect vulnerability") zu vermeiden.
Der Eintrag ist also absolut erforderlich und kannst Du via Microsoft Graph über die API auch automatisieren.

Evtl wäre es ein Woraround, wenn Du immer an die gleiche URL redirectest, aber ein Parameter mitgibst;zB. eine Tenant Id, auf die Du dann wiederum umleiten kannst (denk dran hier eine eigene ID zu vergeben, um keine Azure Tenant ID zu exposen!).
Weiß aber nicht, ob das 100% funktioniert.

Da Du nun aber insgesamt von Multi Domain sprichst (was schon noch mal eine andere Schippe als SaaS ist): Azure AD (und auch Azure AD B2C) hat einige Limitations was das Multi-Domain-Verhalten angeht.
Ich kenn die jetz nicht alle auswendig und weiß auch nicht, ob die Dich überhaupt dann betreffen.

Zitat von Savage

und im Event OnTokenValidated kann ich auch die tenantid des jeweiligen ADs auslesen.

Korrekt.