## 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 Niezależnie od różnic, WIAM i CIAM mają tę samą podstawę: uwierzytelnianie i autoryzacja. Te dwa pojęcia są rdzeniem ich funkcji. 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 (AuthN) odpowiada na pytanie “Jaką tożsamość posiadasz?” - Autoryzacja (AuthZ) odpowiada na pytanie “Co możesz zrobić?” > 💡 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](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/)) 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: ```mermaid graph TD Tenant --- A[Identity: User 1] Tenant --- B[Identity: User 2] Tenant --- C[Identity: Machine 1] ``` 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. ```mermaid graph TD T1[Tenant 1] --- A[Identity: User 1] T2[Tenant 2] --- B[Identity: User 1] T2[Tenant 2] --- C[Identity: Machine 1] subgraph IS2[Identity system 2] T2 B C end subgraph IS1[Identity system 1] T1 A end ``` 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. 🧱 Krótko mówiąc, istnieją „fizyczne ściany” pomiędzy Najemcami. Definicja "Najemcy" różni się w produktach CIAM. Niektórzy odnoszą się do terminu "Organizacja" w Logto, który zostanie przedstawiony później. ### 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](https://openid.net/specs/openid-connect-core-1_0.html))** 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: ```mermaid graph LR A[iOS App] --> |Wywołaj logowanie| Logto --> |Przekieruj| GitHub GitHub --> |Zwróć ID GitHub| Logto --> |Zwróć ID Logto| A ``` **❓ 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. ```mermaid graph TD T1[Tenant 1] --- A[App 1] T1 --- B[App 2] T1 --- C[App 3] T1 --- U1[User 1] T1 --- U2[User 2] T2[Tenant 2] --- D[App 1] T2 --- E[App 2] T2 --- U21[User 1] T2 --- U22[User 2] ``` 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 większości przypadków, "grupa tożsamości" jest równoważna "grupie użytkowników". Jednak **ta sama Tożsamość może istnieć w wielu Organizacjach**. 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.

![Slack workspaces](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _Slack workspaces_ ![Notion workspaces](https://uploads.strapi.logto.io/1/notion_workspaces_5bdc2b7e9b.png) _Notion workspaces_

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”. "Domena organizacji" to wewnętrzny identyfikator używany do rozróżniania organizacji. Może różnić się od "domeny e-mail", ponieważ pierwszy jest zarządzany przez dostawcę usług, podczas gdy drugi jest zazwyczaj dostarczany przez zewnętrznego dostawcę tożsamości. Na przykład, możesz użyć `foo` jako domena organizacyjna w Slack, ale użyć `@bar.io` jako domena e-mail dla tej 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? 🔥 Zrób przerwę, i do zobaczenia w CIAM 102!