DLA DZIAŁÓW IT

Active Directory Federation Services Single Sign-On

2 views 19 września 2016 28 sierpnia 2017 pawel-ostrowski 0

1. Instalacja ADFS 2.0 (jeśli Active Directory ma już tę usługę, ten krok pomijamy).

Przykładowy tutorial obejmujący także konfigurację maszyny wirtualnej i jej wszystkich potrzebnych składników: znajdziesz tu.

2. Konfiguracja Relying Party w ADFS. Kolejne kroki:

Otwarcie kreatora dodawania nowego Relying Party:

adfs_01

Wybieramy manualną konfigurację:

adfs_02

Jako nazwę podajemy np. nazwę adresu emplo (example-company.emplo.com):

adfs_03

Wybieramy opcję AD FS profile:

adfs_04

Jest to opcjonalne, ale zalecamy ustawienie certyfikatu służącego do szyfrowania zwracanych claims:

adfs_05

Wybieramy opcję Ws-Federation. Jako adres podajemy adres instancji emplo:

https://nazwa-instancji.emplo.com/identity
adfs_06

Jako identyfikatory, dodajemy:

https://nazwa-instancji.emplo.com
adfs_07

Pomijamy Multi-Factor authentication
adfs_08

Definiujemy, którzy użytkownicy AD, będą mogli logować się do emplo przez SSO:

adfs_09

Zaznaczając opcję Permit all users to access this relying party pozwalamy wszystkim użytkownikom na dostęp do systemu emplo. Użytkownik, który jeszcze nie istnieje w systemie emplo, zostanie dodany podczas pierwszego udanego logowania i trafi na formularz rejestracji.

Zamykamy kreator i przechodzimy do dodania reguł wysyłanych claims:

adfs_10

Dodajemy regułę na wysyłane claimsy (dane użytkownika, które zostaną przekazane do emplo po udanym zalogowaniu):

adfs_11

Uzupełniamy claimsy. Wymagane są jedynie 2 atrybuty: email i nameidentifier. Pozostałe, jeśli zostaną podane, będą użyte do automatycznego uzupełnienia danych użytkownika po pierwszym zalogowaniu:

adfs_12

Przykładowa konfiguracja wysyłająca oprócz pola email i nameidentifier zawiera także imię i nazwisko:

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”]

=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email”, “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/firstname”, “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/lastname”, “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”), query = “;mail,givenName,sn,userPrincipalName;{0}”, param = c.Value);

Uwaga: w powyższym przykładzie e-mail brany jest z pola General -> E-mail (atrybut mail) z użytkownika AD, jeśli to pole nie jest wypełnione w AD, a adresy e-mail używane są jako nazwa użytkownika, można użyć też atrybutu userPrincipalName.

Pełna lista atrybutów, która może być przesłana do emplo, znajduje się w dokumencie Atrybuty emplo możliwe do synchronizacji.

Po zakończeniu konfiguracji, należy przekazać zespołowi emplo adres metadanych publikowanych przez ADFS.

Jeśli został ustawiony certyfikat do szyfrowania zwracanych claims, będzie także konieczne przekazanie użytego certyfikatu wraz z kluczem prywatnym (w formacie *.pfx, wraz z hasłem wysłanym poufnym kanałem, np. przez SMS). Wymagany będzie także Thumbprint certyfikatu używanego do podpisywania tokenów. Poniżej zrzut ekranu prezentujący gdzie jest dostępna ta informacja (AD FS -> Service -> Certificates -> Token-signing -> View certificate -> Details -> Thumbprint).

adfs_13

Poprzedni Następny