Verificatie en autorisatie in uw app

Artikel
10/24/2023

Beveiliging is essentieel voor moderne webtoepassingen. Vloeiend Framework is, als onderdeel van uw webtoepassingsarchitectuur, een belangrijk onderdeel van de infrastructuur om te beveiligen. Vloeiend Framework is een gelaagde architectuur en verificatieconcepten worden geïmplementeerd op basis van de Fluid-service waarmee deze verbinding maakt. Dit betekent dat, hoewel er algemene verificatiethema's voor alle Fluid-services zijn, de details en details voor elke service verschillen.

Azure Fluid Relay-service

Aan elke Azure Fluid Relay-servicetenant die u maakt, wordt een tenant-id en een eigen unieke tenantgeheimsleutel toegewezen.

De geheime sleutel is een gedeeld geheim. Uw app/service kent deze en de Azure Fluid Relay-service kent deze. Omdat de tenantgeheimsleutel uniek is gekoppeld aan uw tenant, gebruikt u deze om aanvragen te ondertekenen bij de Azure Fluid Relay-service dat de aanvragen afkomstig zijn van een geautoriseerde gebruiker van de tenant.

De geheime sleutel is hoe de Azure Fluid Relay-service weet dat aanvragen afkomstig zijn van uw app of service. Dit is essentieel, omdat zodra de Azure Fluid Relay-service kan vertrouwen dat het uw app is die de aanvragen doet, de gegevens die u verzendt, kan vertrouwen. Daarom is het ook belangrijk dat het geheim veilig wordt afgehandeld.

Let op

Iedereen met toegang tot het geheim kan uw toepassing imiteren wanneer deze communiceert met de Azure Fluid Relay-service.

JSON-webtokens en Azure Fluid Relay-service

Azure Fluid Relay maakt gebruik van JSON-webtokens (JWTs) om gegevens te coderen en te verifiëren die zijn ondertekend met uw geheime sleutel. JSON-webtokens zijn een ondertekende bit van JSON die aanvullende informatie over rechten en machtigingen kan bevatten.

Notitie

De specifieke kenmerken van JWT's vallen buiten het bereik van dit artikel. Zie Inleiding tot JSON-webtokens voor meer informatie over de JWT-standaard.

Hoewel de details van verificatie verschillen tussen Fluid-services, moeten er altijd verschillende waarden aanwezig zijn.

containerId The Fluid-service heeft de container-id nodig om te bepalen welke service overeenkomt met de aanroepende container. Opmerking: JWT roept deze velddocumentid aan, maar de Fluid-service verwacht een container-id in dit veld.
tenantId: De Azure Fluid Relay-service gebruikt de tenant-id om het gedeelde geheim op te halen dat wordt gebruikt om uw aanvraag te verifiëren.
bereiken: Bereiken definiëren de machtigingen van de aanroepende container. De inhoud van het bereikveld is flexibel, zodat u uw eigen aangepaste machtigingen kunt maken.

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

De modus van de gebruiker geeft aan of de verbinding zich in de lees- of lees-/schrijfmodus bevindt. Dit kan worden weergegeven vanuit het connections veld in AzureAudience. De tokenbereikmachtigingen kunnen worden bijgewerkt in uw serverloze Azure-functie onder de generateToken functie.

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

De tokenbereiken samen met het gedrag en de modi van de container zijn als volgt:

