Autoryzacja i kontrola dostępu przy użyciu SAML
  • 23 Sep 2022
  • 5 Minuty do przeczytania
  • Współtwórcy

Autoryzacja i kontrola dostępu przy użyciu SAML


Cel

Instrukcja i metodologia definiowania polityki dostępu i zarządzania SAML dla Twojej organizacji

SAML pozwala organizacjom na zarządzanie uwierzytelnianiem i prawami dostępu użytkowników Tulipa przy użyciu istniejącego dostawcy tożsamości (IdP). Ten przewodnik będzie szczegółowo opisywał proces odkrywania i wdrażania instalacji SAML na poziomie Enterprise. Dla pojedynczej witryny, proszę zapoznać się z naszym artykułem wsparcia technicznego tutaj

Proces wysokiego poziomu

Wstępna praca

Zrozumienie ról użytkowników Tulipa

Połącz pracowników w grupy oparte na rolach

Określ, kto w Twojej organizacji będzie konfigurował IdP i Tulipa

Ustal, czy istniejący użytkownicy muszą zostać zmigrowani

Dla każdej nowej strony

Tulip włącza SAML na Twojej stronie

Twoja organizacja konfiguruje SAML (zarówno w IdP, jak i w Tulipie) i przyznaje dostęp użytkownikom

Proces tworzenia nowej strony

Wyślij prośbę do swojego menedżera sukcesu klienta Tulip, że chciałbyś stworzyć nową stronę z SAML. Powinieneś dostarczyć następujące informacje:

  • Nazwa i adres URL strony
  • Nazwisko i email osoby z Państwa organizacji, która zaloguje się i skonfiguruje SAML

Tulip stworzy witrynę i włączy SAML.

Osoba odpowiedzialna za konfigurację otrzyma e-mail, aby zalogować się do witryny, skonfigurują SAML zgodnie z opisem tutaj. Skonfigurują witrynę w oparciu o Twoją strategię dostępu, z których dwie są zdefiniowane poniżej.

Testowy dostęp z użytkownikami

UWAGA

Po zakończeniu, Właściciel Konta musi usunąć konto użytkownika osoby, która skonfigurowała SAML, ponieważ jej konto używa nazwy użytkownika i hasła Tulip. Jeśli ta osoba będzie utrzymywać SAML w przyszłości, powinna otrzymać dostęp Account Owner i zalogować się za pomocą SAML dla przyszłych konfiguracji.

Certyfikaty SAML stworzone przez Tulipa wygasają co roku. Tulip dotrze, aby powiadomić Twój zespół z 2 tygodniowym wyprzedzeniem o rotacji certyfikatu.

Proces konwersji SAML dla strony aktywnej

Tak samo jak powyżej, ale przed włączeniem SAML, będziemy musieli przekonwertować wszystkich istniejących użytkowników z kont Tulip na konta SAML. W tym celu potrzebujemy listę e-maili każdego użytkownika oraz jego IdP provided NameId. Będziemy pracować z osobą odpowiedzialną za konfigurację, aby dokonać tej konwersji z minimalnym przestojem. Jeśli istniejący użytkownicy nie są potrzebni, możemy po prostu usunąć wszystkich użytkowników. Należy pamiętać, że istniejące dane, takie jak uzupełnienia powiązane z tymi użytkownikami nie zostaną zmigrowane do ich nowych użytkowników. Zobacz dokumentację tutaj

Referencje

Instrukcje krok po kroku dotyczące konfiguracji Tulipa dla Azure Active Directory znajdują się tutaj.

Konfiguracja dostępu

LTS 6

Wraz z wydaniem Workspaces w LTS 6, strategia autoryzacji SAML uległa zmianie, aby lepiej umożliwić organizacjom zarządzanie użytkownikami bez tworzenia niepotrzebnego obciążenia dla IT.

Zmiany w SAML

Istnieją teraz dwie opcje autoryzacji:

SAML Custom Role Mapping

Przy pierwszym logowaniu, użytkownikowi przypisywana jest rola na podstawie grup przedstawionych w jego atrybucie roli. Po tym momencie Tulip nie będzie już czytał atrybutu roli tego użytkownika, a wszelkie zmiany ról muszą być dokonywane w platformie przez właściciela konta.

Jeśli ta metoda zostanie wybrana, będziesz musiał poprosić, aby Twój zespół IdP dodał odpowiednią rolę do wszystkich użytkowników, którzy wymagają dostępu do Tulipa.

Domyślne mapowanie ról

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

Kontrola dostępu

Możesz zdecydować się na dodanie atrybutu kontroli dostępu, gdzie użytkownik musi mieć określoną wartość, aby uzyskać dostęp do Tulipa. Jest to szczególnie istotne dla scenariuszy domyślnego mapowania, gdzie nadal chcesz dyktować, kto powinien mieć dostęp do Tulipa, niezależnie od roli lub przestrzeni roboczej.

