SAML a logowanie federacyjne przy użyciu protokołu OAuth

Jaka jest różnica między SAML a logowaniem sfederowanym przy użyciu OAuth? Które rozwiązanie jest bardziej sensowne, jeśli firma chce korzystać z aplikacji internetowej innej firmy, ale chce również korzystać z jednokrotnego logowania i być organem uwierzytelniającym?

Rozwiązują różne problemy.

SAML to zestaw standardów, które zostały zdefiniowane w celu udostępniania informacji o tym, kim jest użytkownik, jakie są jego atrybuty, oraz umożliwiają udzielenie / odmowę dostępu do czegoś, a nawet zażądanie uwierzytelnienia.

OAuth bardziej polega na przekazywaniu dostępu do czegoś. Zasadniczo pozwalasz komuś „działać” jak ty. Jest najczęściej używany do przyznawania api dostępu, które mogą zrobić coś w Twoim imieniu.

To dwie zupełnie różne rzeczy.

Kilka przykładów, które mogą pomóc.

OAuth pomyśl o Twitterze. Powiedzmy, że używasz usługi Google Buzz i Twittera i chcesz napisać aplikację, która umożliwi ich synchronizację. Zasadniczo możesz ustanowić zaufanie między swoją aplikacją a Twitterem. Gdy po raz pierwszy łączysz aplikację z twitterem, wykonujesz klasyczny monit, aby zalogować się do Twittera, a następnie pojawia się okno potwierdzenia i pyta „Czy chcesz przyznać dostęp do« nazwa Twojej aplikacji »?” gdy klikniesz „tak”, zaufanie zostało ustanowione i teraz Twoja aplikacja może działać tak jak Ty na Twitterze. Może czytać Twoje posty, a także tworzyć nowe.

SAML - w przypadku SAML pomyśl o pewnym rodzaju „umowy” między dwoma niepowiązanymi systemami członkostwa. W naszym przypadku możemy skorzystać z linii US Airways i Hertz. Nie ma wspólnego zestawu danych uwierzytelniających, które mogłyby przenieść Cię z jednej witryny do drugiej, ale powiedzmy, że Hertz chce zaoferować „umowę” US Airways. (Zgoda, wiem, że to skrajny przykład, ale proszę o cierpliwość). Po zakupie lotu zaoferują członkom przewodniczącego bezpłatny wynajem samochodu. US Airways i Hertz ustanowią jakąś formę zaufania i jakiś sposób identyfikacji użytkownika. W naszym przypadku naszym „federacyjnym identyfikatorem” byłby adres e-mail i byłby to jednokierunkowy zestaw zaufania Hertz ufa, że ​​dostawca tożsamości US Airways dostarczy token, który jest dokładny i bezpieczny. Po zarezerwowaniu lotu dostawca tożsamości US Airways wygeneruje token i zapisze sposób uwierzytelnienia użytkownika, a także „atrybuty” dotyczące osoby, w naszym przypadku najważniejszym atrybutem byłby jej status w US Airways. Po wypełnieniu token przekazuje go przez jakiś rodzaj odniesienia lub zakodowany w adresie URL, a gdy dotrzemy do Hertz, patrzy na token, sprawdza go i może teraz pozwolić na bezpłatne wypożyczenie samochodu.

Problem z tym przykładem SAML polega na tym, że jest to tylko jeden z wielu specjalistycznych przypadków użycia. SAML jest standardem i jest prawie zbyt wiele sposobów na jego implementację.

Alternatywnie, jeśli nie dbasz o autoryzację, możesz prawie spierać się, że zapewnia uwierzytelnianie przez SAML i OpenID .

Spójrz na to proste wyjaśnienie podsumowane tutaj:

Wiele osób nie rozumie różnic między SAML, OpenID i OAuth, ale w rzeczywistości jest to bardzo proste. Chociaż istnieje pewne pokrywanie się, tutaj jest bardzo prosty sposób na rozróżnienie tych trzech.

OpenID - logowanie jednokrotne dla konsumentów

SAML - logowanie jednokrotne dla użytkowników korporacyjnych

OAuth - autoryzacja API między aplikacjami

