Есть ли способ в Java или утилите командной строки, чтобы получить билет Kerberos для службы, использующей собственный API SSPI? - PullRequest
18 голосов
/ 25 февраля 2010

Я хочу реализовать единый вход в Kerberos в Java, и мне удалось создать билет для Сервиса, используя билет из входа в Windows.К сожалению, я могу создать этот тикет только тогда, когда ключ реестра «allowtgtsessionkey» включен.Я получаю исключение с сообщением «Идентификатор не соответствует ожидаемому значению (906)», как только я его отключаю.Раздел реестра задокументирован на http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html и http://support.microsoft.com/kb/308339.

К сожалению, у меня нет доступа к реестру на компьютерах, где будет использоваться мое приложение, поэтому я ищу способ сделатьэто без необходимости изменять его.Когда я делаю однократную регистрацию через SPNEGO в Internet Explorer или Mozilla Firefox, они создают билет службы в моем кэше билетов, поэтому определенно должен быть способ сделать это без установки ключа реестра.У кого-нибудь есть идеи, как это сделать на Java?

Спасибо за вашу помощь, memminger

Обновление: я отказываюсь от этой проблемы.Раздел реестра Windows запрещает доступ к Билету (точнее: Предмету) внутри кеша Билета.Java в Windows использует свою собственную реализацию GSSAPI, и я полагаю, что для создания Service Ticket необходим доступ к Ticket.Windows API SSPI, тем не менее, имеет полный доступ к кешу билетов и, таким образом, может создавать билеты службы.Этот API используется веб-браузерами, но не используется Java (в соответствии с http://java.sun.com/developer/technicalArticles/J2SE/security/#3). Когда я отключаю SSPI в Firefox после однократного доступа к веб-странице (таким образом, был создан билет службы), я могупо-прежнему обращайтесь к странице, поэтому, возможно, будет достаточно утилиты командной строки, которая создает билет службы с помощью API SPPI.

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

Ответы [ 3 ]

4 голосов
/ 28 февраля 2010

Простите, если я неправильно понимаю вашу проблему, но ...

Суть систем типа SSO заключается в том, что клиент аутентифицируется непосредственно на (отдельном) сервере аутентификации и получает от него билет. Затем он передает билет целевому серверу (серверам), который он хочет использовать, каждый из которых проверяет, что билет действителен с сервером аутентификации. Если билет подтвержден, сервер может предположить, что клиент получил его, только представив (доверенный) сервер Kerberos с приемлемыми учетными данными.

Нигде в процессе, любой сервер должен аутентифицировать от имени клиента. В такой системе единственным сервером, который должен знать и проверять учетные данные клиента, является сервер аутентификации - никакой другой сервер не должен иметь доступ к этой информации. Таким образом, клиент может проходить аутентификацию для многих серверов с помощью всего одного обмена аутентификацией, и учетные данные не подвергаются риску, поскольку хранятся или доступны для нескольких серверов.

Похоже, ваша реализация работает так, как и должна - аутентификация должна произойти на стороне клиента приложения, и это правильно, а не представляет угрозу безопасности.

1 голос
/ 05 октября 2015

Вы можете получить доступ к собственному API SSPI через JNA . См. WindowsAuthProviderImpl в WAFFLE или WindowsNegotiateScheme из библиотеки Apache HC для примера.

1 голос
/ 08 июля 2010

Вы пробовали установить sun.security.jgss.native в Java 6? Разве SSPI не будет «родным» интерфейсом для Windows?

...