Auth0 – Delegowanie zarządzania tożsamością

Kiedy delegować autoryzację?

Czytając dokumentację techniczną Auth0 oraz przygotowując aplikacje wykorzystujące tego dostawcę, da się dostrzec scenariusze, w których delegowanie zarządzania kontami użytkowników jest jednoznacznie dobrą decyzją.

Dostawca oferuje (prawie)dokładnie to czego potrzebujemy

Większość dostawców tożsamości zaadresowało bardzo szeroki zakres wymagań. Konfiguracja dostawcy zajmuje znacznie mniej czasu niż pisanie autorskiego rozwiązania. Co może być szczególnie ważne w początkowej fazie projektu, gdzie każda godzina opóźnienia w budowie, może decydować o tym czy okaże się on sukcesem czy porażką.

Nie znamy wymagań

Innym problemem występującym na wczesnym etapie tworzenia projektu jest sytuacja, w której często nie znamy wymagań dotyczących autentykacji np. zakresu gromadzonych danych użytkownika. Tworzenie własnego rozwiązania, które następnie zostanie przepisane jest marnotrawstwem zasobów, a podpięcie zewnętrznego dostawcy w domyślnej konfiguracji jest ekstremalnie szybkie.

Należy też dodać że większość pracy wymaganej do integracji z zewnętrznym dostawcą tożsamości nie różni się od integracji z autorskim rozwiązaniem. W optymistycznym przypadku migracja do innego dostawcy, albo autorskiego rozwiązania polega na zmianach w pliku konfiguracyjnym.

Niektórzy twierdzą, że na bardzo wczesnym etapie można wcale nie zabezpieczać serwisu. Podpięcie autentykacji w późniejszym etapie powoduje powstanie błędów regresji – wiele modułów przestaje działać. Istnieje też ryzyko pominięcia zabezpieczenia całych modułów, lub ich części.

Relatywnie wysokie koszty utrzymania autoryzacji

Idealne oprogramowanie robi to co robić powinno i nie wymaga zmian. Posiadanie własnego mechanizmu autoryzacji może wymusić wprowadzenie zmian w aplikacji, a te zmiany pociągają za sobą inne koszty, takie jak przeprowadzenie testów regresji czy wdrożenia.

W takim wypadku wykorzystanie zewnętrznego dostawcy może być tańsze.

Czego nie należy się bać?

Oczywiście sytuacja nie zawsze jest różowa, są sytuacje, w których integracja wiąże się dodatkowymi kosztami, może być jednak ciągle opłacalna.

Niestandardowa rejestracja użytkownika

Większość dostawców dostarcza pustej bazy użytkowników i umożliwiają rejestrację w systemie dowolnej osobie. Są to jednak tylko ustawienia domyślne, rejestrację można wyłączyć jednym kliknięciem. Można też napisać własne ekrany logowania/rejestracji, robiąc to tracimy jednak jeden z powodów dla których decydujemy się na delegowanie.

Integracja z serwisami społecznościowymi

Jedyne czego, w celu integracji z facebookiem, wymaga wielu dostawców to kliknięcie w jeden przełącznik i uzupełnienie formularza. Niestety formularz zawiera kilka pól, których wypełnienie wymaga przebicia się przez biurokrację tej firmy. Przez biurokrację trzeba przejść także przy pisaniu własnego mechanizmu, jej udział sprawia jednak, że zysk wynikający z delegacją jest mniejszy.

Inne portale społecznościowe także wymagają przejścia przez biurokrację, zajmuje to jednak mniej czasu.

Import kont użytkowników

Istnieją dostawcy którzy oferują możliwość importu danych użytkowników. Może to się jednak wiązać z pewnymi niedogodnościami dla użytkownika. Auth0 nie umożliwia importu haseł, więc nawet jeżeli jakimś cudem je posiadamy to dostawca je zignoruje, a użytkownik i tak będzie musiał ustawić hasło przy kolejnym logowaniu.

Vendor locking

Napisałem wcześniej, że w optymistycznym przypadku zmiana dostawcy wymusza tylko aktualizację konfiguracji aplikacji. Problem w tym, że optymistyczne przypadki zdarzają się rzadko. Dostawcy dostarczają własnych bibliotek ułatwiających integrację, jednak ich użycie sprawia, że przesiadka jest trudniejsza.

Jeżeli mamy użytkowników, którzy na swoich maszynach, czy to typu dektop, czy to smartfonach, uporczywie używają starej wersji oprogramowania, migracja może oznaczać ich utratę.

Rozstanie jest trudne, jednak nie niemożliwe. Potwierdza to historia zespołu, który zbudował własnego dostawcę autoryzacji gdy dostawca nie dawał rady obsłużyć ruchu przez nich generowanego. Oznacza to, że pomimo tak długiej relacji, byli w stanie zakończyć ten związek.

Przekierowania na inną domenę

Domyślnie dostawcy tożsamości wymagają przekierowania na stronę w ich domenie albo użycia elementu iframe. Takie zachowanie aplikacji budzi podejrzenia szczególnie ostrożnych użytkowników, ponieważ z podobnych metod korzystają hackerzy w atakach typu phishing. Zachowanie to da się nadpisać ale wymaga to dodatkowej pracy.

Kiedy nie delegować?

Wymagania prawne

Jeżeli prawo, albo regulacje w organizacji, zabraniają przetrzymywania danych użytkowników po za własnymi serwerami, użycie zewnętrznego dostawcy jest niemożliwe albo znacznie utrudnione.

Koszta

Większość dostawców tożsamości działa w modelu SaaS co oznacza że miesięczna opłata zależy od ilości użytkowników i zakresu funkcjonalności. W szczególnych przypadkach, takich jak ekstremalnie duża ilość użytkowników, może się okazać, że napisanie własnego rozwiązania i utrzymywanie kont we własnym data-center będzie znacznie tańsze.

Niestandardowe mechanizmy autoryzacji

Istnieją rozwiązania techniczne utrudniające integrację z zewnętrznym dostawcą:

• komunikacja z oprogramowaniem działającym w  intranecie, np. usługą katalogową (Active Directory/Open LDAP), jest utrudniona, administrator sieci powie Ci czy jest możliwa.
• autoryzacja z wykorzystaniem programów klienckich – najpopularniejsze rozwiązanie do obsługi podpisów cyfrowych w Polsce wymaga uruchomienia apletu Javy, integracja z tą technologią, nawet bez uwzględnienia zewnętrznego dostawcy tożsamości, jest trudna. 

Czy delegować?

Przez wiele lat każdy własny projekt zaczynałem od napisania mechanizmu autoryzacji, a wiele z nich skończyło się na tym etapie. Wygląda na to, że kolejne będę zaczynał od integracji z dostawcą wykorzystując najtańszy możliwy plan i przechodził czym prędzej do rozwiązywania problemów biznesowych.