SSO z CAS czy OAuth?

Question

SSO z CAS czy OAuth?

Zastanawiam się, czy powinienem używać CAS Protokołu lub OAuth + jakiegoś dostawcy uwierzytelniania dla pojedynczego logowania.

Przykładowy Scenariusz:

użytkownik próbuje uzyskać dostęp do chronionego zasobu, ale nie jest uwierzytelniony.
aplikacja przekierowuje użytkownika na serwer SSO.
jeśli beeing uwierzytelniony, użytkownik otrzymuje token z serwera SSO.
SSO przekierowuje do oryginalnej aplikacji.
oryginalna aplikacja sprawdza token przeciwko serwerowi SSO.
Jeśli token jest w porządku, dostęp będzie dozwolony, a aplikacja zna identyfikator użytkownika.
użytkownik dokonuje wylogowania i jest wylogowany ze wszystkich podłączonych aplikacji w tym samym czasie (single sign-out).

Z tego co rozumiem, po to właśnie wynaleziono CAS. Klienci CAS muszą zaimplementować protokół CAS, aby korzystać z usługi uwierzytelniania. Teraz zastanawiam się nad użyciem CAS lub OAuth na stronie klienta (konsumenta). Na OAuth zamiennikiem tej części CAS? Czy OAuth jako nowy standard de facto powinien być preferowany? Czy jest łatwy w użyciu (nie Słońce OpenSSO!) zastępowanie części uwierzytelniania CAS obsługującej różne metody, takie jak nazwa użytkownika/hasło, OpenID, TLS certifactes ...?

Kontekst:

różne aplikacje powinny polegać na uwierzytelnianiu serwera SSO i powinny używać czegoś podobnego do sesji.
aplikacje mogą być aplikacjami webowymi GUI lub (REST) seriale
serwer SSO musi mieć identyfikator użytkownika, który jest niezbędny, aby uzyskać więcej informacji o użytkowniku, takich jak role, e-mail i tak dalej z centralnego magazynu informacji o użytkowniku.
jednorazowe wylogowanie powinno być możliwe.
większość klientów jest napisana w Javie lub PHP.

Właśnie odkryłem WRAP , który może zostać następcą OAuth. Jest to nowy protokół określony przez Microsoft, Google i Yahoo.

Dodatek

I ' ve dowiedział się, że OAuth nie jest przeznaczony do uwierzytelniania, nawet może być używany do implementacji SSO, ale tylko razem z usługą SSO, taką jak OpenID.

OpenID wydaje mi się być"nowym CAS". CAS ma pewne funkcje OpenID misses (jak single sign-out), ale nie powinno być trudno dodać brakujące części w danym scenariuszu. OpenID OpenID ma szeroką akceptację i lepiej jest zintegrować OpenID z aplikacjami lub serwerami aplikacji. Wiem, że CAS wspiera również OpenID, ale myślę, że CAS jest zbędny z OpenID.

168

security oauth single-sign-on cas

Author: deamon, 2010-01-09

Source

5 answers

Myślę o tym w ten sposób:

Użyj CAS, jeśli kontrolujesz / posiadasz system uwierzytelniania użytkownika i musisz obsługiwać heterogeniczny zestaw serwerów i aplikacji, które wymagają centralnego uwierzytelniania.

Użyj OAuth, jeśli chcesz wspierać uwierzytelnianie użytkowników z systemów, których nie posiadasz/Nie obsługujesz (np. Facebook, Google, itp.).

44

Author: Lance Weber,
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
2010-01-13 18:07:37

OpenID jest protokołem uwierzytelniania, OAuth i OAuth WRAP są protokołami autoryzacji. Można je łączyć z hybrydowym rozszerzeniem OpenID.

Zdecydowanie wolałbym, aby ludzie opierali się na standardach, które mają dużo rozmachu (bardziej dostępne wsparcie, łatwiej zaangażować strony trzecie), nawet jeśli nie są dokładnie dopasowane do danej aplikacji. W tym przypadku OAuth ma rozmach, a nie CAS. Powinieneś być w stanie zrobić wszystko a przynajmniej prawie wszystko, co musisz zrobić z OAuth. W pewnym późniejszym momencie w przyszłości owijanie OAuth powinno jeszcze bardziej uprościć sprawy (czyni pewne wartościowe kompromisy, używając tokena na okaziciela i przesuwając szyfrowanie w dół do warstwy protokołu), ale nadal jest w powijakach, a w międzyczasie OAuth prawdopodobnie wykona tę pracę dobrze.

