Autoryzacja SAML i kontrola dostępu

Instrukcja i metodologia definiowania polityki dostępu oraz zarządzania protokołem SAML w organizacji.

Protokół SAML pozwala organizacjom zarządzać uwierzytelnianiem i prawami dostępu użytkowników Tulip przy użyciu istniejącego dostawcy tożsamości (IdP). Niniejszy przewodnik szczegółowo opisuje dostępne opcje wdrożenia integracji z dostawcą tożsamości na poziomie przedsiębiorstwa za pośrednictwem protokołu SAML.

Przygotowanie

• Zapoznaj się z rolami użytkowników Tulip
• Podziel przewidywanych użytkowników Tulip według ról, abyś był gotowy do aktualizacji atrybutu SAML o ich rolę w Tulip
• Określ, kto w Twojej organizacji będzie konfigurował IdP i konto Tulip

Konfiguracja IdP

Gdy instancja Tulip jest skonfigurowana do korzystania z SAML do logowania, Tulip utrzymuje powiązanie między użytkownikami w Tulip a użytkownikami w korporacyjnym dostawcy tożsamości (IdP). Dany użytkownik posiadający konto w IdP powinien mieć co najwyżej jedno konto w danej instancji Tulip. Tulip utrzymuje to powiązanie za pomocą specyficznej dla SAML koncepcji zwanej „NameID”. NameID to nieprzejrzysty typ identyfikatora zapewniany przez uwierzytelnianie SAML i definiowany przez IdP.

Ponieważ do utrzymania tego powiązania wykorzystywany jest NameID, Tulip oczekuje, że identyfikatory NameID będą stabilne, co oznacza, że NameID otrzymywany przez Tulip dla konkretnego użytkownika IdP nie powinien ulegać zmianie w całym okresie aktywności tego użytkownika. Jeśli NameID użytkownika ulegnie zmianie, powiązanie zostanie zerwane i mogą wystąpić błędy podczas logowania.

Tulip zdecydowanie zaleca skonfigurowanie dostawcy tożsamości (IdP) tak, aby dostarczał identyfikator NameID, który nie ulegnie zmianie w przyszłości. Z tego powodu Tulip odradza stosowanie nazw lub adresów e-mail jako identyfikatorów NameID, ponieważ wartości te mogą ulec zmianie z upływem czasu. Zalecamy skonfigurowanie dostawcy tożsamości (IdP) tak, aby wykorzystywał wewnętrzne identyfikatory obiektów lub nazwy kont, co do których istnieje gwarancja, że nigdy się nie zmienią.

Należy pamiętać, że identyfikatory NameID nie muszą być czytelne dla człowieka ani rozpoznawalne (w rzeczywistości z punktu widzenia bezpieczeństwa zazwyczaj lepiej jest używać nierozpoznawalnych wartości jako identyfikatorów NameID).

Podczas konfiguracji dostawcy tożsamości (IdP) zalecamy ustawienie formatu identyfikatora NameID na „Persistent”, co wskazuje platformie Tulip, że wartość ta powinna pozostać stała przez cały okres aktywności użytkownika.

Podczas mapowania wartości źródłowej atrybutu NameID należy przypisać ją do wartości, o której wiadomo, że jest niezmienna, takiej jak „identyfikator obiektu” lub „nazwa podmiotu użytkownika”.

Microsoft Entra

Klienci korzystający z Microsoft Entra jako dostawcy tożsamości (IdP) powinni postępować zgodnie z poniższymi instrukcjami, aby skonfigurować aplikację Tulip do korzystania z trwałych identyfikatorów NameID:

1. W Entra zacznij od aplikacji korporacyjnej powiązanej z instancją Tulip.
2. W lewym menu nawigacyjnym kliknij „Single sign-on” w grupie „Manage”.
3. Edytuj sekcję „Attributes & Claims”.
4. W sekcji „Wymagane oświadczenia” kliknij wiersz oświadczenia o nazwie „Unikalny identyfikator użytkownika (Name ID)”.
5. Upewnij się, że opcja „Format identyfikatora nazwy” jest ustawiona na „Trwały”. Ustaw opcję „Źródło” na „Atrybut” i wybierz atrybut, który pozostanie niezmienny przez cały okres aktywności użytkownika. Dobrym wyborem są atrybuty user.userprincipalname i user.objectid.

Opcje konfiguracyjne SAML i Tulip

Tryby kontroli

Tryb kontroli Tulip oznacza, że rola użytkownika w Tulip oraz jego obszar roboczy są pobierane z mapowania atrybutów SAML tylko przy pierwszym logowaniu do Tulip.

Użytkownicy dezaktywowani w Tulip nie mogą się zalogować.

