Udostępnij za pośrednictwem

Zarządzanie oświadczeniami i autoryzacją za pomocą modelu tożsamości

  • Artykuł

Autoryzacja to proces określania, które jednostki mają uprawnienia do zmiany, wyświetlania lub uzyskiwania dostępu do zasobu komputera. Na przykład w firmie tylko menedżerowie mogą mieć dostęp do plików swoich pracowników. Program Windows Communication Foundation (WCF) obsługuje dwa mechanizmy przetwarzania autoryzacji. Pierwszy mechanizm umożliwia kontrolowanie autoryzacji przy użyciu istniejących konstrukcji środowiska uruchomieniowego języka wspólnego (CLR). Drugi to model oparty na oświadczeniach nazywany modelem tożsamości. Program WCF używa modelu tożsamości do tworzenia oświadczeń z komunikatów przychodzących; Klasy modelu tożsamości można rozszerzyć w celu obsługi nowych typów oświadczeń dla niestandardowych schematów autoryzacji. W tym temacie przedstawiono omówienie głównych pojęć związanych z programowaniem funkcji Modelu tożsamości, a także listę najważniejszych klas używanych przez funkcję.

Scenariusze modelu tożsamości

Poniższe scenariusze reprezentują użycie modelu tożsamości.

Scenariusz 1. Obsługa oświadczeń tożsamości, roli i grupy

Użytkownicy wysyłają komunikaty do usługi sieci Web. Wymagania dotyczące kontroli dostępu usługi sieci Web używają tożsamości, ról lub grup. Nadawca wiadomości jest mapowany na zestaw ról lub grup. Informacje o rolach lub grupach służą do przeprowadzania kontroli dostępu.

Scenariusz 2. Obsługa zaawansowanych oświadczeń

Użytkownicy wysyłają komunikaty do usługi sieci Web. Wymagania dotyczące kontroli dostępu usługi sieci Web wymagają bogatszego modelu niż tożsamość, role lub grupy. Usługa sieci Web określa, czy dany użytkownik ma dostęp do określonego chronionego zasobu przy użyciu zaawansowanego modelu opartego na oświadczeniach. Na przykład jeden użytkownik może mieć możliwość odczytania określonych informacji, takich jak informacje o wynagrodzeniach, do których inni użytkownicy nie mają dostępu.

Scenariusz 3. Mapowanie różnych oświadczeń

Użytkownik wysyła wiadomość do usługi sieci Web. Użytkownik może określić swoje poświadczenia na wiele różnych sposobów: certyfikat X.509, token nazwy użytkownika lub token protokołu Kerberos. Usługa sieci Web jest wymagana do przeprowadzania kontroli dostępu w taki sam sposób, niezależnie od typu poświadczeń użytkownika. Jeśli dodatkowe typy poświadczeń są obsługiwane w miarę upływu czasu, system powinien odpowiednio ewoluować.

Scenariusz 4. Określanie dostępu do wielu zasobów

Usługa sieci Web próbuje uzyskać dostęp do wielu zasobów. Usługa określa, do których chronionych zasobów dany użytkownik ma dostęp, porównując oświadczenia skojarzone z użytkownikiem z oświadczeniami wymaganymi do uzyskania dostępu do zasobu.

Terminy modelu tożsamości

Poniższa lista definiuje kluczowe terminy używane do opisywania koncepcji modelu tożsamości.

Zasady autoryzacji
Zestaw reguł mapowania zestawu oświadczeń wejściowych na zestaw oświadczeń wyjściowych. Ocena zasad autoryzacji powoduje dodanie zestawów oświadczeń do kontekstu oceny, a następnie kontekstu autoryzacji.

Kontekst autoryzacji
Zestaw zestawów oświadczeń i zero lub więcej właściwości. Wynik oceny co najmniej jednej zasady autoryzacji.

Oświadczenie
Kombinacja typu oświadczenia, prawa i wartości.

