CIAM 101: Uwierzytelnianie, Tożsamość, SSO

Tło#

Zacząłem budować Logto, ponieważ zauważyłem, że Zarządzanie Tożsamością i Dostępem (IAM) z czasem stało się coraz bardziej skomplikowane i obszerne. Koncepcja IAM jest na tyle duża, że pojawiły się nowe koncepcje, takie jak WIAM (Workforce IAM) i CIAM (Customer IAM).

Chociaż WIAM i CIAM mają tę samą podstawę, różnią się przypadkami użycia: WIAM jest zazwyczaj używane dla użytkowników wewnętrznych, podczas gdy CIAM dla zewnętrznych klientów. Kilka przykładów:

• WIAM Twoja firma ma zunifikowany system tożsamości dla pracowników, dzięki czemu każdy może używać tego samego konta do uzyskiwania dostępu do zasobów firmowych, takich jak subskrypcje oprogramowania, usługi chmurowe itd.
• CIAM Twoja księgarnia online wymaga systemu tożsamości użytkowników dla klientów i sprzedawców. Proces logowania jest kluczową częścią onboardingu, ponieważ znajduje się na szczycie lejka konwersji.

Logto rozpoczęło się od CIAM z różnych powodów (mamy inny artykuł, który o tym opowiada). Podczas rozwoju, zdaliśmy sobie sprawę, że zbudowanie zrozumienia całego zespołu byłoby korzystne przed wprowadzeniem naszego produktu na wyższy poziom. Mamy nadzieję, że to również pomoże Ci lepiej zrozumieć krajobraz IAM.

Zacznijmy!

Podstawy CIAM#

W tym artykule skupimy się na podstawowych pojęciach CIAM i problemach, które mogą napotkać podczas lub po procesie uwierzytelniania. Omówimy również pojedyncze logowanie (SSO) i związane z nim scenariusze.

Uwierzytelnianie i autoryzacja#

💡 Uwierzytelnianie jest pierwotnie zdefiniowane jako "Kim jesteś?". Jednakże, rozważając tożsamości cyfrowe, bardziej trafne jest przedstawienie uwierzytelniania jako "dowodzenie posiadania tożsamości". (Źródło: Calm-Card-2424)

Jeśli odkryjesz coś, co nie pasuje do jednej z tych dwóch kategorii, prawdopodobnie nie jest to istotne dla biznesu tożsamości.

• Przykłady uwierzytelniania
  • Logowanie z hasłem, logowanie bez hasła, logowanie społecznościowe itd.
  • Uwierzytelnianie maszyn do maszyn
• Przykłady autoryzacji
  • Kontrola dostępu oparta na rolach
  • Kontrola dostępu oparta na atrybutach
• Przykłady wyjątki
  • Dane niebędące tożsamościami
  • Webhooki

Tożsamość i Najemca#

Tożsamość zazwyczaj reprezentuje albo użytkownika, albo maszynę. Po pomyślnym uwierzytelnieniu wydawany jest Token ID jako Tożsamość.

Innymi słowy, głównym celem uwierzytelniania jest uzyskanie Tożsamości.

Najemca to grupa tożsamości:

Kiedy omawiamy "Multi-tenant", mówimy o wielu instancjach Logto, które są izolowane tożsamościowo od siebie. Innymi słowy, wielu instancji Logto.

Zwróć uwagę, że ma dwa izolowane systemy tożsamości, tj. nie możesz użyć Tożsamości z Najemcy 1 w Najemcy 2, nawet dla tego samego identyfikatora (e-mail, telefon, itd.). To jak karta członkowska Costco, która nie jest ważna w Whole Foods.

Aplikacja i Najemca#

Podobnie jak Tożsamość, Aplikacja również należy do Najemcy. Kilka rzeczy do zapamiętania:

• Zazwyczaj nie ma bezpośredniej relacji między Aplikacją a Tożsamością.
  • Tożsamość może reprezentować Aplikację, ale nie ma między nimi bezpośredniego połączenia.
• Podobnie jak użytkownicy, aplikacje są również na poziomie Najemcy.
• Aplikacje to kod, podczas gdy użytkownicy to ludzie.
• Jedynym celem Aplikacji jest ukończenie uwierzytelniania, tj. uzyskanie Tożsamości.

Usługodawca Tożsamości (IdP) i Dostawca Usług (SP)#

