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:
Wybieramy manualną konfigurację:
Jako nazwę podajemy np. nazwę adresu emplo (example-company.emplo.com):
Wybieramy opcję AD FS profile:
Jest to opcjonalne, ale zalecamy ustawienie certyfikatu służącego do szyfrowania zwracanych claims:
Wybieramy opcję Ws-Federation. Jako adres podajemy adres instancji emplo:
https://nazwa-instancji.emplo.com/identity
Jako identyfikatory, dodajemy:
https://nazwa-instancji.emplo.comPomijamy Multi-Factor authentication
Definiujemy, którzy użytkownicy AD, będą mogli logować się do emplo przez SSO:
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:
Dodajemy regułę na wysyłane claimsy (dane użytkownika, które zostaną przekazane do emplo po udanym zalogowaniu):
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:
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).
| Poprzedni | Następny |