Zestaw oświadczeń
Zestaw oświadczeń wystawionych przez określonego wystawcę.

Typ oświadczenia
Rodzaj roszczenia. Oświadczenia zdefiniowane przez interfejs API modelu tożsamości to właściwości ClaimType klasy . Przykłady typów oświadczeń dostarczonych przez system to Dns, , HashRsaSidNameEmailSystemThumbprintSpnUrii .X500DistinguishedName

Kontekst oceny
Kontekst, w którym są oceniane zasady autoryzacji. Zawiera właściwości i zestawy oświadczeń. Staje się podstawą kontekstu autoryzacji po zakończeniu oceny.

Oświadczenie tożsamości
Roszczenie, którego prawo jest tożsamością.

Wystawca
Zestaw oświadczeń zawierający co najmniej jedno oświadczenie tożsamości i jest uznawany za wystawiony inny zestaw oświadczeń.

Właściwości
Zestaw informacji skojarzonych z kontekstem oceny lub kontekstem autoryzacji.

Zasób chroniony
Coś w systemie, którego można używać, uzyskiwać dostęp lub manipulować w inny sposób, jeśli zostały spełnione określone wymagania.

Right
Możliwość zasób. Prawa zdefiniowane przez interfejs API modelu tożsamości to właściwości Rights klasy . Przykłady praw udostępnionych przez system to Identity i PossessProperty.

Wartość
Coś, czego dotyczy prawo.

Roszczenia

Model tożsamości to system oparty na oświadczeniach. Oświadczenia opisują możliwości skojarzone z niektórymi jednostkami w systemie, często użytkownika tego systemu. Zestaw oświadczeń skojarzonych z daną jednostką można traktować jako klucz. Określone oświadczenia definiują kształt tego klucza, podobnie jak klucz fizyczny używany do otwierania blokady w drzwiach. Oświadczenia służą do uzyskiwania dostępu do zasobów. Dostęp do danego chronionego zasobu jest określany przez porównanie oświadczeń potrzebnych do uzyskania dostępu do tego zasobu z oświadczeniami skojarzonymi z jednostką próbującą uzyskać dostęp.

Roszczenie jest wyrażeniem prawa w odniesieniu do określonej wartości. Prawo może być podobne do "Odczyt", "Zapis" lub "Wykonaj". Wartością może być baza danych, plik, skrzynka pocztowa lub właściwość. Oświadczenia mają również typ oświadczenia. Kombinacja typu oświadczenia i prawa zapewnia mechanizm określania możliwości w odniesieniu do wartości. Na przykład oświadczenie typu "Plik", z prawej "Odczyt" dla wartości "Biography.doc", wskazuje, że jednostka, z którą jest skojarzone oświadczenie, ma dostęp do odczytu do Biography.doc pliku. Oświadczenie typu "Name", z prawem "PossessProperty" nad wartością "Martin", wskazuje, że jednostka, z którą jest skojarzone oświadczenie, posiada właściwość Name o wartości "Martin".

Mimo że różne typy oświadczeń i prawa są definiowane jako część modelu tożsamości, system jest rozszerzalny, umożliwiając różne systemy, opierając się na infrastrukturze modelu tożsamości, w celu zdefiniowania dodatkowych typów oświadczeń i praw zgodnie z potrzebami.

Oświadczenia tożsamości

Jednym szczególnym prawem jest tożsamość. Roszczenia, które posiadają to prawo, składają oświadczenie o tożsamości jednostki. Na przykład oświadczenie typu "główna nazwa użytkownika" (UPN) z wartością someone@example.com i prawem Identity wskazuje określoną tożsamość w określonej domenie.

Oświadczenie tożsamości systemu

Model tożsamości definiuje jedno oświadczenie tożsamości: System. Oświadczenie System tożsamości wskazuje, że jednostka jest bieżącą aplikacją lub systemem.

Zestawy oświadczeń

