Logowanie jednokrotne z CAS lub OAuth?

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

Przykładowy scenariusz:

1. Użytkownik próbuje uzyskać dostęp do chronionego zasobu, ale nie jest uwierzytelniony.
2. Aplikacja przekierowuje użytkownika na serwer SSO.
3. W przypadku uwierzytelnienia użytkownik otrzymuje token z serwera SSO.
4. SSO przekierowuje do oryginalnej aplikacji.
5. Oryginalna aplikacja sprawdza token na serwerze SSO.
6. Jeśli token jest prawidłowy, dostęp zostanie udzielony, a aplikacja będzie znała identyfikator użytkownika.
7. Użytkownik dokonuje wylogowania i zostaje wylogowany ze wszystkich połączonych aplikacji w tym samym czasie (wylogowanie jednokrotne).

O ile rozumiem, właśnie po to został wymyślony CAS. Klienci CAS muszą zaimplementować protokół CAS, aby korzystać z usługi uwierzytelniania. Teraz zastanawiam się nad używaniem CAS lub OAuth w witrynie klienta (konsumenta). Czy OAuth zastępuje tę część CAS? Czy należy preferować OAuth jako nowy faktyczny standard? Czy istnieje łatwy w użyciu (nie Sun OpenSSO!) Zamiennik części uwierzytelniającej CAS obsługujący różne metody, takie jak nazwa użytkownika / hasło, OpenID, certyfikaty TLS ...?

Kontekst:

• Różne aplikacje powinny polegać na uwierzytelnianiu serwera SSO i powinny używać czegoś podobnego do sesji.
• Aplikacje mogą być aplikacjami sieciowymi GUI lub usługami (REST).
• Serwer SSO musi mieć identyfikator użytkownika, który jest niezbędny, aby uzyskać więcej informacji o użytkowniku, takich jak role, poczta e-mail itp. Z centralnego magazynu informacji o użytkowniku.
• Pojedyncze wylogowanie powinno być możliwe.
• Większość klientów jest napisana w języku Java lub PHP.

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

Uzupełnienie

Dowiedziałem się, że OAuth nie został zaprojektowany do uwierzytelniania, nawet może być używany do implementacji SSO, ale tylko razem z usługą SSO, taką jak OpenID.

Wydaje mi się, że OpenID to „nowy CAS”. CAS ma pewne funkcje, które pomija OpenID (takie jak pojedyncze wylogowanie), ale dodanie brakujących części w określonym scenariuszu nie powinno być trudne. Myślę, że OpenID ma szeroką akceptację i lepiej jest zintegrować OpenID z aplikacjami lub serwerami aplikacji. Wiem, że CAS obsługuje również OpenID, ale myślę, że CAS jest zbędny w przypadku OpenID.

OpenID nie jest „następcą” ani „substytutem” CAS, są one różne pod względem intencji i 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 jeden serwer CAS).

OpenID decentralizuje uwierzytelnianie. Użyj go, jeśli chcesz, aby Twoja aplikacja akceptowała logowanie użytkowników do dowolnej usługi uwierzytelniania, jakiej chcą (użytkownik podaje adres serwera OpenID - w rzeczywistości „nazwa użytkownika” to adres URL serwera).

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

OAuth obsługuje autoryzację, ale nie zastępuje tradycyjnej „tabeli USER_ROLES” (dostęp użytkownika). Obsługuje autoryzację stron trzecich.

Na przykład chcesz, aby Twoja aplikacja była zintegrowana z Twitterem: użytkownik może pozwolić jej na automatyczne tweetowanie, gdy aktualizuje swoje dane lub publikuje nowe treści. Chcesz uzyskać dostęp do usług lub zasobów strony trzeciej w imieniu użytkownika, bez uzyskiwania jego hasła (co jest oczywiście niebezpieczne dla użytkownika). Aplikacja prosi Twittera o dostęp, użytkownik go autoryzuje (przez Twittera), po czym aplikacja może mieć dostęp.

Tak więc OAuth nie dotyczy jednokrotnego logowania (ani nie zastępuje protokołu CAS). Nie chodzi o to, abyś kontrolował, do czego użytkownik ma dostęp. Chodzi o umożliwienie użytkownikowi kontrolowania sposobu, w jaki osoby trzecie mogą uzyskać dostęp do swoich zasobów. Dwa bardzo różne przypadki użycia.

W opisanym przez ciebie kontekście CAS jest prawdopodobnie właściwym wyborem.

[zaktualizowano]

To powiedziawszy, możesz zaimplementować logowanie jednokrotne z OAuth, jeśli uważasz tożsamość użytkownika za zabezpieczony zasób. Tak właśnie działa „Zarejestruj się w GitHubie” i polubienia. Prawdopodobnie nie było to pierwotne zamierzenie protokołu, ale można to zrobić. Jeśli kontrolujesz serwer OAuth i ograniczysz aplikacje do uwierzytelniania się tylko za jego pomocą, oznacza to logowanie jednokrotne.

Nie ma jednak standardowego sposobu wymuszenia wylogowania (CAS ma tę funkcję).

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

Użyj CAS, jeśli kontrolujesz / jesteś właścicielem systemu uwierzytelniania użytkowników i potrzebujesz obsługi heterogenicznego zestawu serwerów i aplikacji, które wymagają scentralizowanego uwierzytelniania.

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

OpenID to protokół uwierzytelniania, OAuth i OAuth WRAP to protokoły autoryzacyjne. Można je łączyć z hybrydowym rozszerzeniem OpenID .

Zdecydowanie wolałbym, aby ludzie budowali na najwyższych standardach, które mają duży rozmach (bardziej dostępne wsparcie, łatwiejsze do zaangażowania strony trzecie), nawet jeśli nie są one dokładnie dopasowane do danej aplikacji. W tym przypadku OAuth ma rozpęd, a nie CAS. Powinieneś móc zrobić wszystko lub przynajmniej prawie wszystko, co musisz zrobić z OAuth. W późniejszym czasie OAuth WRAP powinien jeszcze bardziej uprościć sprawę (wymaga pewnych kompromisów, używając tokena okaziciela i przenosząc szyfrowanie do warstwy protokołu), ale nadal jest w powijakach, a tymczasem OAuth prawdopodobnie wykona pracę dobrze.

Ostatecznie, jeśli zdecydujesz się korzystać z OpenID i OAuth, będzie więcej bibliotek dla większej liczby języków dostępnych dla Ciebie i dla każdego, kto musi zintegrować się z systemem. Masz też dużo więcej gałek ocznych, które przyglądają się protokołom, upewniając się, że naprawdę są tak bezpieczne, jak powinny.

Dla mnie prawdziwą różnicą między SSO a OAuth jest przyznanie, a nie uwierzytelnianie, ponieważ serwer, który implementuje OAuth, oczywiście ma uwierzytelnianie (musisz być zalogowany do Google, openId lub facebook, aby OAuth działało z aplikacją klienta)

W przypadku logowania jednokrotnego użytkownik zaawansowany / administrator systemu przyznaje wcześniej użytkownikowi końcowemu dostęp do aplikacji w „aplikacji logowania jednokrotnego”. W przypadku protokołu OAuth użytkownik końcowy przyznaje aplikacji dostęp do swoich „danych” w „aplikacji OAuth”

Nie rozumiem, dlaczego nie można użyć protokołu OAuth jako części serwera logowania jednokrotnego. Po prostu usuń ekran grantu z przepływu i pozwól serwerowi OAuth na wyszukanie grantu z bazy danych wspierającej.

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

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