Tryb kontroli IdP oznacza, że rola użytkownika w Tulip oraz jego obszar roboczy będą aktualizowane z IdP przy każdym logowaniu.

Domyślne mapowanie ról (tylko w trybie kontroli Tulip)

Przy pierwszym logowaniu wszyscy użytkownicy otrzymują domyślny poziom dostępu (Viewer z dostępem do odtwarzacza). Właściciel konta będzie następnie musiał ręcznie dostosować rolę do odpowiedniego poziomu w systemie Tulip.

Obszary robocze

Dowiedz się więcej o obszarach roboczych

Podobnie jak w przypadku atrybutu roli, użytkownik ma teraz możliwość automatycznego przypisania użytkowników do konkretnego obszaru roboczego podczas ich pierwszego tworzenia. Po utworzeniu użytkownika właściciele kont mogą elastycznie przenosić użytkowników między obszarami roboczymi.

Niestandardowe przypisywanie obszarów roboczych w SAML

:::(Informacja) (Wiele obszarów roboczych)
Należy pamiętać, że przypisywanie użytkowników do wielu obszarów roboczych jest możliwe wyłącznie w trybie kontroli dostawcy tożsamości ( Tulip ).

W trybie kontroli IdP każdy użytkownik może być członkiem tylko jednego obszaru roboczego.
:::

Przy pierwszym logowaniu użytkownikowi przypisywany jest dostęp do obszaru roboczego na podstawie grupy podanej w atrybucie obszaru roboczego. Od tego momentu Tulip nie odczytuje już atrybutu obszaru roboczego tego użytkownika, a wszelkie zmiany dotyczące obszaru roboczego muszą być dokonywane na platformie przez właściciela konta.

Domyślne mapowanie obszarów roboczych

Przy pierwszym logowaniu wszyscy użytkownicy otrzymują dostęp do wybranego przez Ciebie domyślnego obszaru roboczego. Właściciel konta może następnie dostosować dostęp do obszaru roboczego.

Grupy użytkowników

We wszystkich konfiguracjach SAML można przypisywać użytkowników do funkcji grup użytkowników{target=_blank} w Tulip.

Grupy użytkowników istnieją na poziomie konta. Gdy użytkownik zostanie przypisany do grupy użytkowników, będzie członkiem tej grupy we wszystkich obszarach roboczych.

Po włączeniu opcji „Grupy użytkowników” będzie można przypisywać użytkowników z dostawcy tożsamości (IdP) do grup użytkowników w Tulip na podstawie wartości atrybutu w SAML.

Następnie można nadać nazwy maksymalnie 100 atrybutom SAML i przypisać wartości każdego z nich do grupy użytkowników. Użytkownik może być przypisany do wielu grup użytkowników.

Mapowanie grup użytkowników a zachowanie trybu kontroli

Działanie członkostwa w grupach użytkowników zależy od ustawienia trybu kontroli.

• Tryb kontroli Tulip: Grupy przypisane użytkownikowi za pomocą SAML są stosowane tylko przy pierwszym logowaniu. Następnie członkostwem w grupach można zarządzać w Tulip, a wszelkie ręczne zmiany są zachowywane przy kolejnych logowaniach.
• Tryb kontroli IdP: Pełne członkostwo użytkownika w grupach jest przeliczane na podstawie jego aktualnych atrybutów SAML przy każdym logowaniu. Tulip przypisuje użytkownika do grup wynikających z mapowania oraz usuwa go z grup nieobjętych mapowaniem, w tym z grup przypisanych ręcznie w Tulip.

Opcje uwierzytelniania

Jeśli chcesz używać kluczy FIDO do uwierzytelniania użytkowników, musisz „Wyłączyć dopasowywanie metod uwierzytelniania”.

Klasa kontekstu uwierzytelniania

Klasa kontekstu uwierzytelniania to określona metoda, za pomocą której użytkownicy się uwierzytelniają.

Po włączeniu tej opcji użytkownicy będą mogli uwierzytelniać się wyłącznie przy użyciu określonej metody.

Gdy opcja jest wyłączona, wybór metody uwierzytelniania zostanie całkowicie przekazany dostawcy tożsamości.

Wymuszanie uwierzytelniania

Tulip wykorzystuje parametr SAML forceAuthn do kontrolowania, czy użytkownicy muszą ponownie uwierzytelniać się u swojego dostawcy tożsamości przy każdym logowaniu, czy też można ponownie wykorzystać istniejącą sesję SAML na poziomie systemu operacyjnego. Tulip nie korzysta z parametru isPassive. W tym przypadku istniejącą sesją jest sesja SAML na poziomie systemu operacyjnego (np. sesja Windows powiązana z dostawcą tożsamości), a nie sesja specyficzna dla Tulipa.

