Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Best practice di multi-tenancy con ambito personalizzato
<a name="scope-based-multi-tenancy"></a>

[Amazon Cognito supporta ambiti OAuth 2.0 personalizzati per server di risorse.](cognito-user-pools-define-resource-servers.md) Puoi implementare la multi-tenancy dei client di app nei pool di utenti per modelli di autorizzazione machine-to-machine (M2M) con ambiti personalizzati. La multi-tenancy basata sull'ambito riduce lo sforzo richiesto per implementare la multi-tenancy M2M definendo l'accesso nel client dell'app o nella configurazione dell'applicazione.

 Il diagramma seguente illustra un'opzione per la multi-tenancy con ambito personalizzato. Mostra ogni tenant con un client di app dedicato che ha accesso agli ambiti pertinenti in un pool di utenti.

![\[Un diagramma che illustra il flusso di ambiti personalizzati in un'architettura multi-tenant.\]](http://docs.aws.amazon.com/it_it/cognito/latest/developerguide/images/multi-tenancy-custom-scope.png)


**Quando implementare la multi-tenancy con ambito personalizzato**  
 Quando si utilizza l'autorizzazione M2M con credenziali client in un client riservato. Come best practice, create server di risorse esclusivi per un client di app. *La multi-tenancy con ambito personalizzato può dipendere dalla *richiesta o dal* client.*

**Dipende dalla richiesta**  
 Implementa la logica dell'applicazione per richiedere solo gli ambiti che soddisfano i requisiti del tuo tenant. Ad esempio, un client di app potrebbe essere in grado di fornire l'accesso in lettura e scrittura all'API A e all'API B, ma l'applicazione tenant A richiede solo l'ambito di lettura per l'API A e l'ambito che indica la tenancy. Questo modello consente combinazioni più complesse di ambiti condivisi tra tenant.

**Dipende dal cliente**  
 Richiedi tutti gli ambiti assegnati a un client dell'app nelle tue richieste di autorizzazione. Per fare ciò, ometti il parametro `scope` request nella tua richiesta in. [Endpoint Token](token-endpoint.md) Questo modello consente ai client dell'app di memorizzare gli indicatori di accesso che desideri aggiungere agli ambiti personalizzati.

 In entrambi i casi, le applicazioni ricevono token di accesso con ambiti che indicano i loro privilegi per le fonti di dati da cui dipendono. Gli ambiti possono anche presentare altre informazioni all'applicazione:
+ Designare la locazione
+ Contribuisci alla registrazione delle richieste
+ Indicate APIs che l'applicazione è autorizzata a eseguire interrogazioni
+ Informa i controlli iniziali per i clienti attivi.

**Livello di impegno**  
 La multi-tenancy con ambito personalizzato richiede un livello di impegno variabile rispetto alla scala dell'applicazione. È necessario elaborare una logica applicativa che consenta alle applicazioni di analizzare i token di accesso ed effettuare le richieste API appropriate.

 Ad esempio, l'ambito di un server di risorse è disponibile nel formato. `[resource server identifier]/[name]` È improbabile che l'identificatore del server di risorse sia rilevante per la decisione di autorizzazione presa dall'ambito del tenant, in quanto richiede un'analisi coerente del nome dell'ambito.

## Risorsa di esempio
<a name="scope-based-multi-tenancy-example"></a>

 Il AWS CloudFormation modello seguente crea un pool di utenti per la multi-tenancy con ambito personalizzato con un server di risorse e un client di app.

```
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"
```