Uwierzytelnianie i autoryzacja w aplikacji
Zabezpieczenia mają kluczowe znaczenie dla nowoczesnych aplikacji internetowych. Elastyczna struktura w ramach architektury aplikacji internetowej jest ważnym elementem infrastruktury do zabezpieczenia. Elastyczna struktura jest architekturą warstwową, a koncepcje związane z uwierzytelnianiem są implementowane na podstawie usługi Fluid, z którymi nawiązuje połączenie. Oznacza to, że chociaż istnieją wspólne motywy uwierzytelniania we wszystkich usługach Fluid, szczegóły i szczegóły będą się różnić dla każdej usługi.
Usługa Azure Fluid Relay
Każda utworzona dzierżawa usługi Azure Fluid Relay ma przypisany identyfikator dzierżawy i własny unikatowy klucz tajny dzierżawy.
Klucz tajny jest wspólnym kluczem tajnym. Twoja aplikacja/usługa go zna, a usługa Azure Fluid Relay ją zna. Ponieważ klucz tajny dzierżawy jest jednoznacznie powiązany z dzierżawą, użyj go do podpisywania żądań gwarancji do usługi Azure Fluid Relay, że żądania pochodzą od autoryzowanego użytkownika dzierżawy.
Klucz tajny to sposób, w jaki usługa Azure Fluid Relay wie, że żądania pochodzą z aplikacji lub usługi. Jest to krytyczne, ponieważ gdy usługa Azure Fluid Relay może ufać, że aplikacja wysyła żądania, może ufać wysyłanym danym. Dlatego ważne jest również, aby wpis tajny był bezpiecznie obsługiwany.
Uwaga
Każda osoba mająca dostęp do wpisu tajnego może personifikować aplikację podczas komunikowania się z usługą Azure Fluid Relay.
Tokeny internetowe JSON i usługa Azure Fluid Relay
Usługa Azure Fluid Relay używa tokenów internetowych JSON (JWTs) do kodowania i weryfikowania danych podpisanych przy użyciu klucza tajnego. Tokeny internetowe JSON to podpisany bit JSON, który może zawierać dodatkowe informacje o prawach i uprawnieniach.
Uwaga
Specyfika zestawów JWTs wykracza poza zakres tego artykułu. Aby uzyskać więcej informacji na temat standardu JWT, zobacz Wprowadzenie do tokenów sieci Web JSON.
Chociaż szczegóły uwierzytelniania różnią się między usługami Fluid, zawsze musi być obecnych kilka wartości.
- containerId Usługa Fluid wymaga identyfikatora kontenera, aby zidentyfikować, która usługa odpowiada kontenerowi wywołującego. Uwaga: JWT wywołuje to pole documentId, ale usługa Fluid oczekuje identyfikatora kontenera w tym polu.
- tenantId: usługa Azure Fluid Relay używa identyfikatora dzierżawy do pobrania udostępnionego wpisu tajnego, który będzie używany do uwierzytelniania żądania.
- zakresy: zakresy definiują uprawnienia wywołującego kontenera. Zawartość pola zakresów jest elastyczna, umożliwiając tworzenie własnych uprawnień niestandardowych.
{
"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]
Tryb użytkownika wskazuje, czy połączenie jest w trybie odczytu lub odczytu/zapisu. Można to wyświetlić z connections pola w pliku AzureAudience. Uprawnienia zakresu tokenu można zaktualizować w funkcji platformy Azure bezserwerowej w ramach generateToken funkcji .
const token = generateToken(
tenantId,
documentId,
key,
scopes ?? [ "Token Scope" ],
user
);
Zakresy tokenu wraz z zachowaniem i trybami kontenera są następujące:
| Zakres tokenu | Zachowanie dokumentu | Zachowanie dokumentu odbiorców |
|---|---|---|
| Dokument | Odczyt i zapis w dokumencie. Zmiany wprowadzone w dokumencie nie są odzwierciedlane w żadnym innym dokumencie odbiorców. Tryb: Odczyt |
Odczytywanie i zapisywanie w dokumencie. Zmiany nie zostały odzwierciedlone w innym dokumencie odbiorców. Tryb: zapis |
| DocWrite | Odczyt i zapis w dokumencie. Zmiany wprowadzone są odzwierciedlane we wszystkich innych dokumentach odbiorców. Tryb: zapis |
Odczyt i zapis w dokumencie. Zmiany wprowadzone są odzwierciedlane we wszystkich innych dokumentach odbiorców. Tryb: zapis |
| DocRead, DocWrite | Odczyt i zapis w dokumencie. Zmiany wprowadzone są odzwierciedlane we wszystkich innych dokumentach odbiorców. Tryb: zapis |
Odczyt i zapis w dokumencie. Zmiany wprowadzone są odzwierciedlane we wszystkich innych dokumentach odbiorców. Tryb: zapis |
Uwaga
Należy pamiętać, że token zawiera również informacje o użytkowniku (zobacz wiersze 7–9 powyżej). Można jej użyć do rozszerzania informacji o użytkowniku, które są automatycznie dostępne dla kodu Fluid przy użyciu funkcji odbiorców . Aby uzyskać więcej informacji, zobacz Dodawanie danych niestandardowych do tokenów .
Dostawca tokenu
Każde żądanie do usługi Azure Fluid Relay musi być podpisane przy użyciu prawidłowego zestawu JWT. Płyn deleguje odpowiedzialność za tworzenie i podpisywanie tych tokenów dostawcom tokenów.
Dostawca tokenu jest odpowiedzialny za tworzenie i podpisywanie tokenów używanych @fluidframework/azure-client do wprowadzania żądań do usługi Azure Fluid Relay. Musisz zapewnić własną implementację dostawcy bezpiecznego tokenu. Jednak fluid udostępnia element InsecureTokenProvider , który akceptuje klucz tajny dzierżawy, a następnie lokalnie generuje i zwraca podpisany token. Ten dostawca tokenów jest przydatny do testowania, ale nie może być używany w scenariuszach produkcyjnych.
Bezpieczny dostawca tokenów bezserwerowych
Jedną z opcji tworzenia bezpiecznego dostawcy tokenów jest utworzenie bezserwerowej funkcji platformy Azure i uwidocznienie jej jako dostawcy tokenów. Dzięki temu można przechowywać klucz tajny dzierżawy na bezpiecznym serwerze. Następnie aplikacja wywoła funkcję platformy Azure, aby wygenerować tokeny zamiast podpisywać je lokalnie, tak jak w przypadku tej InsecureTokenProvider funkcji. Aby uzyskać więcej informacji, zobacz Jak napisać tokenProvider za pomocą funkcji platformy Azure.
Połączenie uwierzytelnianie użytkownika w usłudze Fluid Service
Usługi fluidu uwierzytelniają połączenia przychodzące przy użyciu udostępnionego klucza tajnego klienta, który nie jest powiązany z określonym użytkownikiem. Uwierzytelnianie użytkownika można dodać na podstawie szczegółów usługi Fluid.
Jedną z prostych opcji uwierzytelniania użytkowników byłoby użycie funkcji platformy Azure jako dostawcy tokenów i wymuszenie uwierzytelniania użytkownika jako warunku uzyskania tokenu. Jeśli aplikacja spróbuje wywołać funkcję, nie powiedzie się, chyba że uwierzytelniony w systemie uwierzytelniania. Jeśli na przykład używasz identyfikatora Entra firmy Microsoft, możesz utworzyć aplikację Microsoft Entra dla funkcji platformy Azure i powiązać ją z systemem uwierzytelniania organizacji.
W takim przypadku użytkownik zaloguje się do aplikacji przy użyciu identyfikatora Microsoft Entra ID, za pomocą którego uzyskasz token do użycia w celu wywołania funkcji platformy Azure. Sama funkcja platformy Azure zachowuje się tak samo, ale jest teraz dostępna tylko dla osób, które również uwierzytelniły się za pomocą identyfikatora Entra firmy Microsoft.
Ponieważ funkcja platformy Azure jest teraz punktem wejścia w uzyskiwanie prawidłowego tokenu, tylko użytkownicy, którzy prawidłowo uwierzytelnili się w funkcji, będą mogli podać ten token do usługi Azure Fluid Relay z poziomu aplikacji klienckiej. To dwuetapowe podejście umożliwia korzystanie z własnego niestandardowego procesu uwierzytelniania w połączeniu z usługą Azure Fluid Relay.