Model oświadczeń reprezentujących tożsamość jest ważny, ponieważ oświadczenia są zawsze wydawane przez jakąś jednostkę w systemie, nawet jeśli ta jednostka jest ostatecznie pojęciem "siebie". Oświadczenia są grupowane razem jako zestaw, a każdy zestaw ma wystawcę. Wystawca jest tylko zestawem oświadczeń. Taka relacja rekursywna musi ostatecznie zakończyć się, a każdy zestaw oświadczeń może być jego własnym wystawcą.

Na poniższej ilustracji przedstawiono przykład trzech zestawów oświadczeń, w których jeden zestaw oświadczeń ma jako wystawcę inny zestaw oświadczeń, który z kolei ma zestaw oświadczeń systemowych ustawiony jako jego wystawca. W związku z tym zestawy oświadczeń tworzą hierarchię, która może być dowolnie głęboka.

Sets of claims within the hierarchy.

Wiele zestawów oświadczeń może mieć ten sam zestaw oświadczeń wystawiających, jak pokazano na poniższej ilustracji:

Multiple sets of claims with the same issuing claim set.

Z wyjątkiem zestawu oświadczeń, który jest własnym wystawcą, model tożsamości nie zapewnia żadnej obsługi zestawów oświadczeń w celu utworzenia pętli. W związku z tym sytuacja, w której zestaw roszczeń A jest wystawiany przez zestaw roszczeń B, który sam jest wystawiony przez zestaw oświadczeń A, nigdy nie może powstać. Ponadto model tożsamości nie zapewnia żadnej obsługi zestawów oświadczeń, aby mieć wielu wystawców. Jeśli co najmniej dwa wystawcy muszą wydać określony zestaw oświadczeń, należy użyć wielu zestawów oświadczeń, z których każdy zawiera te same oświadczenia, ale ma różnych wystawców.

Pochodzenie oświadczeń

Oświadczenia mogą pochodzić z różnych źródeł. Jednym z typowych źródeł oświadczeń są poświadczenia prezentowane przez użytkownika, na przykład jako część komunikatu wysyłanego do usługi sieci Web. System weryfikuje takie oświadczenia i staje się częścią zestawu oświadczeń skojarzonych z użytkownikiem. Inne składniki systemu mogą być również źródłami oświadczeń, w tym, ale nie tylko, systemem operacyjnym, stosem sieciowym, środowiskiem czasu wykonywania lub aplikacją. Ponadto usługi zdalne mogą być również źródłem oświadczeń.

Zasady autoryzacji

W modelu tożsamości oświadczenia są generowane w ramach procesu oceny zasad autoryzacji. Zasady autoryzacji sprawdzają (prawdopodobnie pusty) zestaw istniejących oświadczeń i mogą zdecydować się na dodanie dodatkowych oświadczeń na podstawie już obecnych oświadczeń i dodatkowych informacji do jego dyspozycji. Zapewnia to podstawę mapowania między oświadczeniami. Obecność lub brak oświadczeń w systemie wpływa na zachowanie zasad autoryzacji w odniesieniu do tego, czy dodaje dodatkowe oświadczenia.

Na przykład zasady autoryzacji mają dostęp do bazy danych zawierającej dane urodzenia różnych jednostek korzystających z systemu. Zasady autoryzacji używają tych informacji do dodania oświadczenia "Over18" do kontekstu. Należy pamiętać, że roszczenie over18 nie ujawnia żadnych informacji o jednostce innej niż fakt, że jest w wieku powyżej 18 lat. Należy pamiętać, że interpretacja roszczenia "Over18" zależy od zrozumienia semantyki tego roszczenia. Zasady autoryzacji, które dodały oświadczenie, rozumieją te semantyki na pewnym poziomie. Kod, który następnie analizuje oświadczenia, które wynikają z oceny zasad, również są informowany o tych semantyce.

