Дыра в безопасности в GSSContext метод acceptSecContext? (ДЖАВА)
Когда билет службы, сгенерированный клиентом, отправляется на сервер, метод GSSContext acceptSecContext должен декодировать такой билет, который был закодирован KDC.
когда этот метод вызывается с сервисным билетом в качестве его параметра, действительно ли этот билет отправляется в сам KDC для декодирования?
В противном случае это не будет проблемой безопасности? потому что, если сервер может декодировать любой действительный билет, о котором он ничего не знает, кроме какого-то отправленного ему клиента или для чего или для кого предназначен билет?
немного смущен
Любые разъяснения с благодарностью.
Я читал, что Сервер приложений и KDC общаются, но я не думаю, что это всегда так.
например, посмотрите на пример кода сервера
Сервер приложений входит в систему, чтобы получить контекст
LoginContext loginCtx = null;
loginCtx = new LoginContext("SPN", new LoginCallbackHandler( id, password ));
loginCtx.login();
Subject subject = loginCtx.getSubject();
затем, используя этот sujbect, он выполнит превалирующие doAs
Subject.doAs( subject, new PrivilegedAction<String>() {
public void run() {
try {
GSSManager manager = GSSManager.getInstance();
GSSContext context = manager.createContext( (GSSCredential) null);
context.acceptSecContext( serviceTicket, 0, serviceTicket.length);
// now do something with decoded ticket
}
...
}
1 ответ
действительно ли билет отправляется на сам KDC для декодирования?
Нет, сервер приложений и KDC
не общайся
Вот почему вы должны скопировать keytab
генерируется на KDC
на сервер приложений перед использованием системы.
Сервер пытается расшифровать билет, и если он может это сделать, он предполагает, что билет был сгенерирован KDC
, потому что он единственный, кто знает пароль, то это действительный билет.
Предварительный обмен ключами / паролями до того, как система будет эффективно включена, а затем никогда не отправлять ее по сети, является распространенным механизмом во многих протоколах аутентификации, например, радиус