Autentisering och auktorisering i din app

Artikel
10/24/2023

Säkerhet är viktigt för moderna webbprogram. Fluid Framework, som en del av din webbprogramarkitektur, är en viktig del av infrastrukturen för att skydda. Fluid Framework är en arkitektur i flera lager och autentiseringsrelaterade begrepp implementeras baserat på den Fluid-tjänst som den ansluter till. Det innebär att även om det finns vanliga autentiseringsteman för alla Fluid-tjänster skiljer sig informationen och detaljerna åt för varje tjänst.

Azure Fluid Relay-tjänsten

Varje Azure Fluid Relay-tjänstklient som du skapar tilldelas ett klient-ID och en egen unik klienthemlighetsnyckel.

Den hemliga nyckeln är en delad hemlighet. Din app/tjänst känner till det och Tjänsten Azure Fluid Relay vet det. Eftersom klienthemlighetsnyckeln är unikt kopplad till din klientorganisation använder du den för att signera begärandegarantier till Azure Fluid Relay-tjänsten att begäranden kommer från en auktoriserad användare av klientorganisationen.

Den hemliga nyckeln är hur Azure Fluid Relay-tjänsten vet att begäranden kommer från din app eller tjänst. Detta är viktigt eftersom när Azure Fluid Relay-tjänsten kan lita på att det är din app som gör begäranden kan den lita på de data du skickar. Därför är det också viktigt att hemligheten hanteras på ett säkert sätt.

Varning

Alla som har åtkomst till hemligheten kan personifiera ditt program när de kommunicerar med Azure Fluid Relay-tjänsten.

JSON-webbtoken och Azure Fluid Relay-tjänsten

Azure Fluid Relay använder JSON-webbtoken (JWT) för att koda och verifiera data som signerats med din hemliga nyckel. JSON-webbtoken är en signerad JSON-bit som kan innehålla ytterligare information om rättigheter och behörigheter.

Kommentar

Detaljerna i JWT:er ligger utanför den här artikelns omfång. Mer information om JWT-standarden finns i Introduktion till JSON-webbtoken.

Även om autentiseringsinformationen skiljer sig åt mellan Fluid-tjänster måste flera värden alltid finnas.

containerId Fluid-tjänsten behöver container-ID:t för att identifiera vilken tjänst som motsvarar den anropande containern. Obs! JWT anropar det här fältet documentId, men fluidtjänsten förväntar sig ett container-ID i det här fältet.
tenantId: Azure Fluid Relay-tjänsten använder klient-ID:t för att hämta den delade hemlighet som används för att autentisera din begäran.
omfång: Omfång definierar den anropande containerns behörigheter. Innehållet i omfångsfältet är flexibelt, så att du kan skapa egna anpassade behörigheter.

{
  "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]

Användarens läge anger om anslutningen är i läs- eller läs-/skrivläge. Detta kan visas från fältet connections i AzureAudience. Behörigheter för tokenomfång kan uppdateras i din serverlösa Azure-funktion under generateToken funktionen.

const token = generateToken(
  tenantId,
  documentId,
  key,
  scopes ?? [ "Token Scope" ],
  user
);

Tokenomfången tillsammans med containerns beteende och lägen är följande:

Tokenomfång	Mitt dokumentbeteende	Beteende för målgruppsdokument
DocRead	Läs och skriv till dokumentet. Ändringar som gjorts i dokumentet återspeglas inte i något annat målgruppsdokument. Läge: Läs	Läsa och skriva till dokument. Ändringarna återspeglas inte i något annat målgruppsdokument. Läge: Skriv
DocWrite	Läs och skriv till dokumentet. Ändringar som görs återspeglas i alla andra målgruppsdokument. Läge: Skriv	Läs och skriv till dokumentet. Ändringar som görs återspeglas i alla andra målgruppsdokument. Läge: Skriv
DocRead, DocWrite	Läs och skriv till dokumentet. Ändringar som görs återspeglas i alla andra målgruppsdokument. Läge: Skriv	Läs och skriv till dokumentet. Ändringar som görs återspeglas i alla andra målgruppsdokument. Läge: Skriv

Kommentar

Observera att token även innehåller användarinformation (se raderna 7–9 ovan). Du kan använda detta för att utöka användarinformationen som automatiskt är tillgänglig för Fluid-kod med hjälp av målgruppsfunktionen. Mer information finns i Lägga till anpassade data i token .

Tokenprovidern

Varje begäran till Azure Fluid Relay måste signeras med en giltig JWT. Fluid delegerar ansvaret för att skapa och signera dessa token till tokenprovidrar.

En tokenprovider ansvarar för att skapa och signera token som @fluidframework/azure-client används för att göra begäranden till Azure Fluid Relay-tjänsten. Du måste tillhandahålla en egen implementering av en säker tokenprovider. Fluid tillhandahåller dock en InsecureTokenProvider som accepterar din klienthemlighet och sedan lokalt genererar och returnerar en signerad token. Den här tokenprovidern är användbar för testning, men kan inte användas i produktionsscenarier.

En säker serverlös tokenprovider

Ett alternativ för att skapa en säker tokenprovider är att skapa en serverlös Azure-funktion och exponera den som en tokenprovider. På så sätt kan du lagra klienthemlighetsnyckeln på en säker server. Ditt program anropar sedan Azure-funktionen för att generera token i stället för att signera dem lokalt som det InsecureTokenProvider gör. Mer information finns i Så här skriver du en TokenProvider med en Azure-funktion.

Anslut användarautentisering till Fluid Service-autentisering

Fluid Services autentiserar inkommande samtal med hjälp av en delad klienthemlighet som inte är kopplad till en specifik användare. Användarautentisering kan läggas till baserat på information om din Fluid-tjänst.

Ett enkelt alternativ för användarautentisering är att helt enkelt använda en Azure-funktion som din tokenprovider och framtvinga användarautentisering som ett villkor för att hämta en token. Om ett program försöker anropa funktionen misslyckas det om det inte autentiseras med ditt autentiseringssystem. Om du till exempel använder Microsoft Entra-ID kan du skapa ett Microsoft Entra-program för din Azure-funktion och koppla det till organisationens autentiseringssystem.

I det här fallet skulle användaren logga in på ditt program med hjälp av Microsoft Entra-ID, genom vilket du skulle få en token att använda för att anropa din Azure-funktion. Själva Azure-funktionen fungerar på samma sätt, men den är nu endast tillgänglig för personer som också har autentiserats med Microsoft Entra-ID.

Eftersom Azure-funktionen nu är startpunkten för att hämta en giltig token kan endast användare som har autentiserats korrekt till funktionen tillhandahålla den token till Azure Fluid Relay-tjänsten från klientprogrammet. Med den här tvåstegsmetoden kan du använda din egen anpassade autentiseringsprocess tillsammans med Azure Fluid Relay-tjänsten.

Share via