Bewährte Methoden für Mehrmandantenfähigkeit mit benutzerdefiniertem Umfang - Amazon Cognito
Beispiel für eine Ressource

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bewährte Methoden für Mehrmandantenfähigkeit mit benutzerdefiniertem Umfang

Amazon Cognito unterstützt benutzerdefinierte OAuth 2.0-Bereiche für Ressourcenserver. Sie können die Mehrmandantenfähigkeit von App-Clients in Benutzerpools für machine-to-machine (M2M-) Autorisierungsmodelle mit benutzerdefinierten Bereichen implementieren. Die bereichsbasierte Mehrmandantenfähigkeit reduziert den Aufwand für die Implementierung von M2M-Multi-Tenancy, indem der Zugriff in Ihrem App-Client oder Ihrer Anwendungskonfiguration definiert wird.

Anmerkung

Derzeit können Sie Zugriffstoken nicht anpassen, um benutzerdefinierte Ansprüche oder Bereiche in den Autorisierungsabläufen für Kundenanmeldedaten (M2M) hinzuzufügen.

Das folgende Diagramm zeigt eine Option für Mehrmandantenfähigkeit mit benutzerdefiniertem Geltungsbereich. Es zeigt jeden Mandanten mit einem dedizierten App-Client, der Zugriff auf relevante Bereiche in einem Benutzerpool hat.

Ein Diagramm, das den Ablauf benutzerdefinierter Bereiche in einer Mehrmandantenarchitektur veranschaulicht.
Wann sollte eine Mehrmandantenfähigkeit mit benutzerdefiniertem Geltungsbereich implementiert werden

Wenn Sie die M2M-Autorisierung mit Kundenanmeldedaten in einem vertraulichen Client verwenden. Es hat sich bewährt, Ressourcenserver zu erstellen, die ausschließlich für einen App-Client bestimmt sind. Mehrmandantenfähigkeit mit benutzerdefiniertem Umfang kann anforderungs- oder clientabhängig sein.

Abhängig von der Anfrage

Implementieren Sie die Anwendungslogik, um nur die Bereiche anzufordern, die den Anforderungen Ihres Mandanten entsprechen. Beispielsweise kann ein App-Client Lese- und Schreibzugriff auf API A und API B gewähren, aber Mandantenanwendung A fordert nur den Lesebereich für API A und den Bereich an, der die Mieterschaft angibt. Dieses Modell ermöglicht komplexere Kombinationen von gemeinsam genutzten Bereichen zwischen Mandanten.

Abhängig vom Kunden

Fordern Sie in Ihren Autorisierungsanfragen alle Bereiche an, die einem App-Client zugewiesen sind. Lassen Sie dazu den scope Anforderungsparameter in Ihrer Anfrage an die weg. Token-Endpunkt Dieses Modell ermöglicht es App-Clients, die Zugriffsindikatoren zu speichern, die Sie Ihren benutzerdefinierten Bereichen hinzufügen möchten.

In beiden Fällen erhalten Ihre Anwendungen Zugriffstoken mit Bereichen, die ihre Rechte für Datenquellen angeben, von denen sie abhängig sind. Bereiche können Ihrer Anwendung auch andere Informationen bieten:

  • Benennen Sie das Mietverhältnis

  • Tragen Sie zur Protokollierung von Anfragen bei

  • Geben Sie an APIs , dass die Anwendung für Abfragen autorisiert ist

  • Informieren Sie über die ersten Checks für aktive Kunden.

Grad des Aufwands

Kundenspezifische Mehrmandantenfähigkeit erfordert je nach Umfang Ihrer Anwendung einen unterschiedlichen Aufwand. Sie müssen eine Anwendungslogik entwickeln, die es Ihren Anwendungen ermöglicht, Zugriffstoken zu analysieren und die entsprechenden API-Anfragen zu stellen.

Ein Ressourcenserverbereich hat beispielsweise das Format. [resource server identifier]/[name] Es ist unwahrscheinlich, dass die ID des Ressourcenservers für die Autorisierungsentscheidung aus dem Mandantenbereich relevant ist, sodass der Bereichsname konsistent analysiert werden muss.

Beispiel für eine Ressource

Die folgende AWS CloudFormation Vorlage erstellt einen Benutzerpool für Mehrmandantenfähigkeit in benutzerdefiniertem Umfang mit einem Ressourcenserver und einem App-Client.

AWSTemplateFormatVersion: "2010-09-09"
Description: A sample template illustrating scope-based multi-tenancy
Resources:
  MyUserPool:
    Type: "AWS::Cognito::UserPool"
  MyUserPoolDomain:
    Type: AWS::Cognito::UserPoolDomain
    Properties:
      UserPoolId: !Ref MyUserPool
      # Note that the value for "Domain" must be unique across all of AWS.
      # In production, you may want to consider using a custom domain.
      # See: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-add-custom-domain.html#cognito-user-pools-add-custom-domain-adding
      Domain: !Sub "example-userpool-domain-${AWS::AccountId}"
  MyUserPoolResourceServer:
    Type: "AWS::Cognito::UserPoolResourceServer"
    Properties:
      Identifier: resource1
      Name: resource1
      Scopes:
        - ScopeDescription: Read-only access
          ScopeName: readScope
      UserPoolId: !Ref MyUserPool
  MyUserPoolTenantBatch1ResourceServer:
    Type: "AWS::Cognito::UserPoolResourceServer"
    Properties:
      Identifier: TenantBatch1
      Name: TenantBatch1
      Scopes:
        - ScopeDescription: tenant1 identifier
          ScopeName: tenant1
        - ScopeDescription: tenant2 identifier
          ScopeName: tenant2
      UserPoolId: !Ref MyUserPool
  MyUserPoolClientTenant1:
    Type: "AWS::Cognito::UserPoolClient"
    Properties:
      AllowedOAuthFlows:
        - client_credentials
      AllowedOAuthFlowsUserPoolClient: true
      AllowedOAuthScopes:
        - !Sub "${MyUserPoolTenantBatch1ResourceServer}/tenant1"
        - !Sub "${MyUserPoolResourceServer}/readScope"
      GenerateSecret: true
      UserPoolId: !Ref MyUserPool
Outputs:
  UserPoolClientId:
    Description: User pool client ID
    Value: !Ref MyUserPoolClientTenant1
  UserPoolDomain:
    Description: User pool domain
    Value: !Sub "https://${MyUserPoolDomain}.auth.${AWS::Region}.amazoncognito.com"