CAS vs. SAML vs. OAuth2
Zanim postawisz mnie za zadanie zbyt podstawowego pytania bez odrabiania lekcji, chciałbym powiedzieć, że dużo czytam na te tematy, ale nadal jestem zdezorientowany.
Moje potrzeby wydają się dość proste. W mojej firmie mamy kilka aplikacji Ruby on Rails. Chcę zbudować usługę uwierzytelniania SSO, z której powinny korzystać wszystkie te aplikacje.Próbując zrobić jakieś badania, jak to zrobić, czytałem o CAS, SAML i OAuth2. (Wiem, że "Auth" w OAuth oznacza autoryzację, a nie uwierzytelnianie, ale czytałem wystarczająco dużo artykułów mówiących, jak OAuth może być używany do uwierzytelniania - to jest jednym z nich.)
I jest tak wiele klejnotów, które wydają się mówić bardzo podobne rzeczy:
- https://github.com/rubycas/rubycas-server i https://github.com/rubycas/rubycas-client
- https://github.com/nbudin/devise_cas_authenticatable
- https://github.com/onelogin/ruby-saml
- kasyno i https://github.com/rbCAS/casino-activerecord_authenticator
- i jestem pewien, że istnieją setki klejnotów związanych z OAuth.
Chcę tylko oddzielną aplikację Rails, która obsługuje wszystkie uwierzytelnianie dla innych moich aplikacji Rails.
Uwaga: nie chcę zezwalać użytkownikom na korzystanie z ich kont Google / Facebook, aby się zalogować. Nasi użytkownicy mają już konta na naszej stronie. Chcę, aby mogli zalogować się za pomocą tego konta raz i mieć dostęp do wszystkich naszych aplikacji bez logowania się ponownie. Wylogowanie w dowolnej aplikacji powinno wylogować je ze wszystkich aplikacji.
UPDATE
Natknąłem się na te dwa rozwiązania OAuth:- http://dev.mikamai.com/post/110722727899/oauth2-on-rails
- http://blog.yorkxin.org/posts/2013/11/05/oauth2-tutorial-grape-api-doorkeeper-en/
Wydają się opisywać coś bardzo podobnego do tego, czego chcę. Ale nie znalazłem żadnego przewodnika / posta na blogu / samouczka pokazującego, jak to zrobić z SAML / CAS.
Sugestie mile widziane.UPDATE 2
Więcej szczegółów na temat naszego przypadku użycia.
My nie posiadać istniejącą architekturę SAML. Przede wszystkim to nasi użytkownicy (zarejestrowani bezpośrednio na naszej stronie) będą mieli dostęp do wszystkich naszych aplikacji. W przyszłości możemy mieć firmy zewnętrzne (partnerskie), które będą używać naszych interfejsów API. Możemy również mieć użytkowników z tych firm zewnętrznych (partnerskich) (zarejestrowanych na ich stronach internetowych), którzy uzyskują dostęp do naszych aplikacji.
5 answers
Jeśli potrzebujesz uwierzytelnić dla LDAP lub ActiveDirectory wtedy rozwiązanie takie jak jeden z klejnotów CAS , o których wspomniałeś powyżej, jest właśnie dla Ciebie (RubyCAS, Kasyno).
Jeśli Cię na to stać, jeden z komercyjnych sprzedawców (jak Okta) to najlepsza opcja, ponieważ będą one na bieżąco z łatkami zabezpieczeń i zarządzać potrzebami uwierzytelniania dla Ciebie. W szczególności, jeśli musisz wspierać ActiveDirectory, zostały już zaimplementowane to.
OAuth jest najbardziej przydatny do uwierzytelniania osób trzecich, choć może wykonywać SSO. Jeśli więc chcesz wspierać Logowanie Google / Facebook lub być uwierzytelniaczem stron trzecich, to jest to świetny wybór. Ponieważ nie chcesz wspierać Google / Facebook, OAuth prawdopodobnie nie jest tym, czego chcesz.
Jeśli zamierzasz używać tylko HTTP POST dla swoich potrzeb SSO, to perełkaruby-saml może być dobrym rozwiązaniem. Musisz zaimplementować własnego dostawcę tożsamości]} i dodaj komponent usługodawcy do wszystkich swoich stron internetowych (ewentualnie w formie klejnotu.) Częścią tego, czego potrzebujesz, jest api rails, aby działać jako twój dostawca tożsamości . Ten gem pomaga w pisaniu API w rails.
EDIT
Wspominasz o możliwości, że przyszli użytkownicy stron trzecich mogą logować się do twojej witryny. To zmienia Twój rachunek z dala od obracania własnego rozwiązania ruby-saml.
Najlepszy sposób na podzielenie się swoją API uwierzytelniania jest implementacją warstwy OAuth . Doorkeeper jest popularnym rozwiązaniem i szybko staje się standardem uwierzytelniania Rails. Wsparcie społeczności, elastyczność i łatwość użycia sprawiają, że jest to najlepszy sposób na korzystanie z API uwierzytelniania materiałów eksploatacyjnych.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-06-05 15:14:14
CAS-Serwer :
Samodzielna Centralna strona logowania, na której użytkownik wprowadza swoje poświadczenia (tj. nazwę użytkownika i hasło).
CAS wspiera znormalizowany protokół SAML 1.1 przede wszystkim w celu obsługi atrybut release to clients i single sign-out.
(Tabela w bazie danych SQL, ActiveDirectory / LDAP, konta Google itp.) Pełna kompatybilność z otwartym, wieloplatformowym protokołem CAS (klienci CAS są implementowani dla szerokiej gamy platformy, w tym PHP, różne frameworki Java,. NET, Zope , itp.) Lokalizacja wielojęzyczna -- RubyCAS-Server automatycznie wykrywa preferowany język użytkownika i prezentuje odpowiedni interfejs.
SAML : Security Assertion Markup Language to oparty na XML, otwarty format danych do wymiany danych uwierzytelniania i autoryzacji między Stronami, w szczególności między dostawcą tożsamości a dostawcą usług. SAML autoryzacja jest procesem dwuetapowym i oczekuje się, że zaimplementujesz wsparcie dla obu.
OAuth 2.0:
OAuth 2.0 authorization framework umożliwia osobom trzecim
wniosek o uzyskanie ograniczonego dostępu do usługi HTTP, albo na
w imieniu właściciela zasobu, organizując interakcję zatwierdzającą
pomiędzy właścicielem zasobu a usługą HTTP, lub poprzez umożliwienie
wniosek strony trzeciej o samodzielne uzyskanie dostępu w imieniu.
Ważna Uwaga:
SAML ma jedną funkcję, której OAuth2 nie ma: token SAML zawiera informacje o tożsamości użytkownika (z powodu podpisywania). W przypadku OAuth2 nie masz tego po wyjęciu z pudełka, a zamiast tego Serwer zasobów musi wykonać dodatkową podróż w obie strony, aby zweryfikować token za pomocą serwera autoryzacji.
Z drugiej strony, za pomocą OAuth2 możesz unieważnić token dostępu Przy autoryzacji Serwera i wyłączyć go z dalszego dostępu do serwera zasobów.
Oba podejścia mają ładne funkcje i oba będą działać dla SSO. Udowodniliśmy zarówno koncepcje w wielu językach, jak i różnego rodzaju aplikacje. Na koniec dnia OAuth2 wydaje się być lepiej dopasowane do naszych potrzeb (ponieważ nie ma istniejącej infrastruktury SAML do wykorzystania).
OAuth2 zapewnia prostsze i bardziej ustandaryzowane rozwiązanie, które obejmuje wszystkich naszych aktualnych potrzeb i unika wykorzystanie obejść dla współdziałanie z natywnymi aplikacjami.
Kiedy powinienem użyć którego?
1.Jeśli twoja baza usecase obejmuje SSO (gdy przynajmniej jeden podmiot lub uczestnik jest przedsiębiorstwem), użyj SAML.
2.Jeśli twoja baza danych wymaga zapewnienia dostępu (tymczasowego lub stałego) do zasobów (takich jak konta, zdjęcia, pliki itp.), Użyj OAuth.
3.Jeśli musisz zapewnić dostęp do aplikacji partnera lub klienta, aby Twój portal, następnie użyj SAML .
4.Jeśli twoja baza danych wymaga scentralizowanego źródła tożsamości, użyj SAML (dostawcy tożsamości).
5.Jeśli twoja baza danych obejmuje urządzenia mobilne, OAuth2 z jakąś formą tokenów na okaziciela jest odpowiednia.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:34:37
Anjan.
Używałem CAS i OAuth w mojej pracy. Oto niektóre z moich opinii i mam nadzieję pomóc.
Zasadniczo
- ZARÓWNO CAS, jak i SAML mają na celu rozwiązanie sytuacji SSO. A CAS to usługa lub system uwierzytelniania, który może obsługiwać protokół SAML. OAuth ma na celu rozwiązanie problemu autoryzacji i uwierzytelniania.
I w praktyce
- Zarówno CAS, jak i SAML działają jako brama przed grupą aplikacji należących do jednej organizacji. Tak jak w twojej sprawie.
- OAuth jest używany do autoryzacji i uwierzytelniania między różnymi organizacjami.
Tylko moje myśli i mam nadzieję usłyszeć więcej głosów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-06-02 08:36:48
Wykorzystaliśmy CAS i SAML w naszej architekturze (aplikacja mobilna, Portal Internetowy i mikroserwisy) i oba są używane do różnych celów.
Nasz Portal internetowy jest jak bankowość internetowa, która działa w domenie publicznej i musi być bezpieczna. Nie chcemy przechowywać hasła i innych bezpiecznych tokenów w DB portalu online, dlatego używamy CAS do uwierzytelniania i autoryzacji. Podczas rejestracji, gdy użytkownik wybierze hasło, przechowujemy hasło w CAS i przechowujemy odpowiedni token w DB portalu
Przy następnym logowaniu użytkownik wprowadza nazwę użytkownika i hasło w portalu. Portal pobiera token odpowiadający użytkownikowi z DB i wysyła nazwę użytkownika, hasło i token do CAS w celu weryfikacji.
Ale, w przypadku, gdy użytkownik jest już zalogowany w jednej aplikacji i przekierowujemy użytkownika do naszej innej aplikacji, to nie chcemy, aby użytkownik ponownie wprowadzić nazwę użytkownika i hasło dla drugiej aplikacji. Wykorzystamy SAMLA do rozwiązania tego problemu. Pierwsza aplikacja udostępnia dane użytkownika SAML serwer i dostaje token w zamian. Pierwsza aplikacja przekazuje token do drugiej aplikacji. Druga aplikacja wysyła token do serwera SAML, aby uzyskać dane użytkownika i po sukcesie ląduje użytkownika na żądanej stronie. Naszą pierwszą aplikacją może być aplikacja mobilna, a drugą Portal w scenariuszu App2Web.
Ponieważ masz wiele odpowiedzi na to pytanie, chciałbym zaproponować Ci produkt tożsamości, który może zaspokoić tego rodzaju wszystkie protokoły w jednej ręce z wieloma funkcjami uwierzytelniania i zarządzania użytkownikami. Możesz po prostu wypróbować WSO2 Identity Server version w tym celu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-11-03 03:10:06