Сервис MyProxy

В нашем проекте сервис MyProxy используется для хранения и передачи пользовательских proxy-сертификатов между пользователем и (в-основном) Web UI. Также он используется как сервис для обновления действительных proxy-сертификатов, время жизни которых близится к концу.

В настоящий момент доступен единственный сервер MyProxy, nghoop.grid.kiae.ru.

Общий сценарий работы

Сначала пользователь помещает на сервер MyProxy долгосрочный proxy-сертификат. В данный момент это можно сделать только с помощью утилиты proxytool, однако в скором времени планируется возникновение Java-утилиты.

Далее, пользователь заходит на Web UI, аутентифицируясь там с использованием своего X.509-сертификата и вводит пароль для своего сертификата на MyProxy. Web UI забирает первоначальный сертификат, используя DN пользователя, его пароль и свой сертификат узла, и начинает работать с этим proxy-сертификатом.

Далее сертификат попадает на сервер Pilot, причем он не делегируется, а передается как есть.

С сервера Pilot сертификат может быть делегирован на сервис WS GRAM или использован для операций с другими сервисами (передача данных).

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

Детали реализации схемы работы с proxy-сертификатами

В данном разделе рассказано, как реализована логика работы с разными типами proxy-сертификатов в CLI Proxytool, которая рассматривается как базовая схема для реализации во всех других приложениях, работающих с proxy-сертификатами.

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

Proxytool реализует два типа credential name: с префиксом "initial:" и с префиксом "renewable:".

На разные credential name вешаются разные ACL. На "initial:" -- retrievers с DN, указанным ключом -T/--retriever, а на "renewable:" -- renewers с DN, указанным ключом -N/--renewer. При этом на "initial:" еще вешается пароль, а на "renewable:" -- нет.

Различия и сходства между этими credential name таковы: везде используется two-factor authentication, но

• для initial -- это пароль и сертификат узла, который затаскивает к себе proxy (у нас это в данный момент, видимо, исключительно ВИГ),
• а для renewable -- это существующий proxy и сертификат узла, который proxy обновляет (сейчас это ВИГ и Pilot).

То есть, если вы хотите разрешить узлу с DN "A" делегировать к себе цепочку с вашим сертификатом не имея при себе уже существующего вашего proxy-сертификата, то этому соответствует загруженная цепочка с credential name "initial:A". На эту цепочку будет повешен ACL для MyProxy "RETRIEVERS=A".

А если сервису с DN "B" нужно обновлять уже существующий у него proxy-сертификат, то этому будет соответствовать цепочка с credential name "renewable:B". ACL для нее будет иметь вид "RENEWERS=B".

Почему недостаточно иметь просто renewable

Потому что на него вешается политика "RENEWERS", которая предполагает наличие у клиента MyProxy существующего proxy-сертификата.

Почему нельзя делать initial с пустым паролем

В этом случае любые люди, получившие сертификат ВИГ (или действующий proxy-сертификат), могут тут же получить доступ ко всем proxy. В схеме с initial, пароль для которого всегда присутствует, нужно еще и знать этот самый пароль. Я именно поэтому в билете #920 написал, что пустых паролей лучше не делать, ибо это прямой путь известно куда.