Я надеюсь получить руководство по запуску нового проекта, в котором я надеюсь использовать IdentityServer4 для управления аутентификацией.
У меня есть сайт, который я переписываю, на котором более 400 установоки 2-3 десятка сервисов, охватывающих все сайты.Некоторые из наших установок должны поддерживать единый вход с использованием федеративного удостоверения в корпоративных системах.В прошлом это обрабатывалось с помощью Shibboleth.
Моя цель - централизовать часть управления Identity в экземпляр Identity Server.Я надеюсь, что это позволит нашим пользователям-администраторам поддерживать единый вход во все приложения, корпоративным клиентам, у которых может быть несколько сайтов, иметь единый вход, упростить интеграцию с федеративными поставщиками удостоверений (для единого входа с некоторыми из наших клиентов).) и разрешить сторонним приложениям регистрироваться у нас, чтобы использовать наши API.
Я считаю, что Identity Server может помочь с этим, но я немного растерялся от того, правильно ли я использую этот подход для решения этой проблемы..
Пожалуйста, прости меня, если я неправильно понял некоторые из моих терминов, я все еще изучаю некоторые из этих понятий.
Во-первых, когда пользователь хочет зарегистрироваться на одном из сайтов, я былпланируя перенаправить их на Identity Server и заставить их настроить там своего пользователя.Они могут либо использовать учетную запись Google, либо установить имя пользователя / пароль.Это потребует, чтобы имя пользователя было уникальным для всех 400+ сайтов, которые у нас есть, но я не думаю, что это большая проблема.Затем я планирую отправить запрос на регистрацию на отдельный сайт, чтобы администратор мог одобрить присоединение этого пользователя к сайту.Таким образом, каждый сайт ведет список пользователей, имеющих доступ к этому сайту, и управляется администраторами каждого сайта.Альтернативой этому будет создание заявки для каждого сайта, который будет управляться Identity Server (таким образом, Identity Server будет иметь более 400 заявок).Я чувствую, что это неправильный подход, потому что он не позволит администраторам на уровне сайта управлять тем, кто может получить доступ, и я не хочу быть тем, кто управляет этим.Имеет ли смысл мой подход или мне чего-то не хватает?
Во-вторых, некоторые клиенты захотят, чтобы мы интегрировались с их решением единого входа с использованием федерации.Здесь все становится немного сложнее.На сайте есть публичный и частный компонент.Общественная сторона должна быть заблокирована, чтобы разрешить доступ только тем людям, которые могут преодолеть их единый вход.Частной части сайта должен быть предоставлен доступ администратором.Мой план состоял в том, чтобы создать разные конечные точки для каждой из этих реализаций единого знака.Например, если бы мне пришлось сделать единый вход для WidgetCo и RightMart, у меня была бы отдельная конечная точка в Identity Server для каждого включения.Мои приложения должны были бы иметь разные конфигурации, на которых конечную точку использовать для своего билета аутентификации, но больше ничего не нужно было бы менять.Когда пользователь заходит на общедоступную часть сайта, он блокируется, поэтому ему необходимо будет войти в систему. Для доступа к общедоступной части сайта не требуется разрешение, и он полагается на тот факт, что IdentityServer выпустил токен дляПользователь должен предоставить им доступ к публичным сторонам Сайта.Приватная часть сайта останется прежней, поскольку администратору сайта потребуется предоставить доступ для входа пользователю. Имея разные конечные точки для каждого экземпляра единого входа, я надеюсь предотвратить сценарий, когда вход в систему из совершенно другогосайт получает доступ к общедоступному сайту WidgetCo, потому что у них есть логин с IdentityServer, даже если у них нет логина с помощью единого решения WidgetCo.Другой сложный аспект в этом заключается в том, что мне нужно было бы иметь доступ как администратор к сайту, даже если у меня нет входа в решение WidgeCo для единого входа.Я не уверен, нужно ли выполнять эту часть на IdentityServer (пусть она проверяет федеративную идентичность WidgetCo и ее локальное хранилище для пользователей с правами администратора) или мне нужно, чтобы это было сделано на самом сайте (есть открытая частьсайт проверяет конечную точку WidgetCo на IdentityServer, и для частной части он проверяет то же самое, и некоторые другие конечные точки, которые предназначены только для меня и моих сотрудников).Есть мысли?
Я также хотел бы разрешить другим приложениям / сервисам использовать мой API.Я думаю, что они должны были бы зарегистрировать Клиентский токен и Секрет на Identity Server.Затем я мог бы использовать это, чтобы заблокировать API.Однако я не знаю, что если я предоставлю доступ пользователям, я хочу, чтобы они имели доступ ко всем сайтам.Нужно ли мне убедиться, что у меня снова есть претензии по каждому сайту?Или я должен сделать то же самое, что планировал ранее, когда администратор каждого сайта должен предоставлять права на уровне сайта, а не на уровне Identity Server?
Буду признателен за любые мысли.Пытаясь обдумать все это, и не нужно переписывать все так много раз.
Спасибо!Ben