HTTP-аутентификация Тип согласования в клиентском приложении iOS

Поддерживается ли схема HTTP-аутентификации "Согласование" в приложениях для iOS?

Я пытаюсь получить доступ к серверу, который использует эту схему аутентификации. В настоящее время я использую класс ASIHTTPRequest, который внутренне использует библиотеку CFNetwork. Не удается выполнить проверку подлинности, и при трассировке через код ASIHTTPRequest я вижу, что она завершается ошибкой после того, как объект CFHTTPAuthentication, созданный путем вызова функции CFHTTPAuthenticationCreateFromResponse, не проходит проверку с помощью функции CFHTTPAuthenticationIsValid. Возвращенная ошибка: "kCFStreamErrorHTTPAuthenticationTypeUnsupported = -1000". Ответ, который он использует для создания CFHTTPAuthentication, имеет заголовок "WWW-Authenticate = Negotiate". Это заставляет меня думать, что схема переговоров не поддерживается. Однако документация библиотеки для CFHTTPAuthentication перечисляет "kCFHTTPAuthenticationSchemeNegotiate" как "Доступный в iOS 2.0 и позже".

Ниже приведены соответствующие части кода из ASIHTTPRequest.m из метода tryToApplyCredentialsAndResume.

// Read authentication data
if (!requestAuthentication) {
    CFHTTPMessageRef responseHeader = (CFHTTPMessageRef) CFReadStreamCopyProperty((CFReadStreamRef)[self readStream],kCFStreamPropertyHTTPResponseHeader);
    requestAuthentication = CFHTTPAuthenticationCreateFromResponse(NULL, responseHeader);
    CFRelease(responseHeader);
    [self setAuthenticationScheme:[(NSString *)CFHTTPAuthenticationCopyMethod(requestAuthentication) autorelease]];
}

//SNIP

// See if authentication is valid
CFStreamError err;      
if (!CFHTTPAuthenticationIsValid(requestAuthentication, &err)) {

    CFRelease(requestAuthentication);
    requestAuthentication = NULL;

Я также несколько озадачен самой схемой переговоров. Насколько я понимаю, он должен попытаться использовать схему Kerberos, если это возможно, а затем вернуться к схеме NTLM, если нет. Схема NTLM поддерживается в iOS, но этого отступления, по-видимому, не происходит, по крайней мере, не так, как CFHTTPAuthenticationCreateFromResponse.

Источник

3 ответа

Решение

На iPhone нет поддержки Kerberos. Согласование возвращается к NTLM, но не ожидайте, что iOS будет поддерживать собственную схему аутентификации. Могут существовать сторонние реализации.

Источник

Safari на iOS 7 поддерживает единую регистрацию (SSO) через HTTP-переговоры:

Чтобы настроить единый вход, iOS поддерживает полезную нагрузку профиля конфигурации, которая позволяет серверам MDM загружать необходимые параметры. Это включает в себя настройку имени участника-пользователя (то есть учетной записи пользователя Active Directory) и настроек области Kerberos, а также настройку того, каким приложениям и / или веб-URL Safari должно быть разрешено использовать единый вход.

Источник: iOS Security, февраль 2014 г. (стр. 18)

Источник

Я знаю, что этот вопрос задавали десять лет назад, и за это время в Apple и iOS могли радикально измениться некоторые вещи. Однако сервер должен отправлять не только Negotiate, но и рекламировать возможности NTLM, иначе откат к NTLM никогда не произойдет.

Эти типы проблем сложны для устранения, особенно при отсутствии достаточной технической документации и когда вы подозреваете, что ваш собственный код неверен. Недавно я столкнулся с похожей проблемой и увидел документацию Microsoft IIS о том, как настроить Kerberos для веб-сайта, в которой указано, что нужно отправлять WWW-Authenticate: Negotiate, NTLM (в таком порядке).

Источник
Другие вопросы по тегам