Różnica między tymi dwoma dostawcami jest trudna, ale ważna.

• Usługodawca Tożsamości to usługodawca, który zapewnia uwierzytelnianie (AuthN) i wydaje tożsamości.

Możesz znaleźć różne wyjaśnienia dotyczące Dostawcy Usług od Google, chociaż mogą nie być satysfakcjonujące. W mojej opinii, Dostawca Usług to pojęcie względne:

• Dostawca Usług (lub Relying Party w OIDC) to usługodawca lub klient, który inicjuje uwierzytelnianie (AuthN) i żąda wyniku od Usługodawców Tożsamości.

Quiz#

Weź pod uwagę typowy scenariusz logowania społecznościowego:

❓ Ilu Dostawców Usług i Usługodawców Tożsamości w tym grafie?

Odpowiedź

Oba mają po dwóch. Aplikacja iOS jest dostawcą usług dla Logto, podczas gdy Logto jest dostawcą tożsamości. Logto jest również dostawcą usług dla GitHub, podczas gdy GitHub jest dostawcą tożsamości. Tak więc, Logto jest zarówno Dostawcą Usług, jak i Dostawcą Tożsamości.

Studium przypadku: Firma z rozwiązaniami technologicznymi#

Jesteś CTO firmy z rozwiązaniami technologicznymi, masz ponad 100 partnerów biznesowych i zrealizowałeś ponad 300 projektów.

• Każdy projekt jest albo aplikacją webową, albo aplikacją mobilną z zapleczem.
• Dla każdego partnera biznesowego chcesz przebudować system użytkowników, aby zapewnić SSO w ramach jego projektów.

❓ W jaki sposób Logto (lub produkt CIAM) może pomóc?

Odpowiedź

Utwórz instancję Logto dla każdego partnera biznesowego. Każdy partner posiada Najemcę. Projekty są mapowane na "Aplikacje" w Logto.

Logto oferuje uniwersalne doświadczenie logowania (tj. SSO) w ramach Najemcy, więc użytkownicy nie muszą ponownie logować się, gdy uzyskują dostęp do innej aplikacji w tym samym Najemcy, jeśli już się zalogowali.

O czym mówimy, kiedy mówimy o SSO#

Zauważyliśmy, że termin “SSO” często wywołuje zamieszanie. Uważamy, że pojedyncze logowanie (SSO) jest zachowaniem, a nie pojęciem biznesowym. Dlatego SSO nie równa się „SSO w WIAM”.

Kiedy mówimy „potrzebuje SSO”, może to odnosić się do jednej z następujących sytuacji:

Przypadek SSO 1#

👉🏽 W dużej firmie pracownicy używają tych samych danych logowania do logowania się do wszystkich zasobów firmowych licencjonowanych (np. e-mail, IM, usługi w chmurze).

Jest to typowy scenariusz WIAM. W tym przypadku zaangażowany jest tylko jeden Dostawca Tożsamości. Na razie nas to nie interesuje.

Przypadek SSO 2#

👉🏽 Użytkownicy końcowi używają tych samych danych logowania do logowania się do wszystkich usług rozwijanych przez tę samą firmę (np. GSuite).

Logto obecnie koncentruje się na podejściu opisanym powyżej. Mogą istnieć niezależnie i bez połączenia wielu zewnętrznych dostawców tożsamości, takich jak zewnętrzni dostawcy logowania społecznościowego.

Mimo to, Logto pozostaje jedynym źródłem prawdy dla Tożsamości, po prostu "pożyczając" je od innych dostawców. W takim przypadku, Logto działa jako zarówno Dostawca Tożsamości (dla aplikacji GSuite), jak i Dostawca Usług (dla zewnętrznych Dostawców Tożsamości).

Przypadek SSO 3#

👉🏽 Użytkownicy końcowi mogą używać tylko określonego Dostawcy Tożsamości w obrębie odpowiadającej domeny e-mail, aby zakończyć uwierzytelnianie. Na przykład, logując się do Figma za pomocą Google Workspace.

Jest to najczęstszy przypadek użycia SSO w CIAM. Przyjrzyjmy się bliżej.

Jeśli chcemy zalogować się do Figma używając naszego emaila @silverhand.io, możemy użyć logowania społecznego lub SSO. Rysunki poniżej ilustrują różnicę między nimi:

Słowami:

