

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à.

# Esempio 1: ABAC di base con autorizzazioni verificate e Cedar
<a name="avp-basic-abac-examples"></a>

In questo scenario di esempio, Amazon Verified Permissions viene utilizzato per determinare a quali utenti è consentito accedere alle informazioni in un microservizio Payroll fittizio. Questa sezione include frammenti di codice Cedar per dimostrare come utilizzare Cedar per prendere decisioni sul controllo degli accessi. Questi esempi non intendono fornire un'esplorazione completa delle funzionalità fornite da Cedar e Verified Permissions. [Per una panoramica più completa di Cedar, consulta la documentazione di Cedar.](https://docs.cedarpolicy.com/)

Nel diagramma seguente, vorremmo applicare due regole aziendali generali associate al `viewSalary` `GET` metodo: i dipendenti possono visualizzare il *proprio stipendio e i dipendenti possono visualizzare *lo stipendio di chiunque faccia* loro* capo. È possibile applicare queste regole aziendali utilizzando le politiche di autorizzazione verificate.

![Esempio di implementazione ABAC di base con Amazon Verified Permissions e Cedar per implementare un PDP](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-1.png)


*I dipendenti possono visualizzare il proprio stipendio.*

In Cedar, il costrutto di base è un'*entità*, che rappresenta un principale, un'azione o una risorsa. Per effettuare una richiesta di autorizzazione e avviare una valutazione con una politica di autorizzazioni verificate, è necessario fornire un *responsabile,* un'*azione*, una *risorsa* e un *elenco* di entità.
+ Il principal (`principal`) è l'utente o il ruolo registrato.
+ L'azione (`action`) è l'operazione che viene valutata dalla richiesta.
+ La risorsa (`resource`) è il componente a cui l'azione accede.
+ L'elenco delle entità (`entityList`) contiene tutte le entità richieste necessarie per valutare la richiesta.

Per soddisfare la regola aziendale, *i dipendenti possono visualizzare il proprio stipendio*, è possibile fornire una politica di autorizzazioni verificate come la seguente.

```
permit (
    principal,
    action == Action::"viewSalary",
    resource
)
when {
    principal == resource.owner
};
```

Questa politica valuta `ALLOW` se la risorsa `Action` is `viewSalary` e la risorsa inclusa nella richiesta hanno un proprietario dell'attributo uguale al principale. Ad esempio, se Bob è l'utente connesso che ha richiesto il rapporto sullo stipendio ed è anche il proprietario del rapporto sullo stipendio, la politica restituisce lo stesso. `ALLOW`

La seguente richiesta di autorizzazione viene inviata a Verified Permissions per essere valutata in base alla politica di esempio. In questo esempio, Bob è l'utente connesso che effettua la richiesta. `viewSalary` Pertanto, Bob è il principale del tipo `Employee` di entità. L'azione che Bob sta cercando di eseguire è `viewSalary,` e la risorsa che `viewSalary` verrà visualizzata è `Salary-Bob` del tipo`Salary`. Per valutare se Bob può visualizzare la `Salary-Bob` risorsa, è necessario fornire una struttura di entità che colleghi il tipo `Employee` con un valore pari a `Bob` (principale) all'attributo proprietario della risorsa che ha il tipo`Salary`. Fornisci questa struttura in un formato`entityList`, in cui gli attributi associati a `Salary` includono un proprietario, che specifica e `entityIdentifier` che contiene il tipo `Employee` e il valore`Bob`. Verified Permissions confronta quanto `principal` fornito nella richiesta di autorizzazione con l'`owner`attributo associato alla `Salary` risorsa per prendere una decisione.

```
{
  "policyStoreId": "PAYROLLAPP_POLICYSTOREID",
  "principal": {
    "entityType": "PayrollApp::Employee",
    "entityId": "Bob"
  },
  "action": {
    "actionType": "PayrollApp::Action",
    "actionId": "viewSalary"
  },
  "resource": {
    "entityType": "PayrollApp::Salary",
    "entityId": "Salary-Bob"
  },
  "entities": {
    "entityList": [
      {
        "identifier": {
          "entityType": "PayrollApp::Salary",
          "entityId": "Salary-Bob"
        },
        "attributes": {
          "owner": {
            "entityIdentifier": {
              "entityType": "PayrollApp::Employee",
              "entityId": "Bob"
            }
          }
        }
      },
      {
        "identifier": {
          "entityType": "PayrollApp::Employee",
          "entityId": "Bob"
        },
        "attributes": {}
      }
    ]
  }
}
```

La richiesta di autorizzazione a Verified Permissions restituisce quanto segue come output, dove l'attributo `decision` è o. `ALLOW` `DENY`

```
{
    "determiningPolicies": 
        [ 
            {
                "determiningPolicyId": "PAYROLLAPP_POLICYSTOREID" 
            }
        ],
    "decision": "ALLOW",
    "errors": [] 
}
```

In questo caso, poiché Bob stava cercando di visualizzare il proprio stipendio, la richiesta di autorizzazione inviata a Verified Permissions corrisponde a. `ALLOW` Tuttavia, il nostro obiettivo era utilizzare le autorizzazioni verificate per applicare due regole aziendali. Anche la regola aziendale che afferma quanto segue dovrebbe essere vera:

*I dipendenti possono visualizzare lo stipendio di chiunque risponda a loro.*

Per soddisfare questa regola aziendale, puoi fornire un'altra politica. La seguente politica valuta `ALLOW` se l'azione è `viewSalary` e se la risorsa nella richiesta ha un attributo `owner.manager` uguale al principale. Ad esempio, se Alice è l'utente connesso che ha richiesto il rapporto sullo stipendio e Alice è la responsabile del proprietario del rapporto, la politica restituisce lo stesso risultato. `ALLOW`

```
permit (
    principal,
    action == Action::"viewSalary",
    resource
)
when {
    principal == resource.owner.manager
};
```

La seguente richiesta di autorizzazione viene inviata a Verified Permissions per essere valutata in base alla politica di esempio. In questo esempio, Alice è l'utente connesso che effettua la richiesta. `viewSalary` Quindi Alice è la principale e l'entità è del tipo`Employee`. L'azione che Alice sta cercando di eseguire è`viewSalary`, e la risorsa che `viewSalary` verrà visualizzata è del tipo `Salary` con un valore di`Salary-Bob`. Per valutare se Alice può visualizzare la `Salary-Bob` risorsa, è necessario fornire una struttura di entità che colleghi il tipo `Employee` con un valore pari `Alice` all'`manager`attributo, che deve quindi essere associato all'`owner`attributo del tipo `Salary` con un valore di`Salary-Bob`. Fornite questa struttura in un formato`entityList`, in cui gli attributi associati a `Salary` includono un proprietario, che specifica e `entityIdentifier` che contiene il tipo `Employee` e il valore`Bob`. Verified Permissions controlla innanzitutto l'`owner`attributo, che restituisce il tipo `Employee` e il valore. `Bob` Quindi, Verified Permissions valuta l'`manager`attributo a cui è associato `Employee` e lo confronta con il principale fornito per prendere una decisione di autorizzazione. In questo caso, la decisione è `ALLOW` dovuta al fatto che `resource.owner.manager` gli attributi `principal ` and sono equivalenti.

```
{
  "policyStoreId": "PAYROLLAPP_POLICYSTOREID",
  "principal": {
    "entityType": "PayrollApp::Employee",
    "entityId": "Alice"
  },
  "action": {
    "actionType": "PayrollApp::Action",
    "actionId": "viewSalary"
  },
  "resource": {
    "entityType": "PayrollApp::Salary",
    "entityId": "Salary-Bob"
  },
  "entities": {
    "entityList": [
      {
        "identifier": {
          "entityType": "PayrollApp::Employee",
          "entityId": "Alice"
        },
        "attributes": {
          "manager": {
            "entityIdentifier": {
              "entityType": "PayrollApp::Employee",
              "entityId": "None"
            }
          }
        },
        "parents": []
      },
      {
        "identifier": {
          "entityType": "PayrollApp::Salary",
          "entityId": "Salary-Bob"
        },
        "attributes": {
          "owner": {
            "entityIdentifier": {
              "entityType": "PayrollApp::Employee",
              "entityId": "Bob"
            }
          }
        },
        "parents": []
      },
      {
        "identifier": {
          "entityType": "PayrollApp::Employee",
          "entityId": "Bob"
        },
        "attributes": {
          "manager": {
            "entityIdentifier": {
              "entityType": "PayrollApp::Employee",
              "entityId": "Alice"
            }
          }
        },
       "parents": []
      }
    ]
  }
}
```

Finora, in questo esempio, abbiamo fornito le due regole aziendali associate al `viewSalary` metodo, vale a dire che *i dipendenti possono visualizzare il proprio stipendio* e *i dipendenti possono visualizzare lo stipendio di chiunque risponda a loro*, utilizzando le autorizzazioni verificate come politiche per soddisfare le condizioni di ogni regola aziendale in modo indipendente. Puoi anche utilizzare un'unica politica di autorizzazioni verificate per soddisfare le condizioni di entrambe le regole aziendali:

*I dipendenti possono visualizzare il proprio stipendio e quello di chiunque risponda a loro.*

Quando si utilizza la richiesta di autorizzazione precedente, la seguente politica valuta `ALLOW` se l'azione è `viewSalary` e se la risorsa inclusa nella richiesta ha un attributo `owner.manager` uguale a o un attributo `owner` uguale a. `principal` `principal` 

```
permit (
    principal,
    action == PayrollApp::Action::"viewSalary",
    resource
)
when {
    principal == resource.owner.manager ||
    principal == resource.owner
};
```

Ad esempio, se Alice è l'utente connesso che richiede il rapporto sullo stipendio e se Alice è la responsabile del proprietario o la proprietaria del rapporto, la politica restituisce tale rapporto. `ALLOW`

[Per ulteriori informazioni sull'utilizzo degli operatori logici con le politiche Cedar, consultate la documentazione di Cedar.](https://docs.cedarpolicy.com/policies/syntax-operators.html)