Udostępnij za pośrednictwem

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

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: Wspieranie 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 rozbudowanych twierdzeń

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
Zbiór zestawów roszczeń i zero lub więcej właściwości. Wynik oceny co najmniej jednej zasady autoryzacji.

Roszczenie
Kombinacja typu oświadczenia, prawa i wartości.

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

Typ oświadczenia
Rodzaj roszczenia. Oświadczenia zdefiniowane przez Identity Model API są właściwościami klasy ClaimType. Przykłady typów oświadczeń dostarczonych przez system to Dns, Email, Hash, Name, Rsa, Sid, Spn, System, Thumbprint, Uri i X500DistinguishedName.

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

Oświadczenie tożsamości
Roszczenie, którego podstawą prawną jest tożsamość.

Wystawca
Zestaw roszczeń zawierający co najmniej jedno oświadczenie tożsamości i jest uznawany za taki, który wystawił inny zestaw roszczeń.

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.

Prawo
Możliwość nad zasobem. 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. Twierdzenia opisują możliwości związane z niektórymi jednostkami w systemie, często dotyczące 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ść. Roszczenia mają również typ roszczenia. 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 prawem "Odczyt" dla wartości "Biography.doc", wskazuje, że jednostka, z którą jest skojarzone oświadczenie, ma dostęp do odczytu do pliku Biography.doc. Oświadczenie typu "Nazwa", z prawem "PosiadanieWłaściwości" dla wartości "Martin", wskazuje, że jednostka, z którą jest skojarzone oświadczenie, posiada właściwość Nazwa 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 posiadające to prawo składają oświadczenie o tożsamości podmiotu. 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.

Deklaracja tożsamości systemu

Model tożsamości definiuje jedno oświadczenie tożsamości: System. Oświadczenie System tożsamości wskazuje, że obiekt 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 jako zestaw, a każdy zestaw ma wystawcę. Wystawca to tylko zestaw oświadczeń. Taka relacja rekursywna musi ostatecznie dobiec końca, a każdy zestaw oświadczeń może być swoim własnym wystawcą.

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

Zestawy roszczeń w hierarchii.

Wiele zestawów roszczeń może mieć ten sam zestaw roszczeń wystawiających, jak pokazano na poniższej ilustracji.

Wiele zestawów oświadczeń z tym samym zestawem oświadczeń wystawiających oświadczenia.

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 obsługuje zestawów oświadczeń z możliwością posiadania 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 roszczeń, takie jak system operacyjny, stos sieciowy, środowisko wykonawcze lub aplikacja. 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. Polityka autoryzacji sprawdza zestaw istniejących roszczeń, które mogą być puste, i może zdecydować się na dodanie dodatkowych roszczeń na podstawie już istniejących roszczeń i dodatkowych informacji do swojej dyspozycji. Stanowi to podstawę mapowania między roszczeniami. Obecność lub brak żądań w systemie wpływa na zachowanie polityki autoryzacji w zakresie tego, czy dodaje dodatkowe żądania.

Na przykład polityka autoryzacji ma dostęp do bazy danych zawierającej daty 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. Polityka autoryzacji, która dodała oświadczenie, rozumie tę semantykę na pewnym poziomie. Kod, który następnie analizuje roszczenia wynikające z oceny polisy, również jest informowany o tych semantykach.

Podana polityka autoryzacji może wymagać wielokrotnej oceny, ponieważ w miarę dodawania oświadczeń przez inne zasady autoryzacji, ta polityka może dodawać jeszcze więcej oświadczeń. Model tożsamości jest zaprojektowany tak, aby kontynuować ocenę, dopóki żadna z obowiązujących zasad autoryzacji nie doda więcej roszczeń do kontekstu. Ciągła ocena zasad autoryzacji zapobiega konieczności wymuszania określonej kolejności oceny w odniesieniu do zasad autoryzacji; można je ocenić w dowolnej kolejności. Na przykład, jeśli polisa X dodaje roszczenie Z tylko wtedy, gdy polisa A dodała roszczenie B, to jeśli X jest oceniana jako pierwsza, początkowo nie dodaje roszczenia Z. Następnie polisa A jest oceniana i dodaje roszczenie B. X jest następnie oceniana po raz drugi i tym razem dodaje roszczenie Z.

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

Maszyna Key-Making

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.

Zamki

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żania takich wymagań, lecz w oparciu o system bazujący na oświadczeniach, wymaga porównania oświadczeń w kontekście autoryzacji z określonym 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.

Zarządzanie oświadczeniami i autoryzacją xsi_recap

WCF i Model Tożsamości

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ą albo w przestrzeni nazw System.IdentityModel.Policy, albo w 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 polityki autoryzacji podczas oceny polityki.
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 albo System.IdentityModel.Claims przestrzeni nazw.

Klasa Opis
ServiceAuthorizationManager Klasa, która udostępnia metodę — CheckAccessCore, umożliwiającą sprawdzanie autoryzacji opartej na oświadczeniach dla każdej operacji w usłudze. Musisz pochodzić z klasy i zastąpić metodę .
ServiceAuthorizationBehavior Klasa o ograniczonym dostępie, która udostępnia różne właściwości związane z funkcjonowaniem usługi w kontekście autoryzacji.
ServiceSecurityContext Klasa, która zapewnia kontekst zabezpieczeń, w tym kontekst autoryzacji, dla obecnie wykonywanej operacji (lub takiej, która ma być uruchomiona). Wystąpienie tej klasy jest częścią klasy OperationContext.

Znaczący członkowie

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

Członek 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ć wszelkie informacje zawarte w podanym OperationContext elemencie lub w innym miejscu. Jeśli CheckAccessCore zwraca wartość true, dostęp zostaje udzielony i operacja może zostać uruchomiona. Jeśli CheckAccessCore zwraca false, to dostęp zostaje odrzucony, a operacja nie jest uruchamiana. 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. ServiceAuthorizationManager jest odpowiedzialny za podejmowanie decyzji dotyczących autoryzacji.
ExternalAuthorizationPolicies Kolekcja niestandardowych zasad autoryzacji określonych dla usługi. Te zasady są oceniane nie tylko osobno, ale także w powiązaniu z poświadczeniami w wiadomościach przychodzących.

Zobacz także