• Po zalogowaniu społecznym użytkownicy mogą swobodnie ustawić hasło lub zmienić adres e-mail w Figma
• Po SSO, użytkownicy nie mogą ustawić hasła ani zmienić żadnych danych osobowych w tym adresu e-mail, ponieważ ich Tożsamości są zarządzane przez Google Workspace

W tym przypadku, Logto jest zarówno Dostawcą Tożsamości, jak i Dostawcą Usług. Wydaje się, że SSO jest bardziej złożone niż normalny proces logowania. Jakie są korzyści dla właściciela tożsamości?

• Centralizowana kontrola: Utrzymuj informacje o tożsamości i procesy uwierzytelniania w jednym miejscu, zapewniając, że informacje użytkowników są zawsze aktualne. Nie ma potrzeby dodawania i usuwania licencji w różnych aplikacjach podczas zmian.
• Ulepszona efektywność użytkownika: Właściciele tożsamości, którzy wymagają SSO, są zazwyczaj korporacjami. Ich pracownicy mogą używać tych samych danych logowania i współdzielonej sesji do aplikacji międzyfirmowych, takich jak Figma, Zoom, Slack itd.
• Zwiększone bezpieczeństwo: Możesz zauważyć, że niektóre korporacje wymagają określonych metod logowania, takich jak dynamiczne kody weryfikacyjne. Używając SSO można zapewnić, że każdy pracownik stosuje te same kombinacje metod logowania do uzyskiwania dostępu do wszystkich zasobów.

🤔 Mądry jak ty musiał zauważyć, że jest to w rzeczywistości Przypadek SSO 1 z perspektywy SaaS.

Czas omówić "X" na grafie SSO. To reprezentuje proces łączenia domeny e-mail z konkretnym Dostawcą Tożsamości przez Figma. Ale jak to działa?

Mapowanie SSO#

Ponieważ prośba często pochodzi od klientów przedsiębiorstwa, odnosimy się do procesu "Przypadku SSO 3" z poprzedniego rozdziału jako "Enterprise SSO" dla jasności.

Możemy łatwo zaprojektować naiwną rozwiązanie: utworzenie mapowania między domenami e-mail a metodami SSO, a następnie ręczna aktualizacja tego.

Działanie procesu “X” jest teraz jasne:

🔍 Znajdź zmapowaną metodę Enterprise SSO dla podanej domeny e-mail

Tak więc, jeśli skonfigurujesz silverhand.io jako ważną domenę e-mail, która łączy się z adresem URL Google Workspace SSO, użytkownicy próbujący zalogować się przy użyciu adresu e-mail @silverhand.io zostaną przekierowani na odpowiednią stronę logowania Google Workspace, zamiast być obsługiwani na miejscu.

Kiedy masz tylko kilka tuzinów klientów potrzebujących Enterprise SSO, ręczne zarządzanie mapowaniem jest ok. Jednakże, jest więcej rzeczy do rozważenia:

1. Co zrobić, jeśli masz setki lub tysiące klientów Enterprise SSO?
2. Jaka jest relacja między „normalnymi użytkownikami” a „użytkownikami Enterprise SSO”?
3. Czy dane powinny być izolowane pomiędzy różnymi klientami Enterprise SSO?
4. Czy istnieje potrzeba zapewnienia dashboardu dla administratorów Enterprise SSO, aby mogli zobaczyć aktywnych użytkowników, dzienniki audytu itd.?
5. Jak konta mogą być automatycznie dezaktywowane, kiedy użytkownik zostaje usunięty z Dostawcy Tożsamości Enterprise SSO?

I wiele więcej. Ponieważ niemal wszystkie Enterprise SSO bazują na domenach e-mail, możemy szybko znaleźć lepsze rozwiązanie:

• Jeśli użytkownik może udowodnić posiadanie tej domeny, może samodzielnie skonfigurować enterprise SSO dla tej domeny.

To rozwiązanie rozwiązuje pierwsze dwa pytania:

1. Co zrobić, jeśli masz setki lub tysiące klientów Enterprise SSO?

• Mogą skonfigurować Enterprise SSO w sposób samodzielny.

2. Jaka jest relacja między „normalnymi użytkownikami” a „użytkownikami Enterprise SSO”?

• Otwieramy wszystkie możliwe metody logowania dla normalnych użytkowników z wyjątkiem Enterprise SSO; Podczas gdy ograniczamy metodę logowania do tylko Enterprise SSO dla użytkowników próbujących się zalogować za pomocą skonfigurowanych domen.

