Czy naprawdę potrzebujesz wielu dzierżawców do zarządzania systemem tożsamości?

Dzięki rosnącej dojrzałości narzędzi low-code i usług chmurowych, w połączeniu z przyspieszeniem narzędziowania AI, próg rozwijania aplikacji jest znacząco obniżany i na rynku pojawia się coraz więcej aplikacji.

Niezależnie od tego, czy to złożone, czy proste aplikacje, większość wspiera scenariusze rejestracji i logowania użytkowników, aby użytkownicy mogli otrzymywać bardziej stabilne, bezpieczne i spersonalizowane usługi. Aby rozwiązać problem logowania i rejestracji użytkowników, pierwszym krokiem jest zbudowanie systemu tożsamości.

Dla wielu aplikacji ukierunkowanych na konsumentów ich modele tożsamości są często stosunkowo proste, a czasem wystarczą tylko e-mail i hasło. W przypadku aplikacji znajdujących się na etapie szybkiego wzrostu i przyciągających nowych użytkowników, to wystarczy; ale gdy aplikacja ma już własny model biznesowy, w najprostszym przypadku, na przykład serwując reklamy, konieczne jest rozróżnienie między zwykłymi kontami użytkowników a kontami reklamodawców. Konta reklamodawców mogą dostosowywać skalę emisji reklam, treści itp., podczas gdy zwykli użytkownicy mogą tylko przeglądać darmowe treści i reklamy itp.

Logto to chmurowe rozwiązanie tożsamości, a także dostępne jest oprogramowanie open-source (OSS) z tym samym jądrem co usługi w chmurze, dla użytkowników ze specjalnymi potrzebami dokonywania dostosowań. Usługa Logto jest oparta na systemie multi-tenancy, gdzie każdy użytkownik Logto tworzy własne konto i może zarządzać wieloma dzierżawcami w ramach tego konta. Inne różne usługi chmurowe tożsamości również mają podobne architektury, przy czym każda usługa ma własną definicję „dzierżawcy”, więc model dzierżawcy, o którym mówimy w tym artykule, jest ograniczony do scenariusza Logto, a dla innych dostawców mogą istnieć inne odpowiadające koncepcje.

Warto zauważyć, że w modelu multi-tenant Logto dane między dzierżawcami (wszystkie informacje użytkowników końcowych) są izolowane, więc użytkownicy Logto mogą zarządzać danymi kont użytkowników końcowych zgodnie ze swoimi potrzebami biznesowymi w ramach jednego konta Logto. Wiele innych chmurowych usług tożsamości może wspierać tylko jedno dzierżawne konto, co sprawia, że użytkownicy, którzy potrzebują zarządzać wieloma dzierżawcami jednocześnie muszą często zmieniać konta, co skutkuje słabym doświadczeniem.

Po tym wszystkim, jak powinieneś wybrać model kont odpowiedni dla swojej aplikacji? Oto trzy przypadki.

Przypadek 1: Aplikacja bezpośrednio świadczy usługi użytkownikom końcowym#

Model tożsamości w tego rodzaju aplikacjach jest całkiem prosty. Weźmy na przykład aplikację do strumieniowego przesyłania muzyki — oprócz administratora (użytkownik Logto „foo”, który w tym przypadku jest właścicielem dzierżawcy, ma wrodzony dostęp administracyjny), są tylko użytkownicy końcowi.

W tym scenariuszu użytkownicy końcowi mogą być podzieleni na trzy typy:

1. Użytkownik z planem darmowym: Może tylko odtwarzać darmową muzykę
2. Użytkownik z planem płatnym: Może odtwarzać darmową muzykę i tworzyć własne listy odtwarzania
3. Użytkownik premium: Oprócz odtwarzania darmowej muzyki i tworzenia list odtwarzania, może również odtwarzać muzykę HiFi

W powyższym scenariuszu aplikacji potrzebujemy tylko trzech typów ról (darmowy, płatny, premium), z których każda ma przydzielone różne uprawnienia. Tak więc po zalogowaniu się użytkownika końcowego, Logto może zdecydować, czy zapewnić mu określone usługi (np. dostęp do muzyki HiFi) na podstawie posiadanej roli. W tym momencie potrzebujemy tylko jednego dzierżawcy, aby spełnić wymagania.

Przypadek 2: Aplikacja platformy eCommerce#

Platforma, która łączy zewnętrznych dostawców usług i użytkowników końcowych, co jest obecnie bardzo popularnym modelem biznesowym 2C. Do rozważenia są dwie grupy użytkowników - posługując się przykładem aplikacji e-commerce, są nimi kupcy (dostawcy usług) i nabywcy (użytkownicy końcowi).

Istnieją dwa sposoby budowy modelu tożsamości tutaj:

