2010-04-02 12 views
12

Od ponad miesiąca staram się zrozumieć, jak ten problem został rozwiązany. Naprawdę muszę wymyślić ogólne podejście do pracy. Mam pewną teorię, ale nie jestem pewna, czy jest to najłatwiejsze (lub poprawne) podejście i nie byłem w stanie znaleźć żadnych informacji, które by wspierały moje pomysły.Logowanie jednokrotne dla aplikacji sieci Web

Oto scenariusz:

1) Masz złożoną aplikację internetową, która oferuje bezpieczne treści na zasadzie subskrypcji.

2) Użytkownicy są wymagane do logowania się do aplikacji z nazwą użytkownika i hasłem.

3) możliwość sprzedaży do dużych korporacji, które już posiadają technologię uwierzytelniania korporacyjnej (na przykład Active Directory).

4) Chcesz zintegrować z mechanizmem uwierzytelniania korporacyjnej, aby umożliwić ich użytkownikom na logowanie się do aplikacji internetowej bez konieczności podawania swoją nazwę użytkownika i hasło.

Teraz każde rozwiązanie wymyślić będą musiały zapewnić mechanizm:

  • dodawanie nowych użytkowników
  • usuwania użytkowników
  • zmieniając informacje o użytkowniku
  • dzięki czemu użytkownicy mogą zalogować

Idealnie, wszystko to się stanie „automagicznie”, gdy klient korporacyjny dokonane odpowiednie zmiany do ich własne uwierzytelnienie.

Mam teraz pewną teorię, że sposobem na to (przynajmniej dla Active Directory) byłoby napisanie aplikacji po stronie klienta, która integruje się z Active Directory klienta, śledząc zmiany, a następnie komunikując się te zmiany w mojej aplikacji internetowej. Myślę, że gdyby ta komunikacja została wykonana za pośrednictwem usług sieciowych oferowanych przez moją aplikację internetową, to utrzymałaby nieusuwalny poziom bezpieczeństwa, który oczywiście byłby wymogiem dla tych klientów korporacyjnych.

Znalazłem kilka informacji na temat produktu firmy Microsoft o nazwie Active Directory Federation pokoi (ADFS), które mogą lub nie mogą być właściwe podejście do mnie. Wydaje się być trochę nieporęczna i ma pewne wymagania, które mogą nie działać dla wszystkich klientów.

W przypadku innych istniejących scenariuszy ID (takich jak Ateny i Shibboleth), nie sądzę, aby aplikacja klienta była konieczna. To prawdopodobnie tylko kwestia przywiązania do istniejących usług ID.

Byłbym wdzięczny za radę, którą każdy ma na temat, o którym tu wspomniałem. W szczególności, jeśli możesz mi powiedzieć, czy moja teoria jest poprawna w kwestii dostarczania aplikacji klienckiej, która komunikuje się z usługami sieciowymi po stronie serwera, lub jeśli całkowicie zmierzam w niewłaściwym kierunku. Ponadto, jeśli mógłbyś wskazać mi jakieś strony lub artykuły wyjaśniające, jak to zrobić, byłbym bardzo wdzięczny. Moje badania nie pojawiły się zbyt wiele.

Wreszcie, jeśli mógłbyś poinformować mnie o jakichkolwiek aplikacjach internetowych, które obecnie oferują tę usługę (szczególnie związaną z firmowym Active Directory), byłbym bardzo wdzięczny. Zastanawiam się, czy inne aplikacje internetowe B2B, takie jak salesforce.com, czy hoovers.com oferują podobną usługę dla swoich klientów korporacyjnych.

Nienawidzę być w ciemności i będą wdzięczni żadnego światła można rzucić ...

Jeremy

+0

Jestem ciekawy, dlaczego ktoś wczoraj zaniechał tego pytania. Chcesz się skomentować? –

+0

Należy pamiętać, że DWÓŁ LAT po tym, jak został wysłany, ktoś go obniżył. Przypadkowo (być może?) Osoba, która go zarzuciła, mogła być tysięcznym widzem. –

+0

Szukam czegoś bardzo podobnego. Czy masz rozwiązanie swojego problemu? Proszę podzielić się spostrzeżeniami, jak to osiągnąć. – Gala101

Odpowiedz

3

Shibboleth jest przeznaczony do obsługi dokładnie ten scenariusz. Będzie jednak polegać na firmach klientów wdrażających mechanizmy dostawcy tożsamości. W tej chwili jest to naprawdę powszechne na uniwersytetach. Co więcej, jeśli potrzebujesz informacji o użytkowniku (nie tylko jako identyfikatora pseudonimu), musisz wyrazić zgodę na udostępnienie tych atrybutów Tobie.

Trudno mi uwierzyć, że wiele firm otworzyłoby dla ciebie firmowy system uwierzytelniania, aby dostarczyć SSO.

Może się zdarzyć, że lepiej będzie polegać na OpenID lub podobnym i użyć pliku cookie "zapamiętaj mnie", aby ograniczyć potrzebę wprowadzania haseł przez użytkowników.

2

Jednym z podstawowych problemów związanych z Twoim podejściem jest to, że rozważasz aplikację internetową w izolacji. Pracownicy w firmie klienta nie potrzebują tylko SSO do swojej aplikacji internetowej, ale także niektórych/kilku/wielu innych osób, a rozszerzenie Twojego podejścia wymagałoby indywidualnej implementacji dla każdego z nich, aby umożliwić dostęp.

Stąd powszechne przyjęcie OpenAthens i Shibboleth w społeczności akademickiej biblioteki w celu wykorzystania lokalnie wydanych poświadczeń. Typowy średni/duży uniwersytet może subskrybować różne produkty/usługi od ponad pięćdziesięciu różnych wydawców, a wdrażając OpenAthens/Shibboleth, może skorzystać z otwartego standardu SAML (SAML jest protokołem używanym przez Shibboleth), który obserwuje zwiększone nie tylko w sektorze akademickim, ale także w sektorze komercyjnym.

Powyższa odpowiedź Johna wskazuje na inną kwestię: pojawiło się kilka otwartych standardów, które pojawiły się niedawno, a wśród nich SAML i OpenID. Dlatego dostawcy treści muszą zdecydować, czy chcą wdrożyć niektóre lub wszystkie z nich natywnie, ale używają oddzielnych stosów technologii, a zatem koszty wdrożenia i wsparcia mogą zostać podwojone.

Dość duża liczba wydawców wdrożyła OpenAthens, ponieważ obsługuje Ateny, SAML/Shibboleth i OpenID na jednej platformie, z opcją podłączenia innych technologii lub pisania niestandardowego modułu, aby umożliwić połączenie aplikacji wewnętrznej, np. fakturowania lub system uprawnień zapisu których użytkownicy klientów są zalogowaniu.

Ten sektor zarządzania dostępem jest zdecydowanie w kierunku otwartych standardów, więc budowanie własnych metodą byłoby pozbawienie dostępu do aplikacji dla dużej liczby użytkowników