Podane zasady autoryzacji mogą wymagać wielokrotnej oceny, ponieważ w miarę dodawania oświadczeń przez inne zasady autoryzacji zasady autoryzacji mogą dodawać jeszcze więcej oświadczeń. Model tożsamości jest przeznaczony do kontynuowania oceny do momentu dodania kolejnych oświadczeń do kontekstu przez dowolne z obowiązujących zasad autoryzacji. Ciągła ocena zasad autoryzacji uniemożliwia wymuszanie dowolnego konkretnego zamówienia oceny w odniesieniu do zasad autoryzacji; można je ocenić w dowolnej kolejności. Jeśli na przykład zasady X dodaje tylko oświadczenie Z, jeśli zasady A dodały oświadczenie B, to jeśli X jest oceniane jako pierwsze, początkowo nie dodaje oświadczenia Z. Następnie element A jest oceniany i dodaje oświadczenie B. X jest następnie oceniane po raz drugi, a tym razem dodaje oświadczenie Z.

W danym systemie może obowiązywać wiele zasad autoryzacji.

Maszyna do tworzenia kluczy

Ocena grupy skojarzonych zasad autoryzacji przypomina używanie maszyny, która tworzy klucze. Zasady autoryzacji są oceniane, a zestawy oświadczeń są generowane, tworząc kształt klucza. Po zakończeniu kształtu klucza można go użyć do próby otwarcia niektórych blokad. Kształt klucza jest przechowywany w "kontekście autoryzacji", który jest tworzony przez menedżera autoryzacji.

Kontekst autoryzacji

Menedżer autoryzacji ocenia różne zasady autoryzacji zgodnie z opisem, a wynikiem jest kontekst autoryzacji (zestaw zestawów oświadczeń i niektóre skojarzone właściwości). Kontekst autoryzacji można zbadać, aby określić, jakie oświadczenia znajdują się w tym kontekście, relacje między tymi różnymi oświadczeniami (na przykład zestawem oświadczeń wystawiających), a ostatecznie porównać je z pewnymi wymaganiami, które muszą spełnić, aby uzyskać dostęp do zasobu.

Blokady

Jeśli kontekst autoryzacji (zestaw oświadczeń) jest kluczem, wymagania, które muszą być spełnione, aby udzielić dostępu do określonego chronionego zasobu, stanowią blokadę, którą musi zmieścić klucz. Model tożsamości nie formalizuje sposobu wyrażenia takich wymagań, ale mają one charakter oparty na oświadczeniach systemu, obejmują porównanie oświadczeń w kontekście autoryzacji z niektórym zestawem wymaganych oświadczeń.

Podsumowanie

Model tożsamości opiera się na koncepcji oświadczeń. Oświadczenia są grupowane w zestawy i agregowane w kontekście autoryzacji. Kontekst autoryzacji zawiera zestaw oświadczeń i jest wynikiem oceny co najmniej jednej zasady autoryzacji skojarzonej z menedżerem autoryzacji. Te zestawy oświadczeń można zbadać, aby określić, czy zostały spełnione wymagania dostępu. Na poniższej ilustracji przedstawiono relacje między tymi różnymi pojęciami dotyczącymi modelu tożsamości.

Managing claims and authorization

Model WCF i Identity

WCF używa infrastruktury modelu tożsamości jako podstawy do wykonywania autoryzacji. W programie WCF ServiceAuthorizationBehavior klasa umożliwia określenie zasad autoryzacji w ramach usługi. Takie zasady autoryzacji są nazywane zasadami autoryzacji zewnętrznej i mogą wykonywać przetwarzanie oświadczeń na podstawie zasad lokalnych lub interakcji z usługą zdalną. Menedżer autoryzacji reprezentowany przez ServiceAuthorizationManager klasę ocenia zewnętrzne zasady autoryzacji wraz z zasadami autoryzacji, które rozpoznają różne typy poświadczeń (tokeny) i wypełnia kontekst autoryzacji z oświadczeniami odpowiednimi dla komunikatu przychodzącego. Kontekst autoryzacji jest reprezentowany przez klasę AuthorizationContext .