Tokenbereik	Mijn documentgedrag	Gedrag van doelgroepdocument
DocRead	Lezen en schrijven naar het document. Wijzigingen die in het document zijn aangebracht, worden niet doorgevoerd in een ander publieksdocument. Modus: Lezen	Lezen en schrijven naar document. Wijzigingen worden niet doorgevoerd in een ander publieksdocument. Modus: Schrijven
DocWrite	Lezen en schrijven naar het document. Wijzigingen die zijn aangebracht, worden doorgevoerd in alle andere doelgroepdocument. Modus: Schrijven	Lezen en schrijven naar het document. Wijzigingen die zijn aangebracht, worden doorgevoerd in alle andere doelgroepdocument. Modus: Schrijven
DocRead, DocWrite	Lezen en schrijven naar het document. Wijzigingen die zijn aangebracht, worden doorgevoerd in alle andere doelgroepdocument. Modus: Schrijven	Lezen en schrijven naar het document. Wijzigingen die zijn aangebracht, worden doorgevoerd in alle andere doelgroepdocument. Modus: Schrijven

Notitie

Het token bevat ook gebruikersgegevens (zie regels 7-9 hierboven). U kunt deze gebruiken om de gebruikersgegevens te verbeteren die automatisch beschikbaar zijn voor Fluid-code met behulp van de doelgroepfunctie . Zie Aangepaste gegevens toevoegen aan tokens voor meer informatie.

De tokenprovider

Elke aanvraag bij Azure Fluid Relay moet zijn ondertekend met een geldige JWT. Fluid delegeert de verantwoordelijkheid voor het maken en ondertekenen van deze tokens tokenproviders.

Een tokenprovider is verantwoordelijk voor het maken en ondertekenen van tokens die worden gebruikt voor het @fluidframework/azure-client indienen van aanvragen bij de Azure Fluid Relay-service. U moet uw eigen implementatie van uw beveiligde tokenprovider opgeven. Fluid biedt echter een InsecureTokenProvider bestand dat uw tenantgeheim accepteert en vervolgens lokaal een ondertekend token genereert en retourneert. Deze tokenprovider is handig voor het testen, maar kan niet worden gebruikt in productiescenario's.

Een beveiligde serverloze tokenprovider

Een optie voor het bouwen van een beveiligde tokenprovider is het maken van een serverloze Azure-functie en deze beschikbaar te maken als een tokenprovider. Hiermee kunt u de geheime sleutel van de tenant opslaan op een beveiligde server. Uw toepassing roept vervolgens de Azure-functie aan om tokens te genereren in plaats van ze lokaal te ondertekenen, zoals dat InsecureTokenProvider wel het geval is. Zie Instructies voor meer informatie: Een TokenProvider schrijven met een Azure-functie.

Verbinding maken van gebruikersverificatie naar Fluid-serviceverificatie

Fluid Services verifiëren binnenkomende oproepen met behulp van een gedeeld clientgeheim, dat niet is gekoppeld aan een specifieke gebruiker. Gebruikersverificatie kan worden toegevoegd op basis van de details van uw Fluid-service.

Een eenvoudige optie voor gebruikersverificatie is om gewoon een Azure-functie te gebruiken als uw tokenprovider en gebruikersverificatie af te dwingen als voorwaarde voor het verkrijgen van een token. Als een toepassing de functie probeert aan te roepen, mislukt deze, tenzij deze is geverifieerd met uw verificatiesysteem. Als u bijvoorbeeld Microsoft Entra-id gebruikt, kunt u een Microsoft Entra-toepassing voor uw Azure-functie maken en deze koppelen aan het verificatiesysteem van uw organisatie.

In dit geval zou de gebruiker zich aanmelden bij uw toepassing met behulp van Microsoft Entra ID, waarmee u een token zou verkrijgen om uw Azure-functie aan te roepen. De Azure-functie zelf gedraagt zich hetzelfde, maar is nu alleen toegankelijk voor personen die ook zijn geverifieerd met Microsoft Entra-id.

Omdat de Azure-functie nu het ingangspunt is om een geldig token te verkrijgen, kunnen alleen gebruikers die correct zijn geverifieerd bij de functie, dat token aan de Azure Fluid Relay-service verstrekken vanuit hun clienttoepassing. Met deze tweestapsbenadering kunt u uw eigen aangepaste verificatieproces gebruiken in combinatie met de Azure Fluid Relay-service.

Delen via