Oszacowanie kosztów integracji z systemem SSO
Jak oszacować nakład pracy związany z integracją SSO: sedno sprawy leży poza Państwa kodem źródłowym, a mianowicie w specyfice dostawcy tożsamości. Pytania, na które należy odpowiedzieć przed ustaleniem szacunkowej wartości.
W przypadku SSO chodzi głównie o specyfikę innych podmiotów — najpierw należy skonfigurować dostawcę tożsamości; reszta to kwestie techniczne.
„Dodaj SSO” brzmi jak jedna funkcja. A są to dwie. Pierwsza to niewielki element infrastruktury OAuth, SAML lub OIDC — dobrze udokumentowany, 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 URI przekierowań bardziej rygorystyczne niż w specyfikacji, limit czasu sesji niezgodny z Państwa ustawieniami, błąd o jeden element w sposobie serializacji grup oraz punkt końcowy metadanych, który we wtorki zwraca nieprawidłowy kod XML. Pierwsza część to kwestia, nad którą każdy może się wypowiedzieć. Druga część to sedno sprawy.
Oznacza to, że szacunek ten 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 działającym przed nim — a kod, który w końcu napiszą, będzie 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?”
To właśnie pytanie kierownika projektu decyduje o oszacowaniu. Jeśli ktoś już realizował projekt z wykorzystaniem 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 — a właściwym rozwiązaniem nie jest intensywniejsze szacowanie, lecz przeprowadzenie testu wstępnego w ramach określonego limitu czasowego, uwzględniającego rzeczywiste zachowanie dostawcy, a dopiero potem określenie zakresu implementacji.
Pytania, które warto zadać przed oddaniem głosu
- A konkretnie o którego dostawcę tożsamości chodzi? Okta, Azure AD, Google Workspace, Auth0, czy rozwiązanie niestandardowe?
- Czy ktoś z zespołu miał już wcześniej do czynienia z integracją z tym dostawcą?
- OAuth, SAML czy OIDC — i która wersja każdego z tych standardów?
- 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 z tych zasad ma 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” zadanie jest zbyt obszerne: proszę wyodrębnić przydzielanie uprawnień, mapowanie ról i migrację jako osobne zadania oraz oszacować zakres przepływu autoryzacji osobno.
Nie wybieraj numeru, dopóki nie dowiesz się, z którym dostawcą tożsamości zamierzasz się zintegrować. To właśnie dostawca ma kluczowe znaczenie.
Więcej informacji na temat powiązanego wzorca „specyfika rozwiązań innych podmiotów” można znaleźć w artykule szacowanie wymiany API strony trzeciej, a dodatkowe przykłady udanych szacunków – w innych materiałach. Rozpocznij bezpłatną sesję planowania pokerowego, gdy w ramach projektu wstępnego ustalono już, z usług którego dostawcy będzie korzystać oraz jakie są specyficzne cechy tego rozwiązania.