Wieloplatformowe logowanie jednokrotne - od czego zacząć?

Question

Badam opcje pojedynczego logowania między dwoma odmiennymi systemami: jeden .NET, jeden Java EE. Każdy z nich zarządzany jest niezależnie i ma osobne zarządzanie użytkownikami, z niektórymi nakładającymi się użytkownikami.

Chciałbym móc linkować z jednego do drugiego bez ponownego pytania o hasło.

Wygląda na to, że istnieje wiele opcji produktów SSO i protokołów tam. Jestem pewien, że mógłbym zakodować jednorazowe, aby wygenerować i zweryfikować własne bezpieczne tokeny, ale wolałbym nie wymyślać ponownie koła.

Co byś polecił pod względem podejścia i/lub produktu (najlepiej open source)?

Po pierwsze, czy skorzystasz z czegoś, co obsługuje SAML, OpenID, OAuth lub żaden z powyższych?

Po drugie, z produktów darmowych/o otwartym kodzie źródłowym, jestem świadomy OpenAM, Shibboleth, JOSSO i CAS. Jakieś doświadczenia, którymi można się podzielić z każdym z nich, dobrym, złym czy brzydkim?

Answer 1

pierwsze pozwala spojrzeć na protokołów:

1. SAML 2,0 jest scentralizowaną zdecentralizowane Protocol/OSM. Jest to najbardziej zaawansowany protokół i oferuje federację, tzn. Można zezwolić użytkownikom na logowanie się przy użyciu dowolnego systemu X lub przekazywanie wszystkich użytkowników za pośrednictwem pojedynczego systemu (znanego jako IDP). SAML 2.0 jest szeroko stosowany w sektorze finansowym i administracyjnym wraz z niektórymi głównymi aplikacjami hostowanymi (na przykład aplikacje Google i Salesforce). Jest to także najbardziej skomplikowane protokół

2. OpenID jest zdecentralizowanym protokół i jest najbardziej odpowiednia do internetu, nie intranet/extranet aplikacji. Użytkownicy mogą rejestrować się pod dowolnym numerem dostawcy OpenId pod numerem . Stackoverflow to dobry przykład OpenId - my możemy zalogować się przy użyciu naszego konta Google lub Facebook. Możesz wdrożyć OpenId w sposób scentralizowany, wymuszając domyślne skojarzenie między aplikacją zużywającą (znaną jako strona odsyłająca ) a systemem SSO (znanym jako dostawca usług).

3. OAuth nie jest tak naprawdę protokołem SSO. Pozwala to użytkownikowi na przyznanie dostępu do jego informacji w Aplikacji B bez podania podania poświadczeń dla Aplikacji B do Aplikacji A. Niektórzy użytkownicy wykorzystali OAuth jako formę uwierzytelniania pseudo, tj. Jeśli system jest w stanie uzyskać dostęp do zdjęć należący do użytkownika X, wówczas użytkownik musi mieć X. Jest to haker i nie jest zalecany.

Jest to z pewnością dobry pomysł, aby pójść ze znormalizowanym protokołem aby uniknąć blokady w. Microsoft wprowadziła niedawno wsparcie dla SAML 2.0 i istnieje wiele open source i komercyjne produkty dostępne dla Java. Dostępne są implementacje OpenId dla java, ale nie wiem wystarczająco dużo o świecie .NET, aby skomentować.

Jak już wspomniano, dostępnych jest wiele produktów SAML o otwartym kodzie źródłowym (OpenAM, Shibboleth, JOSSO i CAS).Jedna uwaga - SAML jest złożonym protokołem, więc jeśli przejdziesz na ścieżkę open source, będziesz musiał przygotować się na ciężką pracę. Kiedy zbudowaliśmy naszą platformę SSO Cloudseal (opartą na SAML 2.0) spędziliśmy dużo czasu próbując uprościć rzeczy, aby zmniejszyć złożoność. Inni komercyjni dostawcy zrobili to samo, ale produkty open source, o których wspomniałeś, są bardziej skoncentrowane na funkcjonalności niż na prostocie - IMHO! :)