Sdílet prostřednictvím

Autorizace a role v Tvůrci rozhraní Data API

Tvůrce rozhraní Data API používá pracovní postup autorizace na základě role. Každému příchozímu požadavku, ověřenému nebo ne, je přiřazena role. Role můžou být systémové role nebo role uživatelů. Přiřazená role se pak kontroluje proti definovaným oprávněním zadaným v konfiguraci, abyste pochopili, jaké akce, pole a zásady jsou pro danou roli pro požadovanou entitu k dispozici.

Určení role uživatele

Žádné role nemá výchozí oprávnění. Jakmile tvůrce rozhraní Data API určí pravidlo, musí entita permissions definovat actions tuto roli, aby žádost byla úspěšná.

Poskytnutý token x-ms-api-role Poskytnutý x-ms-api-role v Tokenu Výsledná role
Ne Ne Ne anonymous
Ano Ne Ne authenticated
Ano Ano Ne Výjimka
Ano Ano Ano x-ms-api-role hodnota

Pokud chcete mít jinou roli než anonymous nebo authenticated, je požadována hlavička x-ms-api-role .

Poznámka:

Požadavek může mít jenom jednu roli. I když token označuje více rolí, hodnota x-ms-api-role vybere, která role je přiřazena k požadavku.

Systémové role

Systémové role jsou předdefinované role rozpoznané tvůrcem rozhraní DATA API. Systémová role se automaticky přiřadí žadateli bez ohledu na členství v roli žadatele označeného v přístupových tokenech. Existují dvě systémové role: anonymous a authenticated.

Role anonymního systému

Role anonymous systému je přiřazena k žádostem spuštěným neověřenými uživateli. Pokud se vyžaduje neověřený přístup, musí definované entity modulu runtime obsahovat oprávnění pro anonymous roli.

Příklad

Následující konfigurace modulu runtime pro nástroj pro tvorbu rozhraní Data API ukazuje explicitní nastavení systémové role anonymous, aby zahrnovala přístup k čtení pro entitu Kniha:

"Book": {
    "source": "books",
    "permissions": [
        {
            "role": "anonymous",
            "actions": [ "read" ]
        }
    ]
}

Když klientská aplikace odešle žádost o přístup k entitě Knihy jménem neověřeného uživatele, neměla by aplikace obsahovat hlavičku Authorization HTTP.

Ověřená systémová role

Role authenticated systému je přiřazena k žádostem spuštěným ověřenými uživateli.

Příklad

Následující konfigurace modulu runtime pro nástroj pro tvorbu rozhraní Data API ukazuje explicitní nastavení systémové role authenticated, aby zahrnovala přístup k čtení pro entitu Kniha:

"Book": {
    "source": "books",
    "permissions": [
        {
            "role": "authenticated",
            "actions": [ "read" ]
        }
    ]
}

Role uživatelů

Role uživatelů jsou nesystémové role, které jsou přiřazeny uživatelům v rámci zprostředkovatele identity, který jste nastavili v konfiguraci modulu runtime. Aby tvůrce rozhraní Data API vyhodnotil požadavek v kontextu role uživatele, musí být splněny dva požadavky:

  1. Poskytnutý přístupový token klientské aplikace musí obsahovat deklarace rolí, které uvádějí členství v roli uživatele.
  2. Klientská aplikace musí obsahovat hlavičku X-MS-API-ROLE HTTP s požadavky a nastavit hodnotu hlavičky jako požadovanou roli uživatele.

Příklad vyhodnocení role

Následující příklad ukazuje požadavky na entitu Book , která je nakonfigurovaná v konfiguraci modulu runtime Tvůrce rozhraní Data API, následujícím způsobem:

"Book": {
    "source": "books",
    "permissions": [
        {
            "role": "anonymous",
            "actions": [ "read" ]
        },
        {
            "role": "authenticated",
            "actions": [ "read" ]
        },
        {
            "role": "author",
            "actions": [ "read" ]
        }
    ]
}

Ve službě Static Web Apps je uživatel ve výchozím nastavení členem anonymní role. Pokud je uživatel ověřený, je členem rolí anonymous a authenticated.

Když klientská aplikace odešle ověřený požadavek tvůrci rozhraní Data API nasazeného pomocí připojení databáze Static Web Apps (Preview), klientská aplikace poskytuje přístupový token, který Static Web Apps transformuje na JSON:

{
  "identityProvider": "azuread",
  "userId": "d75b260a64504067bfc5b2905e3b8182",
  "userDetails": "username",
  "userRoles": ["anonymous", "authenticated", "author"]
}

Vzhledem k tomu, že Tvůrce rozhraní Data API vyhodnocuje požadavky v kontextu jedné role, vyhodnotí požadavek ve výchozím nastavení v kontextu systémové role authenticated .

Pokud požadavek klientské aplikace obsahuje také hlavičku X-MS-API-ROLE HTTP s hodnotou author, požadavek se vyhodnotí v kontextu author role. Příklad požadavku včetně přístupového tokenu a X-MS-API-ROLE hlavičky HTTP:

curl -k -r GET -H 'Authorization: Bearer ey...' -H 'X-MS-API-ROLE: author' https://localhost:5001/api/Book

Důležité

Požadavek klientské aplikace se odmítne, když deklarace identity zadaného roles přístupového tokenu neobsahuje roli uvedenou v X-MS-API-ROLE hlavičce.

Povolení

Oprávnění popisují:

  • Kdo může na základě členství v roli podávat žádosti ohledně entity?
  • Jaké akce (vytvoření, čtení, aktualizace, odstranění, spuštění) může uživatel provádět?
  • Která pole jsou pro konkrétní akci přístupná?
  • Jaká další omezení existují u výsledků vrácených požadavkem?

