Identyfikacja ASP.NET z wieloma aplikacjami

Question

dzięki czemu nasza organizacja opracowuje nowe aplikacje internetowe przy użyciu asp.net mvc i web api. zdecydowaliśmy się nie używać aktywnego katalogu do celów uwierzytelniania/autoryzacji, więc wygląda na to, że tożsamość asp.net ze strukturą encji może działać.

Przeglądanie schematu bazy danych Nie widzę tabeli aplikacji, więc możemy mieć jedno centralne repozytorium dla poświadczeń użytkownika i dostępu do aplikacji. to jest, gdzie pojawiają się roszczenia? jak by to wyglądało; użytkownik -> aplikacja -> rola -> uprawnienia

Jednym z naszych celów jest również zapewnienie użytkownikom jednokrotnego logowania. czy jest to możliwe z nowymi żetonami na okaziciela?

dzięki za wszelką pomoc można zapewnić

Answer 1

Zobacz ten samouczek. To pokazuje, jak zaimplementować Tożsamość używając ASP.NET Web API:

http://bitoftech.net/2015/01/21/asp-net-identity-2-with-asp-net-web-api-2-accounts-management/

Co do czynienia z wieloma aplikacjami. Dwa podejścia, które przychodzą do głowy to:

1. Dopisz się AppId do wszystkich nazw użytkowników
2. Dodaj AppId kolumna do AspNetUsers tabeli pochodzą z UserStore i ponownie wdrożyć metody oparte na Find tak zapytania uwzględniać AppId

dla # 1, gdy aplikacja chce stworzyć nowego użytkownika byłoby wysłać zapytanie do WebAPI zawierającego nowe informacje użytkownika i AppId. WebApi następnie złączy UserName i AppId, aby utworzyć pełną nazwę użytkownika, która zostanie zapisana w bazie danych. Jeśli więc aplikacja 1234 chce utworzyć użytkownika o nazwie użytkownika myuser, WebApi utworzy nowego użytkownika o nazwie użytkownika myuser_1234. Od tego momentu podczas wysyłania zapytań do bazy danych najpierw należy pobrać z żądania UserName i AppId, połączyć je, a następnie wysłać zapytanie do bazy danych.

Jeśli inna aplikacja 9900 chce utworzyć myuser, wówczas ostateczną nazwą użytkownika zapisaną w bazie danych będzie myuser_9900.

Użytkownik może chcieć zapisać szczegóły aplikacji w bazie danych i dla każdego żądania zweryfikować numer AppId, aby upewnić się, że rozpoznaje aplikację przed przetworzeniem żądania.

Nie myślałem dużo o kroku 2, więc jest to tylko sugestia.

Jeśli chcesz udostępnić dane uwierzytelniające użytkownika w wielu aplikacjach, możesz prawdopodobnie zignorować powyższe dane, korzystać ze standardowej funkcjonalności i po prostu mieć wszystkie aplikacje wskazywać na tę samą bazę danych, dzięki czemu wszystkie aplikacje będą miały dostęp do wszystkich użytkowników bez względu na aplikację. stworzyłem który użytkownik.

AKTUALIZACJA # 1: W tym przypadku można użyć żetonów okaziciela i myślę, że (wychodząc z pamięci) seria samouczków wspomniana powyżej dotyczy tego i jak pojedynczy WebApi może zapewnić tokeny dla wielu aplikacji.

Answer 2

dla pojedynczego znaku na to możliwe ciasteczka udostępniania lub za pomocą innego stanu sesji, takie jak <sessionState mode="SQLServer"> lub <sessionState mode="StateServer"> https://msdn.microsoft.com/en-us/library/ms178586(v=vs.140).aspx

Answer 3

użytkowników i ich poświadczenia są przechowywane w AspNetUser tabela i role są w ASPNetRole, podczas gdy AspNetUserRole służy jako tabela skrzyżowań między tymi dwoma, aby mapować użytkowników i role. Możesz wdrożyć SSO (logowanie jednokrotne), udostępniając te tabele w swoich aplikacjach. Tak jak każda aplikacja będzie musiała przeczytać te tabele i role oraz zalogować użytkowników. Ale lepszym rozwiązaniem byłoby stworzenie centralnego WebApi do obsługi uwierzytelniania i autoryzacji użytkownika.

Również jeśli możesz zmienić role w czasie wykonywania, masz pomysł uprawnień, możesz utworzyć niestandardową tabelę do przechowywania uprawnień, a następnie zmapować role do uprawnień. A kiedy użytkownik loguje się, wystarczy załadować wszystkie swoje uprawnienia i przechowywać jako roszczenia. Możesz serializować całą rolę (z listą uprawnień) i przechowywać ją jako jedno żądanie. Możesz też przechowywać każde pozwolenie jako indywidualne roszczenie, które najbardziej Ci odpowiada.