Na przykład:

  • Użytkownik musi mieć atrybut TulipAccessControl ustawiony na True
  • Użytkownik musi należeć do grupy TulipUsers, która jest eksponowana poprzez atrybut TulipAccessControl (patrz przykład poniżej)

Jeśli zdecydujesz się na użycie Kontroli Dostępu, będziesz musiał poprosić, aby Twój zespół IdP dodał zdefiniowany atrybut i wartość do wszystkich użytkowników, którzy powinni mieć jakikolwiek dostęp do Tulipa.

Obszary robocze

Możesz przeczytać o przestrzeniach roboczych w szczegółach tutaj

Podobnie jak w przypadku atrybutu roli, będziesz miał teraz możliwość mapowania użytkowników do przestrzeni roboczych.

SAML Custom Workspace Mapping

Przy pierwszym logowaniu, użytkownik otrzymuje dostęp do przestrzeni roboczej na podstawie grup prezentowanych w jego atrybucie przestrzeni roboczej. Po tym momencie Tulip nie będzie już czytał atrybutu przestrzeni roboczej tego użytkownika, a wszelkie zmiany przestrzeni roboczej muszą być dokonywane w platformie przez właściciela konta.

Jeśli ta metoda zostanie wybrana, będziesz musiał poprosić, aby twój zespół IdP dodał odpowiednią przestrzeń roboczą do wszystkich użytkowników, którzy wymagają dostępu do Tulipa.

Domyślne mapowanie przestrzeni roboczej

Przy pierwszym logowaniu wszyscy użytkownicy otrzymują dostęp do domyślnej przestrzeni roboczej wybranej przez Ciebie. Właściciel konta może następnie dostosować dostęp do przestrzeni roboczej.


Tworzenie grup dostępu

Dla opcji niestandardowego mapowania ról (Domyślnie przed LTS 6)

Tworzenie standardowych grup dostępu Tulipa:

Każdy użytkownik będzie potrzebował atrybutu Role określonego w Twoim IdP, którego Tulip używa do określenia swoich uprawnień po uwierzytelnieniu się za pomocą nazwy użytkownika i hasła IdP. Możemy również użyć tego pola Role, aby określić, do jakich stron mają dostęp, używając standardowej konwencji nazewnictwa. Podczas gdy pole roli może być po prostu ustawioną zmienną, zalecane jest przypisanie użytkownika do określonych grup Tulipa i zmapowanie ich do atrybutu.

Role

Przejrzyj role dostępu do Tulipa tutaj. Każdy użytkownik będzie potrzebował przynajmniej jednej roli. Jeśli użytkownik ma wiele ról, Tulip wybierze tę z najwyższym dostępem.

Przykładowa rola to Właściciel konta.

UWAGA

Musi być co najmniej jeden Account Owner na stronę.

Site

Załóżmy, że Twoja organizacja ma dwie witryny, z instancją Tulip dla każdej z nich.

Możemy oznaczyć każdą stronę przez jej lokalizację (odpowiednio Texas i Londyn).

Łączenie dwóch

Możemy połączyć te dwie witryny, aby stworzyć macierz grupową dla użytkowników, którzy mają być przypisani. Zalecamy, aby organizacje dołączały lub poprzedzały wartość Tulip, aby łatwiej było ją filtrować.

Konwencja: tulip-siteRole

| | acme-texas.tulip.co | acme-london.tulip.co |
| Account Owner | tulip-texasAccountOwner | tulip-londonAccountOwner |
| Application Supervisor | tulip-texasApplicationSupervisor | tulip-londonApplicationSupervisor |
| Viewer | tulip-texasViewer | tulip-londonViewer |
| Operator | tulip-texasOperator | tulip-londonOperator |
| ... | | |

Jeśli Jane Smith jest kierownikiem placówki w Teksasie, przydzielamy ją do grupy tulip-texasAccountOwner. Jeśli Jane Smith potrzebuje również dostępu do widoku w witrynie w Londynie, mogłaby zostać dodana do grupy tulip-londonViewer.

Eksponowanie tych grup jako atrybutu dla Tulipa

W twoim IdP, Jane powinna mieć atrybut, tulip-role, gdzie wszystkie grupy, których jest członkiem, zawierające prefiks "tulip-" będą mapowane. Kiedy loguje się do Tulipa, atrybut tulip-role ma dwie wartości: tulip-texasAccountOwner, tulip-londonViewer.

Role globalne

Możesz również chcieć stworzyć globalne role dostępu, na przykład jako widz. Format dla tego byłby:

tulip-globalViewer

UWAGA

Jeśli użytkownik będący członkiem grupy globalnego widza zaloguje się na stronę, na której ma również rolę z większym dostępem, Tulip da mu najwyższy dostępny dostęp.


Czy ten artykuł był pomocny?