Oświadczenia zawierają informacje dotyczące użytkowników (takie jak nazwa, tożsamość, klucz, grupa, przywilej lub możliwości) zrozumiałe dla obu partnerów w federacji usług Active Directory Federation Services (AD FS). Służą one do autoryzacji w aplikacji.

Usługa federacyjna programu AD FS przekazuje informacje dotyczące zaufania między różnymi jednostkami. Umożliwia ona wymianę oświadczeń zawierających dowolne wartości z zachowaniem relacji zaufania. Na podstawie tych oświadczeń są podejmowane decyzje związane z autoryzacją po stronie odbierającej dane (np. partnera zasobów).

Oświadczenia mogą być przekazywane za pośrednictwem usługi federacyjnej na trzy sposoby:

  • Z magazynu kont do usługi federacyjnej kont, a następnie do partnera zasobów.

  • Od partnera kont do usługi federacyjnej zasobów, a następnie do aplikacji zasobów.

  • Z magazynu kont do usługi federacyjnej, a następnie do aplikacji zasobów.

Usługę federacyjną można skonfigurować do działania we wszystkich trzech wymienionych rolach. Pojedyncza usługa federacyjna może zatem ułatwiać przekazywanie oświadczeń na wszystkie trzy sposoby.

Usługa federacyjna obsługuje trzy typy oświadczeń: oświadczenia tożsamości, oświadczenia grupy i oświadczenia niestandardowe. Poniższa tabela zawiera szczegółowy opis wymienionych typów oświadczeń.

Typ oświadczenia Opis

Tożsamość

W programie AD FS główna nazwa użytkownika, adres e-mail i nazwa pospolita są nazywane typami oświadczeń tożsamości:

  • Główna nazwa użytkownika: wskazuje główną nazwę użytkownika (UPN) w formacie protokołu Kerberos, na przykład: uzytkownik@obszar. Może istnieć tylko jedno oświadczenie typu nazwa UPN. Nawet w przypadku przesyłania wielu wartości UPN tylko jedna z nich może należeć do typu nazwa UPN. Dodatkowe nazwy UPN można skonfigurować jako niestandardowe typy oświadczeń.

  • E-mail: wskazuje nazwy e-mail w formacie RFC 2822 (uzytkownik@domena). Może istnieć tylko jedno oświadczenie typu adres e-mail. Nawet w przypadku przesyłania wielu wartości adresu e-mail tylko jedna z nich może należeć do typu adres e-mail. Dodatkowe adresy e-mail można skonfigurować jako niestandardowe typy oświadczeń.

  • Nazwa pospolita: zawiera dowolny ciąg identyfikujący użytkownika. Przykłady: Tomasz Bator, pracownik firmy Tailspin Toys. Może istnieć tylko jedno oświadczenie typu nazwa pospolita. Należy pamiętać, że nie można zagwarantować unikatowości oświadczenia nazwy pospolitej. Należy zatem ostrożnie używać tego typu oświadczenia przy podejmowaniu decyzji związanych z autoryzacją.

Grupa

Wskazuje członkostwo w grupie lub rolę. Administratorzy mogą definiować oddzielne oświadczenia należące do grupy typu „Oświadczenia grupy”. Można na przykład zdefiniować następujący zestaw oświadczeń grupy: [deweloper, tester, menedżer programu]. Każde oświadczenie grupy jest oddzielną jednostką administracyjną, która umożliwia wypełnianie oświadczeń i ich mapowanie. Można wyobrazić sobie wartość oświadczenia grupy jako wartość logiczną, która wskazuje członkostwo.

Niestandardowe

Wskazuje, że oświadczenie zawiera niestandardowe informacje dotyczące użytkownika, na przykład numer identyfikacyjny pracownika.

Jeśli token zawiera więcej niż jeden spośród trzech wymienionych typów oświadczeń, priorytety są przyznawane oświadczeniom tożsamości w następującej kolejności:

  1. Główna nazwa użytkownika

  2. Adres e-mail

  3. Nazwa pospolita

Aby token został wystawiony, musi być dostępne co najmniej jedno oświadczenie tożsamości należące do jednego z powyższych typów.

Mapowanie oświadczeń

Usługi AD FS używają protokołu profilu pasywnego obiektu żądającego usług federacyjnych w sieci Web (WS-F PRP), który umożliwia przekazywanie oświadczeń w tokenach zabezpieczających wystawianych przez usługę federacyjną. Oświadczenia są początkowo wypełniane przy użyciu magazynów kont usług domenowych w usłudze Active Directory (AD DS, Active Directory Domain Services) lub usług LDS w usłudze Active Directory (AD LDS, Active Directory Lightweight Directory Services).