Wymuszanie uwierzytelniania WŁĄCZONE (domyślnie): Tulip wysyła forceAuthn=true, wymagając od użytkownika aktywnego uwierzytelniania się u dostawcy tożsamości przy każdym logowaniu, niezależnie od istnienia jakiejkolwiek sesji SAML na poziomie systemu operacyjnego. To ustawienie gwarantuje, że użytkownicy nie mogą ominąć ponownego uwierzytelniania.

Wymuszanie uwierzytelniania WYŁĄCZONE: Tulip wysyła parametr forceAuthn=false. Jeśli użytkownik ma już aktywną sesję SAML na poziomie systemu operacyjnego rozpoznawaną przez dostawcę tożsamości (IdP), zostanie automatycznie zalogowany do Tulip bez konieczności ponownego wprowadzania danych uwierzytelniających.

Dostosowanie

Opcjonalne dostosowanie logowania użytkownika.

Etykieta przycisku logowania — dostosuj tekst na przycisku logowania SAML na stronach logowania do Tulip.

Niestandardowy adres e-mail pomocy technicznej — ustaw niestandardowy adres e-mail, który będzie wyświetlany użytkownikom w przypadku wystąpienia błędu logowania SAML. Może on kierować użytkowników do wewnętrznego działu pomocy technicznej IT. Jeśli pole pozostanie puste, zostanie użyty domyślny adres e-mail pomocy technicznej „support@tulip.co”.

Odtwarzacz na komputerze stacjonarnym: domyślna przeglądarka systemu operacyjnego do uwierzytelniania

Jeśli logowanie SSO lub autoryzacja za pomocą łącznika OAuth wymaga integracji dostępnej wyłącznie za pośrednictwem domyślnej przeglądarki, odtwarzacz Tulip można skonfigurować tak, aby procesy uwierzytelniania otwierały się w domyślnej przeglądarce systemu operacyjnego, a nie w oknie osadzonym.

Wymagania dotyczące wersji

Aby korzystać z uwierzytelniania w domyślnej przeglądarce systemu operacyjnego, należy spełnić następujące wymagania dotyczące wersji Tulip:* Odtwarzacz desktopowy 2.8 lub nowszy* Wersja Factory 318 lub nowsza

Działanie funkcji

To zachowanie dotyczy zarówno logowania się do odtwarzacza na komputerze stacjonarnym za pomocą SSO, jak i autoryzacji łączników OAuth w aplikacjach Tulip. W obu przypadkach, gdy użytkownik zainicjuje uwierzytelnianie, otwiera się domyślna przeglądarka systemowa, aby obsłużyć następujący proces:

1. Przeglądarka systemowa uruchamia się i przechodzi do strony logowania dostawcy tożsamości (IdP) Twojej organizacji.
2. Użytkownik dokonuje logowania (wprowadzając dane uwierzytelniające, przechodząc przez uwierzytelnianie wieloskładnikowe (MFA) itp.) w przeglądarce dokładnie tak, jak zrobiłby to w sieci.
3. Po zakończeniu uwierzytelniania na stronie przeglądarki wyświetla się następujący komunikat: „Gotowe! Możesz zamknąć to okno”.
4. Okno przeglądarki pozostaje otwarte. Nie jest zamykane automatycznie. Użytkownik powinien zamknąć je ręcznie.
5. Aplikacja Tulip Desktop Player wykrywa zakończone logowanie i kontynuuje działanie w normalny sposób.

Przewidywane monity o uprawnienia

W zależności od systemu operacyjnego i konfiguracji przeglądarki użytkownicy mogą napotkać jeden lub dwa monity o uprawnienia:

1. Uprawnienia Desktop Playera dotyczące zapory sieciowej / serwera lokalnego (na poziomie systemu operacyjnego)

Po rozpoczęciu procesu uwierzytelniania program Desktop Player tworzy tymczasowy serwer lokalny w celu odebrania odpowiedzi uwierzytelniającej. W zależności od systemu operacyjnego i ustawień zabezpieczeń może pojawić się komunikat zapory systemowej lub monit o dostęp do sieci z pytaniem, czy program Desktop Player może akceptować połączenia przychodzące.

• Wymagane działanie: Zezwól na połączenie. Jest to oczekiwane zachowanie i jest wymagane do zakończenia logowania.
• W zależności od ustawień systemu operacyjnego monit ten może pojawić się tylko przy pierwszym uruchomieniu lub za każdym razem.

2. Uprawnienia przeglądarki do dostępu do sieci lokalnej (na poziomie przeglądarki)