Programowanie modelu tożsamości

W poniższej tabeli opisano model obiektów używany do programowania rozszerzeń modelu tożsamości. Wszystkie te klasy istnieją w System.IdentityModel.Policy przestrzeniach nazw lub System.IdentityModel.Claims .

Klasa opis
Składnik autoryzacji Klasa Modelu tożsamości, która implementuje IAuthorizationComponent interfejs.
IAuthorizationComponent Interfejs, który udostępnia pojedynczą właściwość ciągu tylko do odczytu: Id. Wartość tej właściwości jest unikatowa dla każdego wystąpienia w systemie, który implementuje ten interfejs.
AuthorizationContext Składnik autoryzacji zawierający zestaw wystąpień o zerowej ClaimSet lub większej liczbie właściwości; wynik oceny co najmniej jednej zasady autoryzacji.
Claim Kombinacja typu oświadczenia, prawa i wartości. Części prawej i wartości są ograniczone przez typ oświadczenia.
ClaimSet Abstrakcyjna klasa bazowa. Kolekcja Claim wystąpień.
DefaultClaimSet Zapieczętowana klasa. Implementacja ClaimSet klasy .
EvaluationContext Abstrakcyjna klasa bazowa. Przekazano do zasad autoryzacji podczas oceny zasad.
IAuthorizationPolicy Interfejs pochodzący z IAuthorizationComponent i zaimplementowany przez klasy zasad autoryzacji.
Rights Klasa statyczna zawierająca wstępnie zdefiniowane prawidłowe wartości.

Następujące klasy są również używane do programowania modelu tożsamości, ale nie znajdują się w System.IdentityModel.Policy przestrzeniach nazw lub System.IdentityModel.Claims .

Klasa opis
ServiceAuthorizationManager Klasa, która udostępnia metodę — CheckAccessCoredo przeprowadzania kontroli autoryzacji opartej na oświadczeniach dla każdej operacji w usłudze. Musisz pochodzić z klasy i zastąpić metodę .
ServiceAuthorizationBehavior Zapieczętowana klasa, która udostępnia różne właściwości związane z zachowaniem usługi w odniesieniu do autoryzacji.
ServiceSecurityContext Klasa, która zapewnia kontekst zabezpieczeń, w tym kontekst autoryzacji, dla aktualnie uruchomionej operacji (lub o uruchomieniu). Wystąpienie tej klasy jest częścią klasy OperationContext.

Znaczące elementy członkowskie

Następujące elementy członkowskie są często używane do tworzenia nowych typów oświadczeń.

Element członkowski opis
CheckAccessCore Klasy pochodne implementują tę metodę w celu przeprowadzania kontroli dostępu na podstawie oświadczeń przed uruchomieniem operacji w usłudze. Podczas podejmowania decyzji o kontroli dostępu można zbadać wszystkie informacje podane w podanym OperationContextelemecie lub w innym miejscu. Jeśli CheckAccessCore zwraca truewartość , zostanie udzielony dostęp, a operacja może zostać uruchomiona. Jeśli CheckAccessCore funkcja zwraca falsewartość , dostęp zostanie odrzucony, a operacja nie zostanie uruchomiona. Przykład można znaleźć w temacie How to: Create a Custom Authorization Manager for a Service (Instrukcje: tworzenie niestandardowego menedżera autoryzacji dla usługi).
ServiceAuthorizationManager Zwraca wartość ServiceAuthorizationManager dla usługi. Jest ServiceAuthorizationManager odpowiedzialny za podejmowanie decyzji dotyczących autoryzacji.
ExternalAuthorizationPolicies Kolekcja niestandardowych zasad autoryzacji określonych dla usługi. Te zasady są oceniane oprócz tych zasad skojarzonych z poświadczeniami w komunikatach przychodzących.

Zobacz też