MSAL. Net подключение к Azure AD с федерацией ADFS - PullRequest
1 голос
/ 12 марта 2020

Мы создаем приложения в ASP. Net MVC и Web API, которые используют ряд функций OAuth 2 - AcquireTokenByAuthorizationCode (с помощью microsoft.identity.web), AcquireTokenSilently, AcquireTokenOnBehalfOf, AcquireTokenForClient для разных частей ландшафта приложения.

Приложения используют MSAL. Net для взаимодействия с Azure AD и выделенными в нем пользователями для предоставления доступа к ресурсам, и это работает нормально.

Сейчас мы рассматриваем создание подключения вернемся к предварительно поддерживаемым учетным записям пользователей в организации, чтобы конечные пользователи не дублировались в AAD и в Prem, поэтому ADFS поддерживается в организации. Принимая во внимание, что экземпляр ADFS - 2016, единственная возможность иметь MSAL. Net для работы с ADFS, по-видимому, Azure AD, интегрированный с ADFS, как описано в этой статье: https://docs.microsoft.com/bs-latn-ba/azure/active-directory/develop/msal-net-adfs-support

В статье обсуждается только AcquireTokenInteractive, и я не вижу объяснения, что другие операции MSAL. Net поддерживаются при федеративной интеграции AAD с ADFS. Я бы предположил, что это правда, и мы должны пройти наши тесты после того, как мы все это настроим, но в то же время,

будет у кого-нибудь опыт или документация по поводу диапазона операций с MSAL. Net (и даже msal. js) и AAD работают нормально, когда AAD объединен с ADFS?

1 Ответ

0 голосов
/ 06 апреля 2020

Итак, я попробовал это для себя, настроив виртуальную машину в Azure, установил Active Directory, AD FS и настроил федерацию между Azure AD и VM AD FS согласно статье https://docs.microsoft.com/en-us/azure/active-directory/b2b/direct-federation-adfs.

Затем были проверены различные функции OAuth, используемые нашим приложением, в частности (я ожидаю, что другие функции oauth будут работать так же, как и ожидалось, исходя из следующих наблюдений):

AcquireTokenByAuthorizationCode
AcquireTokenSilently
AcquireTokenOnBehalfOf
AcquireTokenForClient

Все эти функции работают как и ожидалось. Пользователь перенаправляется на страницу входа в org и возвращается в приложение.

Пара наблюдений по пути

  1. Срок действия токена refre sh составляет 12 часов. при работе с учетными данными AD Premise AD, интегрированными через ADFS, вместо нескольких дней, когда пользователь подготовлен в AAD. По-видимому, это снижает риск изменения пользовательской информации, например, смены пароля. Если браузер простаивает в течение> 12 часов, требуется повторный вход пользователя в систему.

  2. После аутентификации дальнейшие операции OAuth не затрагивают On prem AD / ADFS. Операции против Azure AD, любые перенаправления браузера на Azure AD для повторной авторизации.

...