1. Umieścić grupy użytkowników kupców i nabywców pod tym samym dzierżawcą.

2. Umieścić nabywców i kupców w dwóch różnych dzierżawcach odpowiednio.

Aby przykład był łatwiejszy do zrozumienia, załóżmy, że nabywcy mogą składać zamówienia lub przeglądać opisy produktów; kupcy mogą zmieniać ceny produktów, opisy produktów i przeglądać ich stany magazynowe. Kupcy przeglądają opisy produktów, aby pomóc im wykrywać problemy i na bieżąco aktualizować informacje o produktach.

Dla modelu tożsamości 1 jest tylko jedna aplikacja. Wszyscy użytkownicy, którzy się rejestrują, stają się nabywcami. Jeśli ktoś potrzebuje sprzedawać rzeczy, może dodawać własne produkty do sprzedaży, więc tacy użytkownicy końcowi uzyskają uprawnienia kupieckie oprócz uprawnień nabywcy, aby zarządzać własnymi produktami.

Dla modelu tożsamości 2, skoro każdy dzierżawca ma swoje unikatowe informacje tożsamości i swój oddzielny bramkę autoryzacyjną, każdy dzierżawca musi posiadać własną, oddzielną aplikację. W przykładzie istniałaby aplikacja nabywcy i aplikacja kupca. Konta nabywców nie mogą stać się kupcami, a konta kupców nie mogą stać się nabywcami. Jeśli kupcy chcą sprawdzić własne opisy produktów z perspektywy nabywcy, jak w modelu 1, muszą ponownie zaimplementować tę samą funkcjonalność w aplikacji kupieckiej lub zarejestrować konto w aplikacji nabywczej, aby to zobaczyć. Dodaje to wiele złożoności, ale zaletą jest, że tożsamości nabywców i kupców są całkowicie izolowane.

Jeśli kupcy mają wiele różnych produktów do zarządzania, użycie modelu tożsamości 2 i opracowanie bardziej wyspecjalizowanej aplikacji kupieckiej powinno być lepszym wyborem. Model 1 jest bardziej odpowiedni dla platform takich jak eBay, gdzie kupcy nie mają wielu produktów i również nie potrzebują zbyt skomplikowanej funkcjonalności zarządzania produktami.

Przypadek 3: Aplikacje stworzone przez firmę doradztwa IT#

Przypuśćmy, że istnieje firma doradcza w dziedzinie technologii informatycznych, której klienci nie mają zdolności do samodzielnego rozwijania systemów IT, więc muszą szukać usług technicznych od tej firmy.

Zakładając, że firma ma dwóch klientów, jednym będąc wewnętrznym systemem zarządzania książkami dla księgarni, a drugim jest system rezerwacji dla hotelu.

Z punktu widzenia właściciela księgarni, oczywiście nie chcę, aby goście hotelowi mogli losowo logować się do mojego systemu zarządzania książkami, ponieważ byłoby to bardzo niebezpieczne. Dlatego, z punktu widzenia ochrony prywatności, dla każdego klienta należy ustawić oddzielnego dzierżawcę, wykorzystując mechanizm izolacji informacji dzierżawców, aby zapewnić, że dane klientów są niewidoczne dla innych klientów.

Jak wspomnieliśmy wcześniej, nawet jeśli masz potrzebę stworzenia wielu dzierżawców, Logto może pomóc w zarządzaniu wieloma dzierżawcami w ramach jednego konta, co jest bardziej wygodne i bezpieczne w porównaniu do niektórych innych usług, które wymagają, abyś stworzył i zarządzał wieloma kontami samodzielnie.

Poprzez przedstawione powyżej przykłady, bez wątpienia zrozumiesz, kiedy na pewno musisz stworzyć wielu dzierżawców, w jakich scenariuszach możesz mieć albo jednego, albo wielu dzierżawców, i zgodnie z własnymi potrzebami biznesowymi, wybrać rozwiązanie modelu tożsamości, które najlepiej Ci odpowiada.

Zespół Logto ma na celu zapewnienie, że pytanie o "czy powinno się tworzyć wielu dzierżawców" nie będzie stanowiło blokady dla żadnego biznesu. Jeśli jesteś niepewny, czy twój biznesowy scenariusz można osiągnąć z jednym dzierżawcą, prosimy dołączyć do społeczności Logto w celu konsultacji. Twoje pytanie może być również pytaniem kogoś innego, więc podziel się z nami wyzwaniami, które napotkałeś, aby pomóc poprawić skalowalność produktów Logto.

Jeśli wybierasz ramę tożsamości dla swojej aplikacji, Logto jest warte wypróbowania. Oferuje rozwiązanie gotowe do użycia, odpowiednie dla różnych scenariuszy biznesowych od małych firm po wielkoskalowe aplikacje!