Oszacowanie kosztów integracji z systemem SSO
Jak oszacować nakład pracy związany z integracją SSO: praca ta wykracza poza Państwa kod źródłowy i wiąże się ze specyfiką dostawcy tożsamości. Pytania, na które należy odpowiedzieć przed ustaleniem szacunkowej liczby.
W przypadku SSO chodzi głównie o specyfikę innych podmiotów: najpierw należy skonfigurować dostawcę tożsamości, a reszta to już kwestia techniczna.
„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ń, które nie są zgodne ze specyfikacją, zasady dotyczące adresów URI przekierowań, które są 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 szacunek ten nie dotyczy tak naprawdę SSO. Chodzi o tego konkretnego dostawcę tożsamości oraz o to, czy ktoś 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 umieszczonym 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 cofnięcia zmian, jeśli usługa przestanie działać u połowy naszych użytkowników?”
O szacunku 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ółowa wycena, lecz wyznaczenie ram czasowych na przeprowadzenie testu sprawdzającego rzeczywiste zachowanie dostawcy, a dopiero potem określenie zakresu implementacji.
Pytania, które warto zadać przed głosowaniem
- A konkretnie, który dostawca usług uwierzytelniających? Okta, Azure AD, Google Workspace, Auth0, czy własny?
- 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 przejścia na nowy system?
- 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” zadanie jest zbyt obszerne: proszę wyodrębnić proces przydzielania uprawnień, mapowania ról oraz migracji jako osobne zadania i oszacować zakres przepływu autoryzacji osobno.
Proszę nie wybierać numeru, dopóki nie dowiedzą się Państwo, z usługodawcą tożsamości zamierzają Państwo przeprowadzić integrację. Kluczową kwestią jest właśnie ten usługodawca.
Więcej informacji na temat powiązanego wzorca „specyfiki innego podmiotu” można znaleźć w artykule Szacowanie wymiany API podmiotu zewnętrznego, a dodatkowe przykłady udanych szacunków – w innych materiałach. Rozpocznij bezpłatną sesję planowania pokerowego, gdy projekt pilotażowy wyjaśni, który dostawca został wybrany i jakie są jego specyficzne cechy.