Po zakończeniu logowania przez użytkownika za pośrednictwem dostawcy tożsamości strona potwierdzająca uwierzytelnienie w przeglądarce wysyła wynik z powrotem do odtwarzacza Desktop Player, wysyłając żądanie do lokalnego serwera opisanego powyżej. Niektóre przeglądarki wyświetlają monit z pytaniem, czy strona może uzyskać dostęp do urządzeń w sieci lokalnej.

• Wymagane działanie: Zezwól na dostęp. Jest to bezpieczny, oczekiwany etap procesu uwierzytelniania.
• Żądanie jest kierowane wyłącznie do localhost i zawiera wyłącznie zaszyfrowaną odpowiedź uwierzytelniającą. Na tym etapie nie są przesyłane żadne poufne dane uwierzytelniające.

Podsumowanie różnic widocznych dla użytkownika

Poniższa tabela porównuje zachowanie uwierzytelniania domyślnego i uwierzytelniania za pomocą przeglądarki w systemie operacyjnym:

Przykład: Tworzenie grup dostępu w ramach dostawcy tożsamości (IdP)

Poniższy przykład pomoże Ci zrozumieć, w jaki sposób można łączyć ze sobą różne opcje w ustawieniach SAML.

Tworzenie standardowych ról w Tulip

Każdy użytkownik musi mieć atrybut roli określony w systemie IdP, aby Tulip mógł określić jego uprawnienia po uwierzytelnieniu za pomocą nazwy użytkownika i hasła z IdP.

Możesz również użyć tego pola „Rola” do określenia, do jakich witryn użytkownik ma dostęp, stosując standardową konwencję nazewniczą. Chociaż pole „Rola” może być po prostu zmienną ustawioną, zaleca się przypisanie użytkownika do grup specyficznych dla Tulip w ramach IdP i zmapowanie ich do atrybutu.

Rola

Każdemu użytkownikowi zostanie przypisana jedna rola w jednym obszarze roboczym.

Gdy Tulip otrzyma wiele prawidłowych ról dla danego użytkownika, stosuje następującą logikę:

Jeśli zestaw zawiera jakiekolwiek wbudowane role (Operator, Builder itp.), Tulip wybiera wbudowaną rolę o najwyższym rankingu w oparciu o statyczną hierarchię wewnętrzną. Role niestandardowe są zawsze klasyfikowane poniżej wszystkich wbudowanych ról, więc nigdy nie zostaną wybrane, jeśli obecna jest jakakolwiek wbudowana rola.

Jeśli zestaw zawiera wyłącznie role niestandardowe, Tulip wybiera pierwszą rolę niestandardową otrzymaną w ładunku SAML.

Dowiedz się więcej o rolach użytkowników w Tulip.

Witryna

Załóżmy, że Twoja organizacja ma dwie lokalizacje, z których każda ma własną domenę Tulip Instance.

Każdą lokalizację możemy oznaczyć jej nazwą (odpowiednio: Teksas i Londyn).

Łączenie lokalizacji i roli

Możemy połączyć te dwie właściwości, aby utworzyć macierz grup, do których będą przypisywani użytkownicy. Zalecamy, aby organizacje dodawały przed lub po wartości słowo „Tulip”, co ułatwi filtrowanie.

Konwencja: tulip-siteRole

Jeśli Jane Smith jest kierownikiem oddziału w Teksasie, należy przypisać ją do grupy tulip-texasAccountOwner. Jeśli Jane Smith potrzebuje również uprawnień do przeglądania danych w oddziale w Londynie, można ją dodać do grupy tulip-londonViewer.

Ujawnij te grupy jako atrybut dla Tulip

W Twoim dostawcy tożsamości (IdP) Jane powinna posiadać atrybut „tulip-role”, do którego będą mapowane wszystkie grupy, których jest członkiem i które zawierają prefiks „tulip-”.

Kiedy loguje się do Tulip, atrybut „tulip-role” ma dwie wartości: „tulip-texasAccountOwner” i „tulip-londonViewer”. Można indywidualnie skonfigurować mapowanie ról dla każdego serwisu Tulip instance, tak aby w każdej instancji otrzymywała odpowiednie uprawnienia.

Role globalne

Można również utworzyć globalne role dostępu, na przykład rolę „Viewer”. Użytkownicy ci będą mogli logować się do każdej instancji Tulip instance z tymi samymi uprawnieniami. Zalecany format dla tego celu to:

tulip-globalViewer

Aby umożliwić temu użytkownikowi dostęp do każdej instancji, należy skonfigurować to mapowanie ról w każdej instancji z osobna na stronie konfiguracji SAML w ustawieniach konta.

{{snippet.Czy znalazłeś to, czego szukałeś?}}