Как я понимаю,Как SPN с Kerberos работает
Я полностью потерян?
Попытка выяснить, как это работает, но информация либо слишком точная, либо недостаточно.
Thanks
Ok более подробный ответ: -
SPN - Service Principal Name. Это идентификатор, связанный с каждой учетной записью в реализации KDC (AD, OpenLDAP и т. Д.). В основном, если ваша учетная запись действует как услуга, к которой клиент аутентифицируется, клиент должен указать «кто», с которым он хочет связаться. Этот идентификатор «who» является SPN. Это строгое определение. Многие люди часто называют имя клиента (UPN - имя участника-пользователя) службы как SPN. Это происходит, когда сама услуга может выступать в роли клиента (сценарий делегирования Google). Это не совсем правильно, но принято считать правдой.
Kerberos - это протокол для аутентификации. Это имя для фреймворка. Он включает сторонний сервер (называемый KDC или Центр распространения ключей) и включает в себя ряд этапов приобретения билетов (токены аутентификации). Это действительно сложно, поэтому http://en.wikipedia.org/wiki/Kerberos_(protocol)
В какой-то степени вы получили это право. GSSAPI - это API, но SPNEGO - нет. GSSAPI технически не зависит от используемого вами механизма auth, но большинство людей используют его для аутентификации Kerberos. SPNEGO является псевдо-механизмом, в том смысле, что он объявляет RFC для связи на основе аутентификации в домене HTTP. Строго говоря, SPNEGO - это спецификация, но большинство людей также считают ее реализацией. Например, Sun и IBM JDK предоставляют «поставщики механизмов» для генерации маркеров SPNEGO, но GSSAPI используется для фактического вызова. Это делается во многих проектах (Tomcat как сервер и, например, на вершине моей головы, и один из тех, кто ответил на этот вопрос, разработал его).
SSPI является аналогом GSSAPI в окнах. Это другой API, который в конечном итоге делает что-то очень похожее на GSSAPI.
Почти все ваши понимания ошибочны.
Вот он идет:
Не совсем.
SPN просто означает «Название сервера» и является сленгом AD или Kerberos для службы, с которой вы пытаетесь пройти аутентификацию.
Kerberos - это служба аутентификации пользователей, более или менее да. Он также обеспечивает безопасность сетевых сообщений и вызовов между службами.
SPNEGO-GSSAPI * - вид странного зверя. GSSAPI (интерфейс прикладного программного обеспечения общей безопасности) - это API для (в принципе) различных служб аутентификации, он обеспечивает согласование используемых механизмов. Часто единственным доступным механизмом будет Kerberos. Это обычный API для присоединения 3-й программы партии в Kerberos, когда вы находитесь на Unix (определены в различных РЛК, например RFC 2743)
На платформе окон ССПИ это общий слой, поэтому он сравнивает с GSSAPI ,
SPNEGO - вид странного гибрида. Это механизм, который будет использоваться в SSPI, HTTP Auth или GSSAPI, который согласовывает другой протокол аутентификации (например, Kerberos или NTLM, если вы находитесь в Windows), поэтому он в основном делает то же самое, что и GSSAPI, ,
Типичные области использования SPNEGO являются аутентификацией HTTP для домена Windows, например, IIS использует его, если вы используете «Интегрированная проверка подлинности Windows». Он также используется, когда вы выбираете опции «Переговоры» для SSPI. Смотрите, например RFC 4559
Поэтому, если мне нужно попросить моего поставщика зарегистрировать его приложение для интеграции с Windows. Мне нужен был бы он для того чтобы создать слой соединения к SPN используя SPNEGO? В настоящее время он использует только SASL для проверки подлинности Kerberos для SPN, что не соответствует требованиям ИТ. –
Хорошо, поэтому я понимаю, что ваш поставщик должен быть аутентифицирован против вас (я имею в виду, что ваш код является сервером). SPNEGO поддерживает либо Kerberos, либо NTLM, и вы регистрируете свой SPN в реализации KDC (при условии, что на нем установлена аутентификация на основе Kerberos). Я не знаю, как регистрируются SPN, если вы используете NTLM auth. SASL является оболочкой над GSSAPI и не имеет ничего общего с SPNEGO. Я бы предпочел, если вы разместите свой код. –
О, и это также зависит от дизайна приложения вашего поставщика. Если ваше приложение-поставщик использует HTTP-связь, тогда да, они должны сообщать вам через SPNEGO. Классическим примером является авторизация браузера. У браузеров есть жесткий формат SPN, к которому они подключаются - HTTP/canonicaldnsnameofserver.realm.com. Это не может быть изменено, и серверы должны поддерживать это, определяя их SPN как указано выше. Однако это не всегда правильно. Например, я изменил проект curl, чтобы действовать на клиента, в котором целевые SPN являются произвольными. https://github.com/Khalian/CURL –