Esempio 1: ABAC di base con autorizzazioni verificate e Cedar

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.

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.

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 tipoSalary. 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 tipoSalary. Fornisci questa struttura in un formatoentityList, in cui gli attributi associati a Salary includono un proprietario, che specifica e entityIdentifier che contiene il tipo Employee e il valoreBob. Verified Permissions confronta quanto principal fornito nella richiesta di autorizzazione con l'ownerattributo 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 tipoEmployee. L'azione che Alice sta cercando di eseguire èviewSalary, e la risorsa che viewSalary verrà visualizzata è del tipo Salary con un valore diSalary-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'managerattributo, che deve quindi essere associato all'ownerattributo del tipo Salary con un valore diSalary-Bob. Fornite questa struttura in un formatoentityList, in cui gli attributi associati a Salary includono un proprietario, che specifica e entityIdentifier che contiene il tipo Employee e il valoreBob. Verified Permissions controlla innanzitutto l'ownerattributo, che restituisce il tipo Employee e il valore. Bob Quindi, Verified Permissions valuta l'managerattributo 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.