Ostatecznie, jeśli zdecydujesz się użyć OpenID i OAuth, jest więcej bibliotek dla większej liczby języków dostępnych dla Ciebie i dla każdego, kto potrzebuje integracja z systemem. Masz też dużo więcej oczu patrząc na protokoły, upewniając się, że naprawdę są tak bezpieczne, jak powinny być.

13

Author: Bob Aman,
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
2010-03-03 16:18:11

Stary post, ale to może się przydać:

CAS 3.5 będzie obsługiwał oAuth jako klienta i serwera. Zobacz: https://wiki.jasig.org/display/CASUM/OAuth

6

Author: Bertl,
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
2012-04-19 11:08:26

Dla mnie prawdziwa różnica między SSO a OAuth to grant, a nie uwierzytelnianie Facebook, openId lub Google, aby OAuth mógł działać z aplikacją kliencką, musisz być zalogowany na swoim serwerze, który implementuje OAuth, oczywiście ma uwierzytelnianie ]}

W SSO, zaawansowany użytkownik / sysadmin przyznaje użytkownikowi końcowemu dostęp do aplikacji wcześniej w "aplikacji SSO" W OAuth użytkownik końcowy przyznaje aplikacji dostęp do swoich "danych" w "aplikacji OAuth"

I don ' t see why OAuth protokół nie może być używany jako część serwera SSO. Po prostu wyjmij ekran dotacji z flow i pozwól serwerowi OAuth wyszukać dotację z bazy danych.

4

Author: redben,
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
2018-10-02 08:51:27

score 220 · Accepted Answer

OpenID nie jest 'następcą ' lub' substytutem ' CAS, są one inne, w zamiarze i w implementacji.

CAS centralizuje uwierzytelnianie. Użyj go, jeśli chcesz, aby wszystkie Twoje (prawdopodobnie wewnętrzne) aplikacje prosiły użytkowników o zalogowanie się na jednym serwerze (wszystkie aplikacje są skonfigurowane tak, aby wskazywały na jeden serwer CAS).

OpenID decentralizuje uwierzytelnianie . Użyj go, jeśli chcesz, aby aplikacja akceptowała użytkowników logujących się do dowolnej usługi uwierzytelniania, którą chcą (użytkownik podaje adres serwera OpenID - w rzeczywistości 'username' jest adresem URL serwera).

Żaden z powyższych nie obsługuje autoryzacji (bez rozszerzeń i / lub dostosowywania).

OAuth obsługuje autoryzację, ale nie zastępuje tradycyjnej tabeli 'user_roles' (dostęp Użytkownika). Obsługuje autoryzację dla osób trzecich.

Na przykład chcesz, aby Twoja aplikacja zintegrowała się z Twitterem: użytkownik może zezwolić mu na automatyczne tweetowanie po aktualizacji swoich danych lub publikować nowe treści. Chcesz uzyskać dostęp do jakiejś usługi lub zasobu innej firmy w imieniu Użytkownika, bez uzyskania jego hasła (które jest oczywiście niezabezpieczone dla użytkownika). Aplikacja prosi Twittera o dostęp, użytkownik autoryzuje go (za pośrednictwem Twittera), a następnie aplikacja może mieć dostęp.

Tak więc OAuth nie polega na jednokrotnym logowaniu (ani na zastępstwie protokołu CAS). Nie chodzi o ty kontrolowanie dostępu użytkownika. Chodzi o pozwolenie na Użytkownik do kontrolowania, w jaki sposób ich zasoby mogą być dostępne dla osób trzecich. Dwa bardzo różne przypadki użycia.

W kontekście, który opisałeś, CAS jest prawdopodobnie właściwym wyborem.

[Aktualizacja]

To powiedziawszy, możesz zaimplementować SSO z OAuth, jeśli uznasz tożsamość użytkownika za zabezpieczony zasób. To właśnie robią "Zarejestruj się na GitHub" i podobają mi się, w zasadzie. Prawdopodobnie nie jest to pierwotna intencja Protokołu, Ale można to zrobić. Jeśli kontrolujesz Serwer OAuth, i ograniczyć aplikacje tylko uwierzytelniać z nim, to SSO.

Brak jednak standardowego sposobu wymusić wylogowanie(CAS ma tę funkcję).