Usługa federacyjna pozwala na mapowanie oświadczeń, które są przekazywane partnerowi federacyjnemu lub otrzymywane od partnera federacyjnego. Mapowanie oświadczeń polega na mapowaniu, usuwaniu lub filtrowaniu oświadczeń przychodzących lub przekazywaniu ich do oświadczeń wychodzących. Mapowanie oświadczeń może być różne dla poszczególnych partnerów federacyjnych. Określenie sposobu wypełniania i mapowania tych oświadczeń jest ważnym elementem konfiguracji usługi federacyjnej. Mapowanie oświadczeń porównuje ciągi z uwzględnieniem wielkości liter. Następująca ilustracja przedstawia proces mapowania oświadczeń.

Proces mapowania oświadczenia

Zestawy oświadczeń organizacji

Wszystkie oświadczenia przychodzące są mapowane na oświadczenia organizacji. Oświadczenia organizacji są oświadczeniami w formie pośredniej lub znormalizowanej w obszarze nazw organizacji. Wszystkie wewnętrzne akcje usługi federacyjnej są przeprowadzane na zestawie oświadczeń organizacji. Oświadczenia organizacji są używane przez aplikacje zasobów.

Zastosowanie oświadczeń organizacji powoduje, że nie ma potrzeby indywidualnego administrowania mapowaniami między każdą parą organizacji, które mają się komunikować ze sobą. Dla każdej organizacji jest definiowane jedno mapowanie na oświadczenia organizacji lub z oświadczeń organizacji. Upraszcza to administrację programem AD FS. Jeśli na przykład federacja ma:

x partnerów kont

y aplikacji zasobów

to taka federacja ma x + y mapowań oświadczeń.

Oznacza to mniejszą wartość niż potencjalna liczba x × y mapowań oświadczeń. W konkretnym przykładzie, jeśli usługa federacyjna ma:

3 partnerów kont

7 aplikacji zasobów

Federacja potrzebuje tylko 10 mapowań oświadczeń w porównaniu z 21 mapowaniami oświadczeń, które byłyby wymagane w przypadku mapowania bezpośrednio z oświadczeń przychodzących na oświadczenia wychodzące.

Poczta e-mail

Oświadczenia adresu e-mail są zawsze mapowane na oświadczenia adresu e-mail. W ramach tego mapowania w usłudze federacyjnej konta sufiks domeny może być mapowany na wartość stałą. Mapowanie sufiksu domeny na wartość stałą chroni organizację partnera przed nieumyślnym udostępnianiem informacji dotyczących wewnętrznej struktury lasu dla innej organizacji. W usłudze federacyjnej zasobów sufiks domeny może być filtrowany na podstawie listy wartości stałych.

W poniższym przykładzie przedstawiono federację AD FS między dwiema organizacjami: Tailspin Toys i Adventure Works. W tym przykładzie organizacja Tailspin Toys jest partnerem kont, a organizacja Adventure Works - partnerem zasobów.

  • Organizacja Tailspin Toys, działająca jako usługa federacyjna kont, mapuje oświadczenie adresu e-mail organizacji na wychodzące oświadczenie adresu e-mail dla organizacji Adventure Works. W ramach tego mapowania wszystkie sufiksy adresów e-mail są mapowane do postaci tailspintoys.com. Dla oświadczenia adresu e-mail organizacji (e-mail=jsmith@sales.tailspintoys.com) wychodzące oświadczenie adresu e-mail ma postać (e-mail=jsmith@tailspintoys.com).

  • Organizacja Adventure Works, działająca jako usługa federacyjna zasobów, mapuje przychodzące z organizacji Tailspin Toys oświadczenie adresu e-mail na oświadczenie adresu e-mail organizacji i w ramach tego mapowania filtruje listę sufiksów względem domeny tailspintoys.com. Dlatego przychodzące z organizacji Tailspin Toys oświadczenie adresu e-mail (e-mail=jsmith@tailspintoys.com) zostanie przyjęte, ale przychodzące z organizacji Tailspin Toys oświadczenie adresu e-mail (e-mail=jsmith@adventure-works.com) zostanie odrzucone.

Główna nazwa użytkownika

