Реализация Identity Server (OAuth2) с интеграцией с устаревшими системами (Forms Auth, ADFS, AD)

В настоящее время мы создаем API RESTful (.Net Core, IdentityServer 4, EF6). Мы выпустили версию MVP.

Он также ссылается на службу WCF. Эта служба WCF организует все другие вызовы для других внутренних (устаревшие системы) и других компонентов интеграции.

(Возможно, неверно). Краткий обзор реализации выглядит следующим образом:

Одна из главных вещей, за которые мы застряли, заключается в том, чтобы определить как интеграцию различных систем аутентификации и авторизации с использованием Identity Server...

В частности внутренняя служба для обслуживания вызовов. Используем ли тот же IdentityServer для выполнения нескольких функций? (авторизация и аутентификация публичного потребителя и внутренняя авторизация обслуживания для обслуживания).

Традиционно мы использовали различные конфигурации безопасности WCF (Transport, TransportWithMessageCredentials... и т.д.), добавляя Forms, AD, ADFS и учетные записи служб. Мы должны быть уверены, что делаем правильные вызовы для создания многоразовой реализации IdentiyServer.

Короче говоря, наша задача - как вы выполняете авторизацию внутреннего сервиса?

Хорошо ли иметь центральную реализацию Identity Server, которая обрабатывает как запросы, связанные с общественностью, так и внутреннюю (multihop) авторизацию обслуживания для обслуживания?
Рекомендуете ли вы разделить и иметь отдельные серверы идентификации для внутренней авторизации службы-обслуживания от тех, которые обрабатывают запросы API с открытым доступом?
Или мы еще идем дальше, чтобы разделить и создать другой сервер идентификации для каждого случая использования приложения?

Ответ 1

Вот мои мысли о прочном плане реализации.

Хорошо ли иметь центральную реализацию Identity Server, которая обрабатывает как запросы, связанные с общественностью, так и внутреннюю (многопользовательскую) авторизацию на услуги?
Причины совместного использования:
- Упрощенное решение
Причины иметь отдельную реализацию:
- Различные требования безопасности для внешних и внутренних пользователей/клиентов
- Внешний внешний вид не повлияет на внутренних пользователей и клиентов.
Рекомендация: В краткосрочной перспективе используйте реализацию, которая будет обслуживать как с целью разделить их на внешние и внутренние фокусы.

Рекомендуете ли вы разделить и иметь отдельные серверы идентификации для внутренней авторизации службы-обслуживания из тех, которые обрабатывают запросы API с открытым доступом?
Рекомендация: Долгосрочный да. См. Выше, почему.
1. Или мы еще идем дальше, чтобы разделить и создать другой сервер идентификации для каждого случая использования приложения?
  Рекомендация: Нет, создание отдельного сервера идентификации для каждого клиента/случая использования будет сложнее управлять в долгосрочной перспективе. Вы должны создавать отдельные клиенты для каждого приложения/сценария. (т.е. мобильный клиент, веб-сайт MVC, внутренний сервер для внутреннего сервера, внешний API/услуга для внутреннего API/сервиса [подумайте об интерфейсах B2B])

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

Ответ 2

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

Я думаю, что идеальная ситуация - это то, где вы поддерживаете только одного поставщика удостоверений, например Active Directory. Microsoft полагает, что их решение легко, но это не так. Вот почему, если вам придется поддерживать устаревший провайдер Identity, а также новую систему параллельно, вы будете страдать больше.

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

Честно говоря, если вы можете изолировать наследие (или удалить его) из своей новой системы, вы получите огромные преимущества в долгосрочной перспективе для обслуживания и ковкости.

Прежде чем принимать решение, я рассмотрю примеры кода. Лучше знайте разблокировщики транзакций, прежде чем проводить недели в любом направлении.

Ответ 3

Здесь моя точка зрения для проблемы выше

Отдельный сервер идентификации для внутренней службы
Есть больше преимуществ в разделении сервера идентификации для внутреннего обслуживания, т.е.

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

Новый сервер имеет долгосрочные преимущества и улучшения безопасности.