Ověřování a autorizace v aplikaci
Zabezpečení je důležité pro moderní webové aplikace. Fluid Framework, jako součást architektury webové aplikace, je důležitou součástí infrastruktury pro zabezpečení. Fluid Framework je vícevrstvá architektura a koncepty související s ověřováním se implementují na základě služby Fluid, ke které se připojuje. To znamená, že i když existují běžné motivy ověřování ve všech službách Fluid, podrobnosti a specifika se pro každou službu budou lišit.
Služba Azure Fluid Relay
Každému vytvořenému tenantovi služby Azure Fluid Relay se přiřadí ID tenanta a vlastní jedinečný tajný klíč tenanta.
Tajný klíč je sdílený tajný klíč. Vaše aplikace nebo služba ji zná a služba Azure Fluid Relay ji zná. Vzhledem k tomu, že tajný klíč tenanta je jedinečně svázaný s vaším tenantem, jeho použití k podepisování požadavků službě Azure Fluid Relay zaručuje, že požadavky pocházejí od autorizovaného uživatele tenanta.
Tajný klíč je způsob, jakým služba Azure Fluid Relay ví, že žádosti pocházejí z vaší aplikace nebo služby. To je důležité, protože jakmile služba Azure Fluid Relay může důvěřovat tomu, že aplikace provádí požadavky, může důvěřovat datům, která odesíláte. To je také důvod, proč je důležité, aby tajný kód byl bezpečně zpracován.
Upozornění
Kdokoli, kdo má přístup k tajnému kódu, může zosobnit vaši aplikaci při komunikaci se službou Azure Fluid Relay.
Webové tokeny JSON a služba Azure Fluid Relay
Azure Fluid Relay používá k kódování a ověření dat podepsaných pomocí tajného klíče webové tokeny JSON (JWT). Webové tokeny JSON jsou podepsaným bitem JSON, který může obsahovat další informace o právech a oprávněních.
Poznámka:
Specifika JWT jsou nad rámec tohoto článku. Další informace o standardu JWT najdete v tématu Úvod k webovým tokenům JSON.
I když se podrobnosti ověřování mezi službami Fluid liší, musí vždy existovat několik hodnot.
- containerId The Fluid service potřebuje ID kontejneru k identifikaci služby odpovídající volajícímu kontejneru. Poznámka: JWT volá toto pole documentId, ale služba Fluid očekává ID kontejneru v tomto poli.
- tenantId: Služba Azure Fluid Relay používá ID tenanta k načtení sdíleného tajného kódu, který použije k ověření vaší žádosti.
- obory: Obory definují oprávnění volajícího kontejneru. Obsah pole oborů je flexibilní a umožňuje vytvářet vlastní oprávnění.
{
"alg": "HS256",
"typ": "JWT"
}.{
"documentId": "azureFluidDocumentId",
"scopes": [ "doc:read", "doc:write", "summary:write" ],
"user": {
"name": "TestUser",
"id": "Test-Id-123"
},
"iat": 1599098963,
"exp": 1599098963,
"tenantId": "AzureFluidTenantId",
"ver": "1.0"
}.[Signature]
Režim uživatele označuje, jestli je připojení v režimu čtení nebo čtení/zápisu. To lze zobrazit z connections pole v AzureAudience. Oprávnění oboru tokenu je možné aktualizovat v bezserverové funkci Azure Functions pod generateToken funkcí.
const token = generateToken(
tenantId,
documentId,
key,
scopes ?? [ "Token Scope" ],
user
);
Obory tokenů spolu s chováním a režimy kontejneru jsou následující:
| Obor tokenu | Chování dokumentu | Chování dokumentu cílové skupiny |
|---|---|---|
| DocRead | Čtení a zápis do dokumentu Změny provedené v dokumentu se neprojeví v žádném jiném dokumentu cílové skupiny. Režim: Čtení |
Čtení a zápis do dokumentu Změny se neprojeví v žádném jiném dokumentu cílové skupiny. Režim: Zápis |
| DocWrite | Čtení a zápis do dokumentu Provedené změny se projeví ve všech ostatních dokumentech cílové skupiny. Režim: Zápis |
Čtení a zápis do dokumentu Provedené změny se projeví ve všech ostatních dokumentech cílové skupiny. Režim: Zápis |
| DocRead, DocWrite | Čtení a zápis do dokumentu Provedené změny se projeví ve všech ostatních dokumentech cílové skupiny. Režim: Zápis |
Čtení a zápis do dokumentu Provedené změny se projeví ve všech ostatních dokumentech cílové skupiny. Režim: Zápis |
Poznámka:
Všimněte si, že token obsahuje také informace o uživateli (viz řádky 7–9 výše). Můžete ho použít k rozšíření informací o uživateli, které jsou automaticky dostupné pro kód fluidu pomocí funkce cílové skupiny . Další informace najdete v tématu Přidání vlastních dat do tokenů .
Zprostředkovatel tokenu
Každý požadavek na Azure Fluid Relay musí být podepsaný platným JWT. Fluid deleguje odpovědnost za vytváření a podepisování těchto tokenů poskytovatelům tokenů.
Zprostředkovatel tokenu zodpovídá za vytváření a podepisování tokenů, které @fluidframework/azure-client používá k odesílání požadavků do služby Azure Fluid Relay. Musíte zadat vlastní implementaci zprostředkovatele zabezpečených tokenů. Fluid ale poskytuje InsecureTokenProvider klíč vašeho tenanta, který pak místně vygeneruje a vrátí podepsaný token. Tento poskytovatel tokenu je užitečný pro testování, ale nelze ho použít v produkčních scénářích.
Zabezpečený poskytovatel bezserverového tokenu
Jednou z možností vytvoření zprostředkovatele zabezpečeného tokenu je vytvoření bezserverové funkce Azure Functions a její zveřejnění jako zprostředkovatele tokenu. To vám umožní uložit tajný klíč tenanta na zabezpečeném serveru. Vaše aplikace pak zavolá funkci Azure Functions, aby vygenerovala tokeny místo jejich místního podepisování, jako tomu bylo.InsecureTokenProvider Další informace naleznete v tématu Postupy: Zápis TokenProvider pomocí funkce Azure Functions.
Připojení ověřování uživatelů k ověřování služby Fluid Service
Služby Fluid Services ověřují příchozí hovory pomocí sdíleného tajného klíče klienta, který není svázaný s konkrétním uživatelem. Ověřování uživatelů je možné přidat na základě podrobností o vaší službě Fluid.
Jednou z jednoduchých možností pro ověřování uživatelů je jednoduše použít funkci Azure Functions jako zprostředkovatele tokenu a vynutit ověření uživatele jako podmínku získání tokenu. Pokud se aplikace pokusí volat funkci, selže, pokud není ověřena ve vašem ověřovacím systému. Pokud například používáte ID Microsoft Entra, můžete pro funkci Azure Vytvořit aplikaci Microsoft Entra a svázat ji s ověřovacím systémem vaší organizace.
V takovém případě by se uživatel přihlásil k vaší aplikaci pomocí ID Microsoft Entra, prostřednictvím kterého byste získali token, který se použije k volání funkce Azure Functions. Samotná funkce Azure Se chová stejně, ale teď je přístupná jenom uživatelům, kteří se také ověřili pomocí MICROSOFT Entra ID.
Vzhledem k tomu, že funkce Azure Functions je teď vaším vstupním bodem k získání platného tokenu, z klientské aplikace budou moct tento token poskytnout pouze uživatelé, kteří funkci správně ověřili. Tento dvoustupňový přístup umožňuje používat vlastní proces ověřování ve spojení se službou Azure Fluid Relay.