5

Pracuję nad prototypem dla re-architektury strony przy użyciu ASP.NET 5 i debatuję przy użyciu IdentityServer4 dla mojego uwierzytelniania i autoryzacji. Sprawdziłem wiele próbek i artykułów na temat konfigurowania IdentityServer3 i 4 i staram się owijać głowę, jeśli potrafię w odpowiedni sposób poradzić sobie z wymaganiami mojego klienta. Oto moje wymagania.asp.net 5 i IdentityServer4

Mam 3 witryny, które wymagają autoryzacji. Strona 1 (abc.com) będzie wymagać uwierzytelniania systemu Windows i będzie połączeniem wywołań mvc i webapi przy użyciu ról (lub ról przekształconych na oświadczenia) w celu autoryzacji. Witryna 2 (def.com) to zaufana witryna, która chce mieć widżet logowania z polem nazwa użytkownika/hasło/rememberme na swojej stronie, który po przesłaniu uwierzytelni użytkownika i przekieruje go na stronę 3 (xyz.com). Strona 3 będzie również miała swoją własną stronę logowania i będzie połączeniem wywołań mvc i webapi z wykorzystaniem roszczeń. Witryny 2 i 3 nie będą używały uwierzytelniania systemu Windows, a klient nie chce, aby przekierowywały do ​​ekranu logowania do serwera tożsamości, ale mają własny ekran logowania i wywoływanie serwera tożsamości za pomocą kodu z poświadczeniami logowania.

Oto moje pytania dotyczące tego scenariusza i IdentityServer4.

  1. Czy Idsvr4 obsługuje jednego klienta za pomocą uwierzytelniania systemu Windows i innego przy użyciu uwierzytelniania nazwy użytkownika/hasła?
    • Jeśli tak, to czy istnieje powód, aby mieć okna uwierzytelniania w idsvr4 lub należy po prostu użyć standardowy okna auth w webapp?
  2. Czy idsvr4 być ustawiony tak, aby mieć klient zbierać login/hasło/wartości Twój na zawsze i przekazać je za pośrednictwem kodu uzyskać odpowiednie tokeny JWT zarówno MVC i WebAPI?

    • Jeśli tak, to może log je do obu aplikacji MVC i WebAPI w innym miejscu?

    • Jeśli tak, czy to jest obchodzenie prawdziwego celu identityserver4 , a co za tym idzie, zły pomysł?

  3. Jeśli można obsługiwać ten scenariusz i jest to dobry pomysł, w jaki sposób mogę skonfigurować klienta zakresy i kod do obsługi logowania za pomocą kodu i przekierowanie?

Przykładami są świetne i bardzo mile widziane, ale nie jestem jeszcze pewien, co verbiage użyć, aby wyszukać ten scenariusz tak nawet wskazujące mnie we właściwym kierunku byłoby bardzo pomocne.

+0

To może być przydatne https://www.linkedin.com/pulse/securing-net-core-web-api-identityserver4-resource-owner-dalvandi?trk=mp-author-card –

Odpowiedz

1

Nie jestem pewien, czy to pytanie jest nadal aktywne. Ale tak, wierzę, że możesz to wszystko zrobić.

1) Można skonfigurować które LDP jest dostępna dla każdego klienta poprzez ustawienie IdentityProviderRestrictions na kliencie (docs)

1.1) - Nie wiem, co masz na myśli, wierzę, jeden z punktów mających idsrv jest na sentralize uwierzytelnianie i ułatwia przyszłym stronom internetowym integrację z tą samą usługą.

2) Podczas logowania za pomocą klienta (aplikacji), określasz także, do którego apiResource klient ma dostęp - i aplikacja musi dodać to do żądanych zakresów podczas logowania. Więc jeśli twoim klientem jest aplikacja mvc , po prostu dodaj źródło ApiResource w AllowedScopes - i ustaw request_type na id_token code - to wtedy da to użytkownikowi access_token, który jest przekazywany z każdym żądaniem do api backendu. (docs)

2.1) - Zasadniczo logowałby użytkownika na obu stronach - przy użyciu tokena dostępu, który mówi, że użytkownik jest uprawniony do korzystania z interfejsu API zaplecza.

2.2) - Moim zdaniem ten przepływ jest jedną z rzeczy, które sprawiają, że idsrv jest świetny - a nawet wspominają o tym jako o wspaniałej funkcji idsrv. Potrzebujesz tylko jednej podróży do authservera, aby uzyskać dostęp do wszystkich systemów.

co do pt. 3 - Przyjrzyj się dokładnie dokumentom, spróbuj ustawić pusty projekt po quickstarts.

Aby zalogować się z własnej strony logowania, należy użyć typu dotacji Resource Owner password - Mimo że nie zalecają tego w przypadku problemów bezpieczeństwa (przekazywanie haseł przez kabel) - jest to obsługiwane.

Powiązane problemy