Mehrere OpenIdConnectAuthentication-Middlewares für Multitenancy

Question

Wir versuchen, den wunderbaren IdentityServer für unser Produkt zu verwenden. Ihre Anwendung sollte in der Lage sein, mit verschiedenen Mandanten zu arbeiten, und jeder Mandanten könnte eigene Identitätsanbieter haben.

Der IdentityServer Teil „könnte“ (es funktioniert, aber ich bin nicht sicher, ob das Super klug ist) wie folgt gelöst werden:

app.Map("/demotenant", (test) => 
     { 
      test.UseIdentityServer(new IdentityServerOptions 
      { 
       SiteName = "Embedded IdentityServer", 
       SigningCertificate = Certificate.Load(), 
       Factory = factory, 
       RequireSsl = false, 
       AuthenticationOptions = new AuthenticationOptions 
       { 
        EnableLocalLogin = false, 
        IdentityProviders = ConfigureIdentityProviders, 
       }, 
      }); 
     }); 

app.Map("/demotenant2", (test) => 
     { 
      test.UseIdentityServer(new IdentityServerOptions 
      { 
       SiteName = "Embedded IdentityServer", 
       SigningCertificate = Certificate.Load(), 
       Factory = factory, 
       RequireSsl = false, 
       AuthenticationOptions = new AuthenticationOptions 
       { 
        EnableLocalLogin = false, 
        IdentityProviders = ConfigureIdentityProviders, 
       }, 
      }); 
     }); 

Jetzt habe ich versucht, dies aus meiner Webapplikation zu verwenden. Wenn ich arbeite/demotenant sollte es den/demotenant-Identität-Server verwendet usw.

app.Map("/demotenant", (test) => 
{ 
    test.UseCookieAuthentication(new CookieAuthenticationOptions() 
    { 
     AuthenticationType = "cookies", 
    }); 
    test.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions() 
    { 
     AuthenticationType = "oidc", 
     SignInAsAuthenticationType = "cookies", 
     Authority = "http://localhost:63958/demotenant", 
     ClientId = "webapp", 
     RedirectUri = "http://localhost:57354/", 
     ResponseType = "id_token", 
     Scope = "openid", 
     Notifications = new OpenIdConnectAuthenticationNotifications 
     { 
      RedirectToIdentityProvider = async f => 
      { 
       f.ProtocolMessage.AcrValues = "datasourceId:test"; 
      }, 
     }, 
    }); 
}); 

app.Map("/demotenant2", (test) => 
{ 
    test.UseCookieAuthentication(new CookieAuthenticationOptions() 
    { 
     AuthenticationType = "cookies", 
    }); 

    test.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions() 
    { 
     AuthenticationType = "oidc", 
     SignInAsAuthenticationType = "cookies", 
     Authority = "http://localhost:63958/demotenant2", 
     ClientId = "webapp", 
     RedirectUri = "http://localhost:57354/", 
     ResponseType = "id_token", 
     Scope = "openid", 
     Notifications = new OpenIdConnectAuthenticationNotifications 
     { 
      RedirectToIdentityProvider = async f => 
      { 
       f.ProtocolMessage.AcrValues = "datasourceId:test"; 
      } 
     }, 
    }); 
}); 

Leider funktioniert es nicht oder zumindest kann ich nicht den Authentifizierungsablauf auslösen.

Mein "einfaches" Beispiel verwendet nur das Attribut [Autorisieren], das mich auf magische Weise zu meinem IdentityServer weiterleitet. So ist die Frage:
- Ist es möglich, eine der Autorisierung basierend auf einem Routing auszulösen, wenn ja: Wie?

Answer 1

Bitte beachten Sie, dass Sie die app.Map nicht verwenden müssen, um auf der Grundlage des Mandanten zu den Identity-Providern [IDP] zu routen. Im IdentityServer müssen Sie den genauen IDP basierend auf dem Mandanten ermitteln. Dann kannst du einfach die Challenge für diesen bestimmten IDP aufrufen.

Schritte

1. Identifizieren Sie den Mieter
2. Look-up der IDP für den Mieter
3. nun vom eingetragenen IDP vom Owin Middlewares, werden Sie die Herausforderung aufrufen müssen. 4.Die Endpunkte/clientID & Geheimnisse sollen vom identifizierten Mieter gelöst werden.
4. Dies ermöglicht eine vollständig dynamische Pipeline ohne mandantenspezifische Routen. In einer mandantenfähigen Produktions-App möchten wir kein neues Bereitstellungsupdate für jeden neuen Mandanten, den wir an Bord haben, vornehmen.
5. Zum Beispiel, im Falle eines Mieters, der sich für Social Identity-Anbieter entscheidet, enthält der loginmodel.Provider alle Login-Optionen wie Facebook, Google, Twitter usw.
6. Der Benutzer kann wählen und klicken Sie auf Login.

Codebeispiel den Endpunkt zu lösen URIs aus einer OWIN Middleware auf einem Mieter basiert OnDemandEndpoints = async (clientid, EndpointUriTypes) => { var endpointResolver = ServiceLocator.Resolve<IClientEndpointResolver>(); return await endpointResolver.ResolveEndpointUri(EndpointUriTypes, clientid); },

braucht es einige Kontext sein, dass Ihre Mieter Kontext über die Middleware, so dass von der Endpunkt-Auflösung führen können die clientId und ClientSecrets können dynamisch aufgelöst werden.

Ich hoffe, dies ist hilfreich für Sie