Обобщенный прикладной программный интерфейс службы безопасности GSS-API — это "всего лишь" спецификации, приобретающие реальную силу, только если за ними стоят конкретные системы. Мы рассмотрим две разновидности подобных систем — Kerberos и службы безопасности, основанные на рекомендациях X.509.
Данный раздел предназначен для тех, кто знаком с соответствующими службами.
Понятия системы Kerberos можно отображать на понятия обобщенного интерфейса безопасности GSS-API разными способами. Мы рассмотрим простейший из них.
Роль удостоверения выполняет билет на билеты (в терминологии Kerberos — Ticket Granting Ticket, TGT). Функция GSS_Acquire_cred выдаст дескриптор удостоверения.
Функция GSS_Init_sec_ context пройдет маршрут от локальной области управления до удаленной, в которой располагается сервер, и получит билет к серверу. В контекст безопасности, помимо прочих данных, войдет сгенерированный сеансовый ключ. Функция GSS_Init_ sec_context вернет в качестве токена безопасности сообщение, имеющее Kerberos-формат KRB_AP_REQ и использующееся при аутентификационном обмене клиент/сервер.
После получения сервером сообщения KRB_AP_REQ и его обработки функцией GSS_Accept_sec_context, обе стороны будут располагать общим сеансовым ключом, который они смогут использовать для защиты пересылаемых сообщений. Если требуется взаимная аутентификация, сервер должен переслать клиенту Kerberos-сообщение KRP_AP_ REP.
Естественным образом устанавливается соответствие между сроками годности удостоверений и контекстов с одной стороны, и сроками годности соответствующих билетов (обычных или предназначенных для получения других билетов) с другой стороны.
Выше было отмечено, что интерфейс GSS-API предусматривает возможность делегирования полномочий. Аналогичное средство имеется и в системе Kerberos (флаги PROXIABLE, PROXY, FORWARDABLE, FORWARDED).
Как известно, рекомендации X.509 предусматривают использование шифрования с открытыми ключами.
Функция GSS_Acquire_ cred формирует удостоверение, в которое входит секретный ключ пользователя. Тем самым открывается доступ к этому ключу от имени пользователя.
Функция GSS_Init_sec_ context получает от службы директорий заверенный сертификат сервера. Тем самым для клиента становится доступным открытый ключ сервера. GSS_Init_ sec_context генерирует сеансовый ключ (как часть контекста безопасности) и шифрует его открытым ключом сервера (для вставки в выходной токен). Сеансовый ключ будет использоваться для защиты сообщений, пересылаемых между клиентом и сервером. В токен, выдаваемый функцией GSS_Init_sec_context, помимо зашифрованного сеансового ключа включаются сведения о клиенте, зашифрованные его (клиента) секретным ключом. Таким образом гарантируется конфиденциальность сеансового ключа (только сервер сможет его расшифровать) и достоверность информации о клиенте (поскольку она заверена его электронной подписью).
Функция GSS_Accept_ sec_context, вызываемая сервером, получает от службы директорий сертификат клиента и, в частности, его открытый ключ. После этого становится возможной проверка подлинности присланного токена безопасности и аутентификация клиента. Сервер расшифровывает своим секретным ключом присланный в токене сеансовый ключ. После этого может начаться эффективный обмен защищенными сообщениями между клиентом и сервером.
|
|
|
|
| Логика работы пользователей интерфейса безопасности | Содержание | Детальное описание некоторых функций безопасности |
| Copyright ╘ 1993-2000, Jet Infosystems |