Совместное использование аутентификации между Asp .Net и Asp .Net Core - PullRequest
Новая
       57

Совместное использование аутентификации между Asp .Net и Asp .Net Core

0 голосов
/ 27 марта 2019

Привет! Я создаю централизованную структуру аутентификации для всех наших приложений в нашей интрасети.

Я пытался использовать Jwt Web Api.

Я пробовал Identity Server 4 OpenConnect

И теперь я узнал, что Cookie Share из Microsoft docs

https://docs.microsoft.com/en-us/aspnet/core/security/cookie-sharing?view=aspnetcore-2.2

Я не могу решить даже после прочтения такого количества статей, какую из них мне следует реализовать.

Обмен файлами cookie звучит очень просто, я скачал образец, и он сработал прямо из коробки.

Все примеры с сервером идентификации 4 имеют некоторые проблемы, которые я не могу запустить.Некоторые функции, такие как выход из системы, не будут работать или будут работать только на одном конце.

Jwt Web Api не очень сложен в реализации, но все же требуется немного подумать, чтобы получить утверждения из токена и затем реализовать токенrefresh.

Совместный доступ к файлам cookie, который я только что обнаружил, но я все еще открыт для большего количества альтернатив или плюсов и минусов каждого из них.

Я также слышал о OWIN, но до сих пор точно не понимаючто это такое

1 Ответ

2 голосов
/ 27 марта 2019

AFAIK

Обмен файлами cookie

Если все ваши приложения находятся в интрасети и все сделаны с использованием стека dot net. Имеет смысл воспользоваться файлами cookie для обмена. Ранее я имел успех при реализации единого входа с использованием этой стратегии, где основным логином было бы старое приложение веб-форм, и оно авторизовало бы основное приложение dotnet.

Плюсы: вы используете стек Microsoft, прост в настройке.

Минусы: вы заблокированы для использования стека Microsoft. Отпадает, если вы хотите использовать с родными / JS-приложениями.

IdentityServer4

Немного поэкспериментировав с этой библиотекой, это абстракция протоколов OAuth2 и OpenIdConnect, в основном аутентификация и авторизация с использованием токенов jwt. IdentityServer4 позволяет вам указать свои полномочия (AS => Authentication Server), который обрабатывает аутентификацию клиентов (другие ваши приложения, будь то .net, js или native). Маркер, который AS предоставляет клиентам, затем используется для определения, имеет ли клиент доступ к API. Вы можете указать, какие клиенты могут получить доступ к каким API-интерфейсам и к какому количеству из них они могут получить доступ на основе утверждений. Можно преобразовать группы Active Directory в заявки и авторизоваться на этом уровне.

Плюсы: действительно хорошая абстракция, они упрощают большую часть процесса. Вы можете защитить любой тип клиента (js / native / .net).

Минусы: Вам все еще нужно изучить спецификации OAuth2 и OpenIdConnect, что может занять довольно много времени. Вы, вероятно, в конце концов напишете довольно много настроек, в зависимости от того, насколько велика сеть приложений, которую вы пытаетесь защитить.

Промежуточное программное обеспечение JWT

Это просто позволяет API авторизовать токены для авторизации, и на самом деле это не обеспечивает «централизованную структуру аутентификации», вам придется самостоятельно обрабатывать множество настроек потока. как правило, просто разбавленная версия IS4.

Плюсы: быстрый и простой способ защиты API для уже существующего Органа.

Минусы: не позволяет вам создать сервер аутентификации.

Резюме

Я бы сказал, что вы можете использовать Cookie Sharing, если вы не планируете защищать собственные приложения или приложения js.

Если вы настраиваете аутентификацию на основе токенов, читайте ниже.

Пользуйтесь IdentityServer4 для долгосрочного гибкого решения и, если у вас есть время, чтобы узнать, как его использовать и настроить.

если у вас есть полномочия и вы не возражаете против установки JWT Middleware, это будет более гибко, чем обмен файлами cookie.

...