Oświadczenia głównej nazwy użytkownika są zawsze mapowane na oświadczenia głównej nazwy użytkownika. Podlegają one mapowaniu i filtrowaniu sufiksów w takim sam sposób jak oświadczenia adresu e-mail. Jednak ponieważ w usługach AD DS jest możliwe użycie głównej nazwy użytkownika bez znaku @, usługa federacyjna kont dołącza znak @ z następującym po nim sufiksem, o ile zdefiniowano sufiks mapowania głównej nazwy użytkownika. Jeśli natomiast jest przekazywany dowolny sufiks, usługa federacyjna przekazuje nazwę główną nazwę użytkownika bez zmian, czyli bez znaku @. Po stronie zasobów, jeśli jest dozwolony dowolny sufiks głównej nazwy użytkownika, to główna nazwa użytkownika bez znaku @ jest akceptowana. Jeśli natomiast jest dozwolony określony sufiks głównej nazwy użytkownika, to główna nazwa użytkownika bez znaku @ jest odrzucana.

Nazwa pospolita

Oświadczenia nazwy pospolitej są zawsze mapowane na oświadczenia nazwy pospolitej. Nie podlegają one żadnym dodatkowym regułom.

Niestandardowe

Oświadczenia niestandardowe są zawsze mapowane na oświadczenia niestandardowe. Na przykład dla zestawu oświadczeń przychodzących (UPN, Custom=[NumerPracownika, NIP]) oraz zestawu oświadczeń organizacji (UPN, Custom=[Pracownik, PESEL]) można utworzyć mapowania elementów NumerPracownika na Pracownik oraz NIP na PESEL.

Grupa

Oświadczenia grupy są zawsze mapowane na oświadczenia grupy. Na przykład dla zestawu oświadczeń przychodzących (UPN, Group=[Jeden, Dwa, Trzy]) oraz zestawu oświadczeń organizacji (UPN, Group=[X,Y,Z]) można utworzyć mapowania elementów Jeden na Y, Dwa na X i Trzy na Z.

Mapowanie oświadczeń grupy na oświadczenia głównej nazwy użytkownika

Oprócz standardowych mapowań opisanych w poprzednich sekcjach można użyć specjalnego typu mapowania oświadczenia grupy na oświadczenie głównej nazwy użytkownika. Mapowanie oświadczeń grupy na oświadczenia głównej nazwy użytkownika jest obsługiwane wyłącznie w usłudze federacyjnej zasobów, gdy oświadczenia pochodzą od partnera kont. W takim przypadku oświadczenia głównej nazwy użytkownika nie są mapowane na oświadczenia głównej nazwy użytkownika. Zamiast tego należy podać uporządkowaną listę mapowań oświadczeń głównej nazwy użytkownika.

Lista mapowań oświadczeń grupy na oświadczenia głównej nazwy użytkownika może wyglądać następująco:

  1. Dew na deweloperzy@internal.tailspintoys.com

  2. Test na testerzy@internal.tailspintoys.com

  3. MP na menedzerowie_programu@internal.tailspintoys.com

Dla zestawu oświadczeń przychodzących (Common name=Jan Kowalski, Group=[Dew]) zestaw oświadczeń organizacji zawiera (Common name=Jan Kowalski, UPN=deweloperzy@internal.tailspintoys.com). Należy pamiętać, że lista jest uporządkowana. Dlatego dla zestawu oświadczeń (Common name=Jan Kowalski, Group=[Dew,MP]) jest otrzymywany wynik (Common name=Jan Kowalski, UPN=deweloperzy@internal.tailspintoys.com). Ponadto jeśli oświadczenie przychodzące zawiera główną nazwę użytkownika, jest ona zastępowana. Ta specjalna reguła mapowania obsługuje określone konta zasobów oparte na grupach, które mają dostęp do starszych zasobów. Kolejność mapowań grupy na główną nazwę użytkownika jest określona w zasadach zaufania usługi federacyjnej.

Przeprowadzanie inspekcji oświadczeń

Niektóre oświadczenia grupy i oświadczenia niestandardowe można oznaczyć jako podlegające inspekcji. Po włączeniu inspekcji nazwa oświadczenia będzie widoczna w dzienniku zdarzeń zabezpieczeń, ale jego wartość zostanie pominięta. Przykładem oświadczenia, które można poddać inspekcji, jest numer PESEL. Nazwa oświadczenia PESEL będzie widoczna, natomiast wartość liczbowa przechowywana w tym oświadczeniu nie będzie dostępna. Wartość oświadczenia nie będzie poddawana inspekcji po utworzeniu lub zamapowaniu oświadczenia.

Uwaga

Każdy typ oświadczenia tożsamości można poddać inspekcji.

Zobacz też

Spis treści