Powiązanie dostawców tożsamości opartych na wielu roszczeniach z jednym użytkownikiem przy użyciu programu ASP.NET

Question

W aplikacji ASP.NET MVC 4 używającej architektury .NET 4.5 w połączeniu z usługą Azure Access Control Service (ACS), chcę zapewnić użytkownikom wiele możliwości uwierzytelniania (np. Google, Facebook, Windows Live itp.). Jaka jest "najlepsza praktyka" związana z powiązaniem pojedynczego użytkownika z wieloma dostawcami tożsamości?

Załóżmy na przykład, że użytkownik zaloguje się w Google jednego dnia, a następnie przejdzie do innej przeglądarki następnego dnia i zaloguje się za pomocą Facebooka. Skąd mam wiedzieć, aby powiązać logowanie Facebooka z poprzednim loginem Google do tego samego użytkownika?

Answer 1

Jeśli korzystasz z ACS, możesz przetłumaczyć informacje z każdego dostawcy tożsamości (np. Gogle, Yahoo !, FB itp.) Na wspólny uchwyt, korzystając z transformacji roszczeń na ACS. Często używanym uchwytem jest e-mail użytkowników. Ale jeśli chcesz, aby zaakceptować wiele e-maili mapowanie do tego samego użytkownika, a chcesz wprowadzić swój własny, unikalny identyfikator (w postaci roszczenia) i map IdP dostarczane roszczeń do niego:

• myemail@gmail.com (e-mail - Google) -> (UserId - YourApp) user_1234
• myotheremail@yahoo.com (email - Yahoo!) -> (UserId - YourApp) user_1234
• 64746374613847349 (NameIdentifier - LiveID) -> (UserId - YourApp) user_1234

można zautomatyzować ten przez ACS API. Powinieneś prawdopodobnie obsłużyć dziennik użytkownika po raz pierwszy w Twojej witrynie (np. Pytając użytkownika o wiadomość e-mail i wysyłając komunikat potwierdzający, który uruchomi mapowanie).

Prawdopodobnie używasz tych informacji do pobierania danych z lokalnej bazy danych w aplikacji, w przeciwnym razie możesz po prostu zakodować wszystko w roszczeniach i nie martwić się o żadne równoważniki. Roszczenia często są dobrym miejscem do kodowania typowych danych profilu. (np. role, itp.)

Answer 2

Nie szukaj dalej niż sam stackoverflow na dobry przykład tego. Kliknij swój profil użytkownika, a następnie wybierz "moje loginy".

Gdy użytkownik tworzy swoje konto, wybiera dostawcę tożsamości, którego chcesz użyć do logowania. Pod maską aplikacja tworzy nowy, specyficzny dla witryny identyfikator użytkownika i łączy go z unikalnym identyfikatorem dostarczanym przez firmę zewnętrzną. . (Możesz użyć poczty e-mail, ale większość dostawców tożsamości dostarczy również unikalne roszczenie do identyfikatora użytkownika, które nie ulegnie zmianie, nawet jeśli użytkownik zmieni adres e-mail)

Teraz, po zalogowaniu się użytkownika, ma on zarządzanie kontem panel kontrolny, za pośrednictwem którego mogą ustanowić dodatkowe łącza do innych dostawców tożsamości.

widzę dwie możliwości osiągnięcia tego celu:

1. Wyraź swoją aplikację MVC utrzymywać powiązania konta. Gdy użytkownik się zaloguje, wysyła zapytanie do magazynu linków do konta, korzystając z unikalnego identyfikatora dostawcy zewnętrznego, i rozwiązuje specyficzny dla witryny unikalny identyfikator użytkownika.

2. Użyj silnika reguł ACS. Utworzysz jeden link dla każdego konta. Na przykład, powiedzmy, że mogę się zalogować albo gmail lub LiveID i moim unikalnym identyfikatorem to 1234. Dwie zasady wyglądać następująco:

   • google + me@gmail.com - roszczenia ID> użytkownik wyjściowa 1234

   • LiveID + me@live.com -> user ID wyjście roszczenie 1234

Dla unikalnym ID wyjściowego typu roszczenia, można wybrać jeden z dostępnych typów roszczenia lub wyznaczyć własną rękę. ACS ma OData based management service, za pomocą którego można programowo utworzyć te reguły z aplikacji MVC. Oto code sample.