Dla osób, które czują się dobrze z wzorami projektowymi OO, myślę, że istnieje fajny następstwo wzorów zawijania . Pomyśl o wzorach elewacji , dekoratora i proxy . Zasadniczo wszystkie są takie same, to po prostu opakowania ... Różnica polega na intencji każdego wzoru .

Podobnie SAML, OAuth i OpenID ułatwiają różne intencje za pośrednictwem wspólnego mechanizmu bazowego , którym jest przekierowanie do dostawcy usług / urzędu tożsamości w celu przeprowadzenia jakiejś prywatnej interakcji, a następnie przekierowanie do źródłowej aplikacji innej firmy.

Rozglądając się po sieci, zauważysz, że możliwości protokołów pokrywają się. Uwierzytelnianie przez OAuth jest całkowicie uzasadnione. Logowanie jednokrotne przez OAuth może nie mieć większego sensu, ponieważ SAML i OpenID są specjalnie przystosowane do tożsamości federacyjnej.

Jeśli chodzi o samo pytanie, w kontekście korporacyjnym SAML wydaje się bardziej odpowiedni niż OAuth do logowania jednokrotnego . Założę się, że jeśli spojrzysz na aplikacje innych firm, które chcesz zintegrować z tożsamościami korporacyjnymi, okaże się, że są one już zaprojektowane do integracji z SAML / LDAP / Radius itp. IMO OAuth jest bardziej odpowiedni do interakcji z Internetem między aplikacjami lub aplikacjami składającymi się na architekturę zorientowaną na usługi w dużym środowisku korporacyjnym.

Reguły autoryzacji można określić w środowisku korporacyjnym także na inne sposoby. LDAP jest do tego typowym narzędziem. Organizowanie użytkowników w grupy i kojarzenie uprawnień aplikacji z członkostwem w grupie jest szeroko rozpowszechnionym podejściem. Tak się składa, że ​​LDAP może być również używany do uwierzytelniania. Active Directory to świetny przykład, chociaż wolę OpenLDAP.

Obsługują subtelny przypadek użycia

• SAML - udostępnianie danych logowania (np. SSO) użytkownika różnym dostawcom usług (np. Sieci lub usługi sieciowej)
• OAuth - użytkownik delegujący aplikację do dostępu do zasobu w swoim imieniu

Znaleziono dobry artykuł tutaj

SAML (Security Assertion Markup Language) to zestaw standardów umożliwiających osiągnięcie jednokrotnego logowania (SSO), federacji i zarządzania tożsamością.

Przykład : użytkownik (główny) uwierzytelnia się w witrynie rezerwacji lotów, AirFlyer (dostawca tożsamości), który ma skonfigurowane logowanie jednokrotne przez SAML w witrynie rezerwacji transportu wahadłowego, Shuttler (dostawca usług). Po uwierzytelnieniu w serwisie Flyer użytkownik może zarezerwować transport wahadłowy w Shuttler bez konieczności uwierzytelniania

OAuth (Open Authorization) to standard autoryzacji zasobów. Nie dotyczy uwierzytelniania.

Przykład : aplikacja mobilna do udostępniania zdjęć (klient OAuth), która umożliwia użytkownikom importowanie zdjęć z ich konta na Instagramie (dostawca OAuth), które wysyła tymczasowy token dostępu lub klucz do aplikacji do udostępniania zdjęć, który wygasa po kilku godzinach.

SAML ma różne „profile” do wyboru, które pozwalają innym użytkownikom „logować się” w Twojej witrynie. SAML-P lub SAML Passive są bardzo popularne i dość proste w konfiguracji. WS-Trust jest podobny i również pozwala na federację między stronami internetowymi.

OAuth służy do autoryzacji. Możesz przeczytać więcej tutaj:

Jaka jest różnica między OpenID a OAuth?

SAMLsłuży do uwierzytelniania - używany głównie w scenariuszu Single Sign On . OAuthsłuży do autoryzacji reprezentacji zasobów.

Token sieciowy JSON (JWT) to alternatywa dla tokenów SAML XML. JWT może być używany z OAuth

Dobre odniesienie to SAML i OAuth: którego użyć?

Termin federacja naprawdę oznacza tożsamości połączeń między systemami. Jest to związane z SSO, ale nie są one takie same. Uważam, że ten wpis na blogu jest naprawdę pomocny w kwestii tego, co naprawdę oznacza federacja.