Сервер идентификации без входа в систему

Question

Я пытаюсь реализовать авторизацию IdentityServer, и мой сценарий ниже:

у нас есть одна домашняя страница для всего нашего приложения «www.vision2025.com», и у меня есть ссылка на мое mvc приложение «MarketingDashboard», где пользователи аутентифицируются на домашней странице и перенаправляются в мое приложение mvc с использованием аутентификации windows. Теперь пользователь может выполнять любые действия на моей панели инструментов, которые взаимодействуют с веб-API.

Теперь мне нужно внедрить IdentityServer, чтобы авторизовать все вызовы веб-API с моей панели, но без входа в систему.

Пожалуйста предложить любую идею

Заранее спасибо

Answer 1

Я думаю, вы не хотите создавать IdentityServer, потому что ваша корпоративная компания уже построила ADFS (службы федерации Active Directory). Вы просто хотите спросить, кто обслуживает AD, и попросить его включить ADFS для OAuth2. Это страница, которая поможет вам поймать все сценарии ios здесь .

Потому что я не знаю, насколько далеко вы можете изменить для всех приложений, но есть некоторые решения с ADFS, которые вы можете go с:

1. Пусть ваш главный сервер (действует как домашняя страница и где пользователь перенаправляется на ADFS для входа) выполняет поток от имени . В этом сценарии вашим основным сервером будет связанный сервер, который передает свои принятые access token, полученные из ADFS. Я настоятельно рекомендую этот способ, потому что вы просто хотите добавить столько же, сколько ваш новый веб-сайт и api. Минусы в том, что они требуют высокой степени защиты access token на вашем основном сервере
2. Поскольку OAuth 2.0 еще не поддерживает цепочку серверов ресурсов (например, вы вошли в сервер ресурсов A, затем используйте provided access_token для вызовите сервер ресурсов B в разных клиентах), вам необходимо разрешить вашему основному серверу хранить его имя пользователя / пароль (также известный как доверенный внутренний сервер , это означает, что ваше предприятие позволяет этому серверу хранить учетные данные клиента). Таким образом, каждый раз, когда вы перенаправляете пользователя в целевое приложение MVC, вы также должны передавать зашифрованное имя пользователя / пароль . Затем ваше целевое приложение MVC может выполнять авторизованный поток или неявный поток во внутреннем коде, а затем возвращать новый access token клиентской сети для выполнения вызова веб-API.