Аутентификация Azure AD без перенаправления пользователя

Я просмотрел множество примеров в Примеры кода Azure Active Directory, и я не могу найти тот, который соответствует моему сценарию.

В примерах, которые я нашел, есть кнопка входа, которая после нажатия перенаправляет пользователя на этот URL-адрес https://login.microsoftonline.com, позволяя пользователю пройти аутентификацию.

После успешной аутентификации пользователь перенаправляется обратно на исходный веб-сайт.

Хотя мой сценарий чем-то похож, единственное отличие состоит в том, что я не хочу перенаправлять пользователя на эту https://login.microsoftonline.com страницу.

Если возможно, я бы хотел, чтобы пользователь вводил свое имя пользователя/пароль в мои текстовые поля и отправлял их в ADAL, чтобы получить токен.

Насколько я понимаю, поскольку я нахожусь внутри приложения ASP.NET MVC, Azure AD ожидает client_secret, а не имя пользователя/пароль пользователя.

Другими словами, кажется, что единственный способ выполнить мою задачу - это:

  • Продолжайте использовать подход, отправляя пользователя на эту https://login.microsoftonline.com страницу.
  • б) Получить идентификатор клиента и секрет. Аутентификация приложения MVC в целом, а не аутентификация каждого пользователя.

Я не уверен, имеет ли смысл мой вопрос (или нет), поэтому не стесняйтесь просить разъяснений.

Спасибо


azure-active-directory azure-authentication adal
person Vlince    schedule 13.03.2017    source источник
comment
Это можно сделать с типом гранта password. Это требует, чтобы вы отправили идентификатор клиента, секрет клиента, имя пользователя, пароль и URI ресурса в конечную точку токена. Если у пользователя включена функция MFA или он объединен с локальной AD, это не сработает. Существует также небольшая проблема безопасности, связанная с тем, что пользователь предоставляет вашему приложению доступ к своему паролю. Ваше приложение действительно не должно обрабатывать их, весь смысл федеративной аутентификации заключается в том, чтобы переложить бремя на другую службу.   -  person juunas    schedule 13.03.2017

Ответы (1)


arrow_upward
2
arrow_downward

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

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

Перенаправление к поставщику удостоверений ожидается, когда мы выбираем интерактивный поток OAuth 2 Authorization Framework, потому что именно так это работает!

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

Более подробную информацию об OAuth2 см. в спецификации rfc6749.

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

Добавьте фирменную символику компании на страницы входа и панели доступа

person Fei Xue - MSFT    schedule 14.03.2017