ADAL AcquireToken проверка подлинности Windows UWP
Я разрабатываю приложение UWP, которое должно проходить аутентификацию на локальном экземпляре ADFS 2016, но с использованием встроенной аутентификации Windows.
Я использую ADAL 3.19.8. Приложение работает на устройстве Windows 10, к которому присоединен домен. В приложении включены возможности корпоративной аутентификации, частной сети (клиент и сервер) и сертификаты общего пользователя, как указано здесь: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/uwp-specificities
Я устанавливаю для флага UseCorporateNetwork значение true. Встроенная проверка подлинности Windows включена в окне "Свойства обозревателя", и я добавил сервер ADFS в зону локальной интрасети.
Вот как я пытаюсь аутентифицироваться:
string authority = "https://xxxx/adfs/oauth2";
const bool useCorporateNetwork = true;
var authContext = new AuthenticationContext(authority, false);
var authResult = await authContext.AcquireTokenAsync(
resourceURI,
clientID,
new Uri(clientReturnURI),
new PlatformParameters(PromptBehavior.Auto, useCorporateNetwork));
Аутентификация по ADFS прошла успешно, и я получаю токены доступа и идентификатора. Однако приложение всегда отображает экран входа в ADFS. Чтобы продолжить, я ввожу те же самые имя пользователя и пароль, которые я использовал для входа в Windows. Очевидно, что это не идеальный вариант, и это не то поведение, которое пользователи приложения хотели бы видеть.
Используя Fiddler, я вижу, что приложение UWP вызывает https://xxxx/adfs/oauth2/authorize.
Я могу получить ожидаемое поведение единого входа, если использую приведенный выше код, но в приложении WinForms (хотя перегрузка useCorporateNetwork отсутствует). Используя Fiddler, приложение WinForms вызывает https://xxxx/adfs/oauth2/authorize/wia
Что мне не хватает?
2 ответа
Бит, который я пропустил, оказался тем, что вам нужно заполучить Uri перенаправления клиента из WebAuthenticationBroker вместо того, чтобы устанавливать его в произвольную строку:
Uri clientReturnURI = Windows.Security.Authentication.Web
.WebAuthenticationBroker.GetCurrentApplicationCallbackUri();
Это возвращает URI, такой как ms-app://s-1-15-2-1352796503-54529114-405753024-3540103335-3203256200-511895534-1429095407/, и это должно быть зарегистрировано в ADFS для собственного приложения.
Эта статья была полезна: https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/Acquiring-tokens-interactively---Public-client-application-flows
Это соответствующий раздел:
Свойства PlatformParameter, специфичные для WinRT и UWP (корпоративная сеть)
Платформы WinRT (до ADAL 3.x) и UWP имеют следующее свойство UseCorporateNetwork - логическое значение, которое позволяет приложениям Win8.1 и UWP использовать преимущества встроенной аутентификации Windows (и, следовательно, единого входа с пользователем, вошедшим в операционную систему). если этот пользователь вошел в систему с учетной записью в федеративном клиенте Azure AD. Это использует WAB (брокер веб-аутентификации).
Важное замечание: Если для этого свойства установлено значение true, предполагается, что разработчик приложения включил встроенную проверку подлинности Windows (WIA) в приложении. За это:
В Package.appxmanifest для вашего приложения UWP на вкладке "Возможности" включите следующие возможности: Общий сертификат пользователя для частных сетей (клиент и сервер) WIA не включен по умолчанию, поскольку приложения, запрашивающие возможности корпоративных аутентификационных или общих пользовательских сертификатов, требуют более высокий уровень проверки должен быть принят в Windows Store, и не все разработчики могут пожелать выполнить более высокий уровень проверки. Обратите внимание, что базовая реализация на платформе UWP (WAB) не работает правильно в сценариях Enterprise, где был включен условный доступ. Симптом состоит в том, что пользователь пытается войти в систему с помощью Windows hello, и ему предлагается выбрать сертификат, но сертификат для PIN-кода не найден, или пользователь выбирает его, но никогда не получает запрос на PIN-код. Обходной путь должен использовать альтернативный метод (имя пользователя / пароль + проверка подлинности телефона), но опыт не является хорошим. В будущем ADAL и MSAL потребуется использовать WAM, что решит проблему.
Получение URI перенаправления в случае магазина приложений Windows 8.1
Примечание: поддержка Win8.1 и Windows Phone 8.1 остановлена в ADAL 4.x. Приложение Windows 10 (UWP) по-прежнему поддерживается
В случае приложений Windows Store, вам нужно будет найти URI обратного вызова для вашего приложения Windows Phone. Самый простой способ сделать это - добавить строку в метод Initialization (например, в MainPage) и установить точку останова на этой строке в методе:
var redirectURI = Windows.Security.Authentication.Web.WebAuthenticationBroker.GetCurrentApplicationCallbackUri ();
затем запустите приложение и скопируйте значение redirect Uri при достижении точки останова. Это должно выглядеть примерно так: ms-app://s-1-15-2-1352796503-54529114-405753024-3540103335-3203256200-511895534-1429095407/ Назад на вкладку ReplyURLs своего приложения на портале Azure добавьте это значение.
Надеюсь, это окажется полезным для всех, кто борется с той же проблемой!
Если ADAL.NET приобрел для пользователя токен для веб-API, кэширует его вместе с токеном обновления. В следующий раз, когда приложение захочет получить токен, оно может сначала вызвать AcquireTokenSilentAsync проверить, находится ли приемлемый токен в кэше.
AuthenticationContext ac = new AuthenticationContext(authority);
AuthenticationResult result=null;
try
{
result = await ac.AcquireTokenSilentAsync(resource, clientId);
}
catch (AdalException adalException)
{
if (adalException.ErrorCode == AdalError.FailedToAcquireTokenSilently
|| adalException.ErrorCode == AdalError.InteractionRequired)
{
result = await ac.AcquireTokenAsync(resource, clientId, redirectUri,
new PlatformParameters(PromptBehavior.Auto));
}
}
Для получения дополнительной информации, пожалуйста, обратитесь к этому.