Протокол отправки токенов GSS

Я пытался выяснить, как использовать GSSAPI для аутентификации на сервере IIS в домене Active Directory, работая через код для руководств от Oracle, и у меня возникли проблемы с установлением контекста.

То, как учебник отправляет токены, заключается в том, что сначала отправляется целое число, а затем отправляется токен. Это работает, конечно, с учебным сервером, потому что он этого ожидает. Однако я не знаю, является ли это правильным протоколом для взаимодействия с GSSAPI в целом?

раздел 4 RFC4121 и RFC2743, раздел 3.1, кажется, предполагает, что есть нечто большее (какой-то тег, затем длина, но немного скорректированная, затем Oid [запрошенного механизма, я полагаю] и его длину и т. д.).

Это относится к внутренней структуре токена? Или это специфично для некоторых реализаций? Или этому протоколу будет следовать IIS (и, предположительно, все остальные серверы/хосты, поддерживающие GSSAPI)?

Кроме того, если это именно то, чему нужно следовать, почему руководство не следует этому или, по крайней мере, не упоминает об этом? Разве GSS не должен быть универсальным? Это нормально, что это происходит?

Заранее спасибо :)


java kerberos gssapi
person dram    schedule 22.12.2016    source источник
comment
Обычно RFC не означает, что так должно быть. RFC — это документы, предлагающие новые технологии, и, насколько мне известно, обычно они не обновляются при каждом изменении протокола. Можете ли вы опубликовать токен? Он должен начинаться с YII, чтобы быть токеном kerberos/SPNEGO. Если это так, взгляните на ссылку, которую я разместил в своем исходном вопросе о gssapi, ответ проходит через весь процесс настройки до проверки токена.   -  person Nico    schedule 22.12.2016
comment
Я думаю, что билет в этом ответе и этот токен немного отличаются. Этот токен — это тикер службы kerberos (или что-то в этом роде), а токен, который у меня есть, — это токен GSSAPI (я думаю, что у него есть куча данных, которые GSSAPI использует для установления контекста и т. д.).   -  person dram    schedule 22.12.2016
comment
Это все еще нормально, так как вы можете изменить учетные данные, которые gssapi будет обрабатывать. Просто измените OID на тот, который должен обрабатывать gssapi. final Oid spnegoOid = new Oid( "1.3.6.1.5.5.2" ); GSSManager gssmgr = GSSManager.getInstance(); GSSName serviceName = gssmgr.createName( this.spn, GSSName.NT_USER_NAME ); GSSCredential serviceCredentials = gssmgr.createCredential( serviceName, GSSCredential.INDEFINITE_LIFETIME, spnegoOid, GSSCredential.ACCEPT_ONLY );   -  person Nico    schedule 22.12.2016
comment
Я только что попытался закодировать его в Base64, и вы были правы, это билет spnego: закодированный, это YII.....= Кроме того, что вы имели в виду под приведенным выше кодом? Должен ли я использовать SPNego вместо Kerberos?   -  person dram    schedule 22.12.2016
comment
Да, используйте OID для SPNEGO, поскольку фактический токен kerberos окружен токеном snpego. gssapi сможет развернуть его и получить токен kerberos, где вы сможете использовать GSSContext.unwrap и GSSContext.verifyMIC и все такое. В ответе есть код макета, который вы затем можете изменить в соответствии со своими потребностями.   -  person Nico    schedule 22.12.2016
comment
Я внимательно изучил трассировку сети, когда я вхожу в систему через Chrome, и он отправляет HTTP-запрос GET со строкой заголовка Authorization: Negotiate YII.....   -  person dram    schedule 23.12.2016
comment
Моя программа, однако, отправляет запрос TCP с длиной токена и токеном. Это похоже на то, что вызывает ошибку Invalid Verb (например, ожидается GET или POST, но я просто отправляю материал TCP). (кстати, это не позволило бы мне отредактировать мой комментарий выше, поэтому он разделен на две части)   -  person dram    schedule 23.12.2016