Jeśli chodzi o trzecie pytanie:

3. Czy dane powinny być izolowane pomiędzy różnymi klientami Enterprise SSO?

• Tak i nie. Nadszedł czas, aby wprowadzić organizację.

Organizacja#

Wspomnieliśmy o używaniu domen e-mail do rozpoznania konkretnej metody Enterprise SSO, którą należy zastosować; innymi słowy, zastosowanie konkretnego traktowania dla konkretnej grupy użytkowników.

Jednakże, wymagania klientów często wykraczają poza samo Enterprise SSO; na przykład, pytania 4 i 5 w poprzednim rozdziale. Przez lata dojrzały model został opracowany przez wybitne firmy z branży SaaS, aby rozwiązać tego rodzaju problemy: Organizacje.

Zasady Organizacji

1. Organizacja to grupa tożsamości, zazwyczaj mniejsza niż Najemca.
2. Wszystkie organizacje są powiązane z Najemcą.

Możesz zobaczyć inne terminy, takie jak "Workspace", “Team”, a nawet "Najemca" w oprogramowaniu. Aby przekonać się, czy to pojęcie, o którym mówimy, sprawdź, czy reprezentuje „grupę tożsamości”.

W tym artykule użyjemy terminu "Organizacja" dla spójności.

W Notion, możesz tworzyć i dołączać do wielu miejsc pracy (czyli organizacji) przy użyciu tego samego adresu e-mail i łatwo się między nimi przełączać.

Dla Slack, wydaje się być tak samo, ale podejrzewamy, że używa różnych Tożsamości za kulisami, ponieważ musimy tworzyć nowe konto dla każdego miejsca pracy.

Notion ma dostępny “Plan Personalny”, który jest zazwyczaj ukrytą Organizacją, z jedynym użytkownikiem (tobą) w środku. Nie znamy dokładnego wdrożenia Notion, ale to wyjaśnienie jest rozsądne i osiągalne dla naszego modelu.

Każda Organizacja ma również identyfikator, zazwyczaj nazywany „domeną Organizacji”.

Quiz#

❓ Czy aplikacja może być powiązana z Organizacją?

Odpowiedź

Tak, tak. Jak omawialiśmy na początku, aplikacja może mieć Tożsamość. Czy możesz rozwinąć biznesowy scenariusz tego?

Pozostałe pytania#

3. Czy dane powinny być izolowane pomiędzy różnymi klientami Enterprise SSO?

• Tak: Izolowanie danych biznesowych, takich jak wiadomości i dokumenty, na poziomie organizacji.
• Nie: Utrzymywanie tożsamości niezależne, ponieważ nie muszą być powiązane z organizacją.
• Zwróć uwagę, że zaangażowane są tu trzy odrębne podmioty: Tożsamości, Organizacje i konfiguracje Enterprise SSO; co znacznie zwiększyło złożoność. Samo pytanie nie jest wystarczająco szczegółowe.

4. Czy istnieje potrzeba zapewnienia dashboardu dla administratorów Enterprise SSO, aby mogli zobaczyć aktywnych użytkowników, dzienniki audytu itd.?

5. Jak konta mogą być automatycznie dezaktywowane, kiedy użytkownik zostaje usunięty z Dostawcy Tożsamości Enterprise SSO?

• Te wymagania są bardziej zorientowane na biznes i można je wdrożyć na poziomie organizacji. Pozostawimy je otwarte tutaj.

Zakończenie#

Przedstawiliśmy kilka pojęć: Uwierzytelnianie (AuthN), Autoryzacja (AuthZ), Tożsamość, Najemca, Aplikacja, Dostawca Tożsamości (IdP), Dostawca Usług (SP), Pojedyncze logowanie (SSO) i Enterprise SSO (Organizacja). Może to wymagać trochę czasu, aby je wszystkie zrozumieć.

Pisałem ten artykuł, zauważyłem, że interesujące jest to, że najdroższe plany usług online często zawierają ekskluzywne funkcje związane z autoryzacją, które są całkowicie nie wspomniane w tym artykule. Możesz mieć już kilka pytań na temat autoryzacji, takie jak:

• Jak możemy przypisać uprawnienia do użytkownika i je zweryfikować?
• Jakiego modelu autoryzacji powinienem użyć?
• Jaka jest najlepsza praktyka aplikacji modelu autoryzacji?