Proste SSO - korzystanie z uwierzytelniania niestandardowego-CAS lub jakiÅ› serwer OAuth lub openid?

Mogę odpowiedzieć na niektóre pytania dotyczące CAS, ponieważ korzystałem z nich wcześniej. Nie mam doświadczenia z OAuth i dlatego Nie będę komentować tego.

Po pierwsze, nie rozumiem potrzeby tokenowej weryfikacji CAS, do czego to służy?

CAS jest używany do celów SSO. Jest używany, gdy masz wiele aplikacji (aplikacje komputerowe / webapps na różnych TLD), które chcą zrobić uwierzytelnianie z jednego źródła.

Czy jest bezpieczniej? Zauważam, że jest oparty na przekierowaniach, a zatem równie podlega atakowi man-in-the-middle, tak jak "niestandardowy" serwer auth bez dodatkowego etapu weryfikacji tokenu. Czy coś mnie ominęło dla ochrony w CAS?

Serwery uwierzytelniania używają SSL, aby zapobiec atakom MitM. Ale nie widzę, jak to specyficzny problem z SSO / CAS, ponieważ miałbyś ten sam problem, nawet jeśli aplikacja robi własne uwierzytelnianie. Może powiesz nam, jakiego rodzaju atakami MitM się martwisz o konfiguracji CAS

Czy celem tokenów jest zapewnienie pojedynczego wylogowania i / lub limitu czasu? (Nie chcemy tego, nasi użytkownicy by nas znienawidzili.) Przyglądałem się CAS, ponieważ jest kilka niesamowitych implementacji Ruby, ale nie jestem pewien, czy tego potrzebujemy.

Tokeny są tylko sposobem, aby aplikacja uwierzytelniła Cię bez posiadania hasła. Są to krótkie żywotność / pojedynczy używany token, który jest powiązany z poświadczeniami użytkownika. Wniosek zapewnia token do serwera CAS i odpowiedź serwera CAS z poświadczeniem, jeśli jest z nim powiązany. Możliwe jest wdrożenie pojedynczego logowania i limitu czasu, ale nie jest to bezpośrednio związane z posiadaniem tokenów.

Mam nadzieję, że to jasne. Chciałem to wyjaśnić na wysokim poziomie. Możesz poprosić o szczegóły, jeśli jest jakaś część, która nie jest jasna lub chcesz uzyskać więcej szczegółów.

EDIT: znalazłem lepsze proste wyjaśnienie jak działa CAS w http://www.jasig.org/cas/proxy-authentication (reszta strony mówi o uwierzytelnianiu proxy. Co jest bardziej złożone, ale kilka pierwszych akapitów jest prostym przypadkiem, o którym tutaj mówimy)

Idę do mojej instancji portalu. Przekierowuje mnie do CAS, aby się zalogować. CAS wykrywa mój Bezpieczny plik cookie i dokonuje jednokrotnego logowania, dzięki czemu nie muszę ponownie podawać nazwy użytkownika i hasła. CAS przekierowuje mnie z powrotem do portalu. Portal sprawdza bilet, loguje mnie do Portal widzę mój domyślny układ wypełniony fajnymi kanałami mówiącymi mi, że na zewnątrz jest naprawdę zimno i co jest w wiadomościach.

Zauważ, że portal nie dostał mojego hasła.

Jest to oparte na moim doświadczeniu: SSO (Single sign on) dotyczy dwóch scenariuszy:- i) znam cię bardzo dobrze (dwie strony zaangażowane) ii) Hey friend, meet my friend (three parties involved)

Oczywiście, drugi scenariusz wymaga mechanizmu przekierowania / przekazania, ponieważ zazwyczaj strona trzecia jest tylko scentralizowaną usługą uwierzytelniania / autoryzacji.

Teraz, implementacja mądry, SSO wymaga dwóch obszarów do oceny: -

A) Jak różne strony / Systemy (czy wewnętrzne/zewnętrzne do danej organizacji) zarządzają poświadczeniami użytkowników. To się nazywa zarządzanie tożsamością.

B) jak informacje SSO powinny przepływać między stronami? Ofcouse bezpiecznie w większości scenariuszy.

Myślę, że zarządzanie tożsamością jest ważniejsze niż określanie, jak bezpiecznie przekazywać informacje, ponieważ w przypadku drugiej części dostępnych jest wiele technik szyfrowania / deszyfrowania. Jest to zarządzanie niestandardowe, które jest niespotykanie różne w jednym zestawie systemów obsługujących SSO.

Teraz Tożsamość zarządzanie może być zaimplementowane za pomocą prostego identyfikatora użytkownika (jeśli jest on dostępny we wszystkich uczestniczących systemach), lub za pomocą opracowanej przez siebie zawartości XML,lub SAML payload, lub tokena strony trzeciej. Myślę, że token jest tylko ogólnym terminem odnoszącym się do kontenera zawierającego poświadczenia użytkownika w bezpieczny sposób, a także informacje o niektórych zastosowanych procedurach bezpieczeństwa.

@Ole, biorąc pod uwagę powyższe podstawy SSO (z mojej perspektywy), myślę, że powinieneś skoncentrować się bardziej na tym, jak użytkownicy i ich role są zidentyfikowane w wielu systemach tj. w Twoim przypadku: - Sklep użytkowników, open outh2 provider; więc umieścić więcej myślenia o zarządzaniu tożsamością.

Jednym z rozwiązań może być (w zależności od budżetu i czasu), Twoje przedsiębiorstwo może poświęcić wysiłek na stworzenie wewnętrznego scentralizowanego interfejsu uwierzytelniania w postaci standardowych technologii integracyjnych dla np. usługi internetowej, a za tymi API możesz mieć dowolną implementację: własnego dostawcy lub OAuth strony trzeciej lub mieszane obu. Możesz wdrożyć warstwa silnika pomiędzy Twoim API a warstwą dostawcy, która jest decydentem. Na przykład silnik może mieć domenę aplikacji i odpowiednie mapowanie dostawcy auth. W ten sposób będziesz miał jednolity interfejs uwierzytelniania dla wszystkich klientów.

Client -- > in-house scentralizowane API -- > Engine --> Auth provider(s) pozwól, że podam ci przykład:- i) możesz mieć odsłonięty Webservice, o nazwie może być singleSigonService. XML payload może wyglądać następująco: -

<SingleSignOnReqType>   <sourceID>XYZ</sourceID>    <source-domain>my-java-app.com</source-domain>  <user-credentials>...</<user-credentials>
        <security-credentials>...</<security-credentials> </SingleSignOnReqType>

Ii) klient usługi internetowej byłby wywołaj SSO do scentralizowanej warstwy silnika (zaimplementowanej w dowolnej technologii), która może wykonywać walidacje i księgowość i może być oparta na domenie źródłowej (np. my-java-app.com) w przychodzącym XML będzie delegować żądanie do dostawcy Oauth2, takiego jak facebook-connect. Tak więc twój silnik, decydent, będzie zarządzał regułami uwierzytelniania, jak wspomniałeś w wymaganiach.

Więc zasadniczo wszystkie aplikacje konsumenckie będą miały ujednolicony interfejs oparty na usługach internetowych do twojego SSO rozwiązanie.To jest to, co mam na myśli w domu scentralizowane API.