Oszacowanie kosztów integracji z systemem SSO

W przypadku SSO chodzi głównie o specyfikę innych podmiotów: najpierw należy skonfigurować dostawcę tożsamości, a reszta to kwestie techniczne.

„Dodaj SSO” brzmi jak jedna funkcja. A są to dwie. Pierwsza to niewielki element infrastruktury OAuth, SAML lub OIDC: jest dobrze udokumentowana, istnieją biblioteki, a każda nowoczesna biblioteka uwierzytelniająca zawiera samouczek. Druga to wszystko, co robi dostawca tożsamości, a czego nie ma w samouczku: nazwy oświadczeń niezgodne ze specyfikacją, reguły dotyczące adresów przekierowania (redirect-URI) bardziej rygorystyczne niż w specyfikacji, limit czasu sesji niezgodny z Państwa ustawieniami, błąd „off-by-one” w sposobie serializacji grup oraz punkt końcowy metadanych, który we wtorki zwraca nieprawidłowy kod XML. Pierwsza część to kwestia, w której każdy może zabrać głos. Druga część to sedno sprawy.

Oznacza to, że oszacowanie nie dotyczy tak naprawdę SSO. Chodzi o tego dostawcę tożsamości oraz o to, czy ktokolwiek z zespołu miał już wcześniej do czynienia z integracją z tym rozwiązaniem. Okta z podstawową konfiguracją SAML to zupełnie inna sytuacja niż Azure AD z niestandardową regułą oświadczeń, której nikt po żadnej ze stron w pełni nie rozumie. Zespół, który w ramach jednego sprintu wdraża integrację z Okta, poświęci trzy sprinty na wdrożenie federacyjnego AD FS z niestandardowym serwerem proxy przed nim, a kod, który napiszą, będzie ostatecznie wyglądał niemal identycznie.

O czym się mówi w tym pomieszczeniu

Backend: „To proces OAuth. Biblioteka zajmuje się tym. 5 punktów.”

Bezpieczeństwo: „Który dostawca tożsamości (IdP)? Okta? Azure AD? Niestandardowy SAML?”

Backend: „…czy to ma znaczenie?”

Bezpieczeństwo: „Tak. Ich twierdzenia nie pokrywają się z twierdzeniami zawartymi w specyfikacji”.

Pytanie wstępne: „Czy ktoś z tego zespołu miał już wcześniej do czynienia z integracją z dostawcą tożsamości (IdP)?”

SRE: „Jakie są konsekwencje przywrócenia poprzedniej wersji, jeśli usługa przestanie działać u połowy naszych użytkowników?”

O oszacowaniu decyduje pytanie zadane przez kierownika projektu. Jeśli ktoś już realizował zlecenie dla tego dostawcy, zadanie jest niewielkie i dobrze zdefiniowane. Jeśli nikt tego nie robił, zadanie składa się z dwóch elementów o nieznanym zakresie. Właściwym rozwiązaniem nie jest bardziej szczegółowe oszacowanie, lecz przeprowadzenie testu wstępnego (spike) w ramach określonego przedziału czasowego, opartego na rzeczywistym zachowaniu dostawcy, a następnie dostosowanie zakresu implementacji na tej podstawie.

Pytania, które warto zadać przed oddaniem głosu

• A konkretnie który dostawca usług uwierzytelniania? Okta, Azure AD, Google Workspace, Auth0, czy niestandardowy?
• Czy ktoś z zespołu miał już wcześniej do czynienia z integracją z tym dostawcą?
• OAuth, SAML czy OIDC? A która wersja każdego z nich?
• Jaki jest model tworzenia kont użytkowników: JIT, SCIM czy ręczny?
• Mapowanie grup do ról: czy jest nam to potrzebne? Gdzie znajduje się to mapowanie?
• Co stanie się z istniejącymi kontami lokalnymi podczas przełączenia?
• Limit czasu sesji, limit czasu bezczynności, wymóg uwierzytelniania wieloskładnikowego (MFA): które zasady mają pierwszeństwo?
• Czy możemy przeprowadzić testy z wykorzystaniem rzeczywistego dostawcy klienta, czy tylko w środowisku testowym?

Jeśli co najmniej dwa z tych elementów zostaną uznane za „osobne zadania”, oznacza to, że zakres projektu jest zbyt duży: należy wyodrębnić procesy przydzielania uprawnień, mapowania ról i migracji jako odrębne zadania, a także oszacować zakres przepływu autoryzacji osobno.

Proszę nie wybierać numeru, dopóki nie dowiedzą się Państwo, z którym dostawcą tożsamości mają Państwo do czynienia. Najważniejszy jest właśnie ten dostawca.

Więcej informacji na ten temat można znaleźć w artykule poświęconym szacowaniu kosztów wymiany API strony trzeciej, gdzie omówiono powiązany wzorzec „specyfika innego podmiotu”, a także w innych przykładach skutecznych szacunków. Proszę zorganizować bezpłatną sesję planowania pokerowego, gdy tylko w ramach projektu wstępnego ustalono, z usług którego dostawcy będzie korzystać oraz jakie są jego specyficzne cechy.