Proxy Chest

Proxy Chest -- это планируемая реинкарнация MyProxy, которая будет использовать для транспорта протокол HTTPS.

Что плохо в MyProxy

• Протокол, основанный на GSSAPI и его расширениях от Globus Alliance (GSI): это не позволяет сделать достаточно простых клиентов, ибо им нужно тащить за собой какую-то реализацию GSI, что не всегда хорошо.
• Плохая реализуемость раздельной аутентификации, основанной на нескольких факторах: если я хочу сделать обновление proxy-сертификата (renewal), но MyProxy дополнительно аутентифицирует клиента по сертификату узла, с которого он делает обновление, то необходимо давать клиенту доступ и к proxy-сертификату, и к сертификату узла, что не всегда хорошо.

Что планируется

• Реализация сервера поверх протокола HTTPS: клиенты смогут использовать стандартные или практически стандартные (с поправкой на реализацию проверки proxy-сертификатов) библиотеки.
• Отделение аутентификации узла, с которого посылается клиентский запрос от аутентификации самого клиента: планируется, что на узле будет работать сервис, к которому смогут обращаться локальные клиенты и который будет аутентифицировать сам узел с помощью cookie-подобного механизма:
  1. клиенту высылается код операции 401;
  2. клиент делает запрос к локальному сервису аутентификации узла;
  3. сервис проверяет, разрешено ли обслуживать этого клиента, и отправляет запрос на аутентификацию к серверу Proxy Chest (простой HTTP-запрос с авторизацией по сертификату);
  4. сервер Proxy Chest выдает в ответ cookie и запоминает соответствие DN клиента (сервиса авторизации узла) и cookie, а также время создания данной пары (cookie, DN);
  5. сервис возвращает cookie клиенту;
  6. клиент повторяет запрос, в который включен этот cookie;
  7. сервер Proxy Chest проверяет cookie и принимает решение о привильности этого фактора аутентификации;
  8. периодически, сервер Proxy Chest удаляет отжившие пары (cookie, DN); период жизни пары настраивается на сервере.

Такое отделение аутентификации узла позволит обойти проблемы с доступом к сертификату узла: этим будет заниматься специальный сервис.

• Делегирование сертификатов от клиента к Proxy Chest и от Proxy Chest к клиенту реализуется с помощью HTTP-запросов: делегирующая сторона высылает запрос на подписание делегируемого сертификата, делегирующая сторона подписывает запрос и отправляет результат обратно. В случае делегирования сертификата на сервер Proxy Chest, это делается в две стадии:
  1. клиент уведомляет сервер о желании делегировать proxy, на что сервер отвечает запросом на сертификат (CSR) и сохраняет информацию о запросе; возможно, клиенту возвращается идентификатор запроса, который будет использоваться в следующей части диалога;
  2. клиент подписывает CSR и отправляет его на сервер в следующем запросе.

Очевидно, что чистого REST здесь не будет (будет храниться информация о состоянии между этими двумя запросами), но особенной проблемы я в этом пока не вижу. Естественно, отжившая свое информация о сгенерированных CSR на сервере должна периодически удаляться. Поскольку, я надеюсь на функционирование keep-alive, несколько запросов подряд от одного клиента не должны очень негативно сказываться на производительности: SSL-handshake будет делаться только один раз.

Связанные вопросы

Очевидно, что, например для Proxytool, да и для клентского Java GUI, вопрос о полном отказе от Globus Toolkit не заканчивается на переходе к Proxy Chest: еще есть проблема создания и работы с proxy-сертификатами. Здесь есть надежда на то, что реализация этой функциональности, не привязанная к Globus Toolkit, будет не очень сложной, поскольку весь вопрос в правильной интерпретации специфичных для RFC proxy-сертификатов расширений X.509 и работе с ними.