Nowoczesna tożsamość: SAML, OIDC i podejścia hybrydowe

Security Assertion Markup Language 2.0 (SAML) to oparty na XML otwarty standard jednokrotnego logowania w środowiskach przedsiębiorstw. SAML, ustandaryzowany w 2005 roku, umożliwia dostawcy tożsamości (IdP) wystawianie dostawcom usług (SP) cyfrowo podpisanych asercji XML, dzięki czemu użytkownicy mogą uwierzytelnić się raz i uzyskać dostęp do wielu usług bez ponownego wpisywania danych uwierzytelniających.

W protokole SAML dostawca tożsamości (IdP) jest podmiotem, który uwierzytelnia użytkowników i wystawia asercje. Przykłady: Okta, Microsoft Entra ID, PingFederate. Dostawca usług (SP) to aplikacja, która korzysta z asercji dostawcy tożsamości. Przykłady: Salesforce, Workday, ServiceNow. Dostawca usług ufa podpisowi dostawcy tożsamości i na tej podstawie przyznaje dostęp.

Asercje SAML muszą być cyfrowo podpisane przez dostawcę tożsamości za pomocą pary kluczy RSA lub EC, co umożliwia dostawcy usług weryfikację ich autentyczności. Asercje mogą być również szyfrowane w celu zapewnienia poufności podczas przesyłania. Dostawca usług musi zweryfikować podpis, sprawdzić znaczniki czasu NotBefore i NotOnOrAfter asercji oraz zweryfikować ograniczenie odbiorców, aby zapobiec atakom typu replay.

OpenID Connect (OIDC) to nowoczesna warstwa tożsamości zbudowana na OAuth 2.0, która służy do tego samego celu co SAML — zapewnia jednokrotne logowanie — ale zamiast XML używa JSON i tokenów JWT. OIDC, opublikowany w 2014 roku, lepiej sprawdza się w aplikacjach mobilnych, aplikacjach jednostronicowych i interfejsach API REST, podczas gdy SAML nadal dominuje w tradycyjnych internetowych aplikacjach dla przedsiębiorstw.

OIDC rozszerza OAuth 2.0, dodając token ID (JWT zawierający deklaracje dotyczące tożsamości) do przepływu autoryzacji OAuth 2.0. OAuth 2.0 obsługuje autoryzację (delegowanie dostępu do interfejsów API), natomiast OIDC dodaje uwierzytelnianie (weryfikację tożsamości użytkownika). OIDC wymaga zakresu openid i zwraca token ID wraz z tokenem dostępu OAuth.

Microsoft Entra ID (dawniej Azure Active Directory) to natywny dla chmury dostawca tożsamości, który obsługuje SAML i OIDC/OAuth 2.0 na potrzeby federacyjnego jednokrotnego logowania. Może synchronizować się z lokalną usługą Active Directory za pośrednictwem Entra Connect, zapewniając hybrydowe zarządzanie tożsamością, w którym zasoby chmurowe i lokalne korzystają z jednego katalogu tożsamości.

Active Directory Federation Services (AD FS) to lokalny serwer federacyjny firmy Microsoft, który udostępnia punkty końcowe SAML i WS-Federation dla lokalnej usługi Active Directory. AD FS łączy starsze aplikacje oparte na SAML z poświadczeniami usługi Active Directory, a we wdrożeniach hybrydowych federuje się z Entra ID, rozszerzając jednokrotne logowanie na aplikacje chmurowe.

System for Cross-domain Identity Management (SCIM) to standard interfejsu API REST służący do automatyzacji aprowizacji i wycofywania aprowizacji użytkowników w systemach tożsamości i aplikacjach. Gdy nowy pracownik zostanie dodany do Entra ID lub Okta, SCIM automatycznie tworzy odpowiadające mu konta w połączonych aplikacjach SaaS, a po odejściu pracownika je usuwa.

Nowoczesni dostawcy tożsamości wdrażają zasady dostępu warunkowego, które przed przyznaniem dostępu oceniają sygnały ryzyka (zgodność urządzenia, lokalizację i zachowanie użytkownika). Zasady te mogą wymagać dodatkowego uwierzytelniania wieloskładnikowego w przypadku wrażliwych zasobów. W połączeniu z jednokrotnym logowaniem OIDC lub SAML dostęp warunkowy zapewnia adaptacyjne bezpieczeństwo bez uciążliwego ponownego uwierzytelniania.

Architektura Zero Trust traktuje lokalizację sieciową jako nieistotną przy podejmowaniu decyzji o dostępie — przebywanie w sieci firmowej nie zapewnia domyślnego zaufania. Zamiast uwierzytelniania opartego na obwodzie Kerberos model Zero Trust korzysta z ciągłej weryfikacji tożsamości, kontroli stanu urządzenia i zasad dostępu zgodnego z zasadą najmniejszych uprawnień, egzekwowanych przy każdym żądaniu dostępu do zasobu za pośrednictwem OIDC lub SAML.

Proszę użyć SAML w przypadku starszych aplikacji dla przedsiębiorstw, które powstały przed 2014 rokiem i już obsługują SAML. OIDC należy używać w nowych aplikacjach, aplikacjach mobilnych, aplikacjach jednostronicowych i interfejsach API. Oba standardy są obsługiwane przez głównych dostawców tożsamości, dlatego wybór często zależy od istniejącej obsługi aplikacji, a nie od różnic w bezpieczeństwie. OIDC jest preferowanym wyborem w przypadku całkowicie nowego oprogramowania.

Które stwierdzenie prawidłowo opisuje kluczową różnicę między SAML a OIDC?

SAML 2.0 zapewnia oparte na XML jednokrotne logowanie w tradycyjnych aplikacjach dla przedsiębiorstw. OIDC dodaje tożsamość do OAuth 2.0 za pomocą tokenów JWT i jest preferowany w nowoczesnych aplikacjach. Entra ID obsługuje oba standardy jako hybrydowy dostawca tożsamości w chmurze. AD FS łączy lokalną usługę AD z aplikacjami opartymi na SAML. SCIM automatyzuje aprowizację. Zero Trust zastępuje oparte na obwodzie uwierzytelnianie Kerberos ciągłą weryfikacją tożsamości sterowaną przez zasady.