Hitelesítés és engedélyezés az alkalmazásban
A biztonság kritikus fontosságú a modern webalkalmazások számára. Dinamikus keretrendszer a webalkalmazás-architektúra részeként a biztonságos infrastruktúra fontos része. Dinamikus keretrendszer egy rétegzett architektúra, és a hitelesítéssel kapcsolatos fogalmak az általa összekapcsolt Fluid-szolgáltatáson alapulnak. Ez azt jelenti, hogy bár az összes Fluid-szolgáltatásban vannak gyakori hitelesítési témák, a részletek és a részletek minden szolgáltatás esetében eltérőek lesznek.
Azure Fluid Relay szolgáltatás
Minden létrehozott Azure Fluid Relay-szolgáltatás bérlői azonosítót és saját egyedi bérlői titkos kulcsot kap.
A titkos kulcs egy megosztott titkos kód. Az alkalmazás/szolgáltatás tudja, és az Azure Fluid Relay szolgáltatás is ismeri. Mivel a bérlő titkos kulcsa egyedileg a bérlőhöz van kötve, a kérések aláírására használt kulcs garantálja az Azure Fluid Relay szolgáltatásnak, hogy a kérések a bérlő egy jogosult felhasználójától érkeznek.
A titkos kulcs az, ahogyan az Azure Fluid Relay szolgáltatás tudja, hogy a kérések az alkalmazásból vagy szolgáltatásból érkeznek. Ez kritikus fontosságú, mert ha az Azure Fluid Relay szolgáltatás megbízik abban, hogy az alkalmazás intézi a kéréseket, megbízhatóvá teheti a küldött adatokat. Ezért is fontos, hogy a titkos kulcs biztonságosan legyen kezelve.
Figyelmeztetés
Bárki, aki hozzáfér a titkos kódhoz, megszemélyesítheti az alkalmazást az Azure Fluid Relay szolgáltatással folytatott kommunikáció során.
JSON Web Tokens és Azure Fluid Relay szolgáltatás
Az Azure Fluid Relay JSON webes jogkivonatokat (JWT-ket) használ a titkos kulccsal aláírt adatok kódolásához és ellenőrzéséhez. A JSON webes jogkivonatok aláírt JSON-bitek, amelyek további információkat tartalmazhatnak a jogosultságokról és engedélyekről.
Megjegyzés:
A JWT-k jellemzői túlmutatnak a jelen cikk hatókörén. A JWT szabványról további információt a JSON webes jogkivonatok bemutatása című témakörben talál.
Bár a hitelesítés részletei különböznek a Fluid-szolgáltatásoktól, több értéknek mindig jelen kell lennie.
- containerId A Fluid szolgáltatásnak szüksége van a tárolóazonosítóra annak azonosításához, hogy melyik szolgáltatás felel meg a hívó tárolónak. Megjegyzés: A JWT meghívja ezt a mező documentId azonosítóját, de a Fluid szolgáltatás tárolóazonosítót vár ebben a mezőben.
- tenantId: Az Azure Fluid Relay szolgáltatás a bérlőazonosítóval kéri le a kérés hitelesítéséhez használni kívánt megosztott titkos kulcsot.
- hatókörök: A hatókörök határozzák meg a hívó tároló engedélyeit. A hatókörök mező tartalma rugalmas, így saját egyéni engedélyeket hozhat létre.
{
"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]
A felhasználó üzemmódja jelzi, hogy a kapcsolat olvasási vagy olvasási/írási módban van-e. Ez a mezőből tekinthető meg a connections következőben AzureAudience: . A jogkivonat-hatókör engedélyei frissíthetők a kiszolgáló nélküli Azure-függvényben a generateToken függvény alatt.
const token = generateToken(
tenantId,
documentId,
key,
scopes ?? [ "Token Scope" ],
user
);
A token hatókörei, valamint a tároló viselkedése és módjai a következők:
| Jogkivonat hatóköre | Saját dokumentum viselkedése | Célközönség dokumentumának viselkedése |
|---|---|---|
| DocRead | Olvasás és írás a dokumentumba. A dokumentum módosításai nem jelennek meg más célközönségdokumentumokban. Mód: Olvasás |
Olvasás és írás a dokumentumba. A módosítások nem jelennek meg más célközönségdokumentumokban. Mód: Írás |
| DocWrite | Olvasás és írás a dokumentumba. A végrehajtott módosítások az összes többi célközönségdokumentumban is megjelennek. Mód: Írás |
Olvasás és írás a dokumentumba. A végrehajtott módosítások az összes többi célközönségdokumentumban is megjelennek. Mód: Írás |
| DocRead, DocWrite | Olvasás és írás a dokumentumba. A végrehajtott módosítások az összes többi célközönségdokumentumban is megjelennek. Mód: Írás |
Olvasás és írás a dokumentumba. A végrehajtott módosítások az összes többi célközönségdokumentumban is megjelennek. Mód: Írás |
Megjegyzés:
Vegye figyelembe, hogy a jogkivonat felhasználói adatokat is tartalmaz (lásd a fenti 7–9. sort). Ezzel bővítheti azokat a felhasználói adatokat, amelyek automatikusan elérhetővé válnak a Fluid Code számára a célközönség funkció használatával. További információ: Egyéni adatok hozzáadása jogkivonatokhoz .
A jogkivonat-szolgáltató
Az Azure Fluid Relay felé irányuló minden kérést érvényes JWT-vel kell aláírni. A Fluid delegálja a jogkivonatok létrehozásának és aláírásának felelősségét a jogkivonat-szolgáltatóknak.
A jogkivonat-szolgáltató feladata olyan jogkivonatok létrehozása és aláírása, amelyeket az @fluidframework/azure-client Azure Fluid Relay szolgáltatáshoz való kérésekhez használnak. Saját biztonságos jogkivonat-szolgáltatói implementációt kell biztosítania. A Fluid azonban olyan fájlt InsecureTokenProvider biztosít, amely elfogadja a bérlői titkos kulcsot, majd helyileg létrehoz és visszaad egy aláírt jogkivonatot. Ez a jogkivonat-szolgáltató teszteléshez hasznos, éles környezetben azonban nem használható.
Biztonságos kiszolgáló nélküli jogkivonat-szolgáltató
A biztonságos jogkivonat-szolgáltató létrehozásának egyik lehetősége egy kiszolgáló nélküli Azure-függvény létrehozása és jogkivonat-szolgáltatóként való elérhetővé tétele. Ez lehetővé teszi a bérlő titkos kulcsának biztonságos kiszolgálón való tárolását. Az alkalmazás ezután meghívja az Azure-függvényt, hogy hozzon létre jogkivonatokat ahelyett, hogy helyileg aláírná őket, ahogyan azt tenné InsecureTokenProvider . További információ : TokenProvider írása Azure-függvényekkel.
Csatlakozás felhasználói hitelesítést a Fluid service-hitelesítéshez
A Fluid Services megosztott ügyfélkód használatával hitelesíti a bejövő hívásokat, ami nem egy adott felhasználóhoz van kötve. A felhasználóhitelesítés a Fluid szolgáltatás adatai alapján adható hozzá.
A felhasználói hitelesítés egyik egyszerű lehetősége az lenne, ha egyszerűen egy Azure-függvényt használna jogkivonat-szolgáltatóként, és kényszerítené a felhasználói hitelesítést a jogkivonat beszerzésének feltételeként. Ha egy alkalmazás megpróbálja meghívni a függvényt, az sikertelen lenne, hacsak nem hitelesíti a hitelesítést a hitelesítési rendszerrel. Ha például Microsoft Entra-azonosítót használ, létrehozhat egy Microsoft Entra-alkalmazást az Azure-függvényhez, és összekapcsolhatja azt a szervezet hitelesítési rendszeréhez.
Ebben az esetben a felhasználó Microsoft Entra-azonosítóval jelentkezik be az alkalmazásba, amelyen keresztül lekért egy jogkivonatot az Azure-függvény meghívásához. Maga az Azure-függvény is ugyanúgy viselkedik, de most már csak azok számára érhető el, akik a Microsoft Entra-azonosítóval is hitelesítettek.
Mivel az Azure-függvény most már a belépési pontja egy érvényes jogkivonat beszerzésének, csak azok a felhasználók tudják majd ezt a jogkivonatot biztosítani az Azure Fluid Relay szolgáltatásnak az ügyfélalkalmazásukból, akik megfelelően hitelesítették a függvényt. Ez a kétlépéses megközelítés lehetővé teszi, hogy saját egyéni hitelesítési folyamatot használjon az Azure Fluid Relay szolgáltatással együtt.