Syntaxe pro definování oprávnění je popsaná v článku o konfiguraci modulu runtime.

Důležité

V konfiguraci oprávnění jedné entity může být definováno více rolí. Požadavek se ale vyhodnocuje pouze v kontextu jedné role:

  • Ve výchozím nastavení je buď role systému anonymous, nebo authenticated
  • Pokud je zahrnuta, nastaví se role v hlavičce HTTP X-MS-API-ROLE.

Ve výchozím nastavení zabezpečeno

Ve výchozím nastavení nemá entita nakonfigurovaná žádná oprávnění, což znamená, že k entitě nemá nikdo přístup. Tvůrce rozhraní Data API navíc ignoruje databázové objekty, pokud nejsou odkazovány v konfiguraci modulu runtime.

Oprávnění musí být explicitně nakonfigurovaná.

Pokud chcete povolit neověřený přístup k entitě, anonymous musí být role explicitně definována v oprávněních entity. Například oprávnění book entity jsou explicitně nastavena tak, aby povolovala neověřený přístup pro čtení:

"book": {
  "source": "dbo.books",
  "permissions": [{
    "role": "anonymous",
    "actions": [ "read" ]
  }]
}

Pokud chcete zjednodušit definici oprávnění u entity, předpokládejme, že pokud pro roli neexistují žádná konkrétní oprávnění authenticated , použijí se oprávnění definovaná pro danou anonymous roli. Tato book konfigurace dříve umožňovala všem anonymním nebo ověřeným uživatelům provádět operace čtení na book entitě.

Pokud by operace čtení měly být omezené jenom na ověřené uživatele, měla by se nastavit následující konfigurace oprávnění, což vede k zamítnutí neověřených požadavků:

"book": {
  "source": "dbo.books",
  "permissions": [{
    "role": "authenticated",
    "actions": [ "read" ]
  }]
}

Entita nevyžaduje a není s oprávněními předem nakonfigurovaná pro role anonymous a authenticated. Jedna nebo více uživatelských rolí je možné definovat v rámci konfigurace oprávnění entity a všechny ostatní nedefinované role, systém nebo uživatelem definované, přístup se automaticky odepře.

V následujícím příkladu je role administrator uživatele jedinou definovanou rolí pro entitu book . Aby uživatel mohl pracovat s entitou administrator, musí být členem role X-MS-API-ROLE a tuto roli zahrnout do book hlavičky HTTP.

"book": {
  "source": "dbo.books",
  "permissions": [{
    "role": "administrator",
    "actions": [ "*" ]
  }]
}

Poznámka:

Pokud chcete vynutit řízení přístupu pro dotazy GraphQL při použití Tvůrce rozhraní Data API se službou Azure Cosmos DB, musíte použít direktivu @authorize v zadaném souboru schématu GraphQL. Pro mutace a filtry v dotazech GraphQL se však řízení přístupu stále vynucuje konfigurací oprávnění, jak bylo popsáno výše.

Akce

Akce popisují přístupnost entity v rámci oboru role. Akce lze zadat jednotlivě nebo pomocí zástupné zkratky: * (hvězdička). Zástupný znak představuje všechny akce podporované pro typ entity.

  • Tabulky a zobrazení: create, read, update, delete
  • Uložené procedury: execute

Další informace o akcích najdete v dokumentaci ke konfiguračnímu souboru .

Přístup k polím

Můžete nakonfigurovat, která pole mají být pro akci přístupná. Můžete například nastavit pole, která mají být zahrnuta a vyloučena z read akce.

Následující příklad zabraňuje uživatelům v roli free-access provádět operace čtení na Column3. Odkazy na Column3 požadavky GET (koncový bod REST) nebo dotazy (koncový bod GraphQL) mají za následek odmítnutý požadavek:

    "book": {
      "source": "dbo.books",
      "permissions": [
        {
          "role": "free-access",
          "actions": [
            "create",
            "update",
            "delete",
            {
              "action": "read",
              "fields": {
                "include": [ "Column1", "Column2" ],
                "exclude": [ "Column3" ]
              }
            }
          ]
        }
      ]
    }

Poznámka:

Pokud chcete vynutit řízení přístupu pro dotazy GraphQL při použití Tvůrce rozhraní Data API se službou Azure Cosmos DB, musíte použít direktivu @authorize v zadaném souboru schématu GraphQL. V případě mutací GraphQL a filtrů v dotazech GraphQL se však řízení přístupu stále vynucuje konfigurací oprávnění, jak je popsáno zde.

Zabezpečení na úrovni položek

Výrazy zásad databáze umožňují ještě více omezit výsledky. Zásady databáze překládají výrazy do predikátů dotazů spuštěných v databázi. Výrazy zásad databáze jsou podporovány pro následující akce:

  • vytvořit
  • číst
  • aktualizace
  • odstranit

Výstraha

Akce execute, která se používá s uloženými procedurami, nepodporuje politiky databáze.

Poznámka:

CosmosDB pro NoSQL v současné době nepodporuje pravidla databáze.

Další informace o zásadách databáze najdete v dokumentaci ke konfiguračnímu souboru .

Příklad

Zásady databáze, které omezují akci read na consumer roli, aby vracely pouze záznamy, kde název je "Ukázkový název".

{
  "role": "consumer",
  "actions": [
    {
      "action": "read",
      "policy": {
        "database": "@item.title eq 'Sample Title'"
      }
    }
  ]
}

Související obsah

  • Last updated on