GSS-API
GSS-API (GSS, GSSAPI, англ. Generic Security Services API, общий программный интерфейс сервисов безопасности) — API для доступа к сервисам безопасности. Описан в стандарте IETF. Предназначен для решения проблемы несовместимости схожих сервисов безопасности.
Описание
[править | править код]GSS-API сам по себе не обеспечивает сервисов безопасности, вместо этого он обеспечивает интерфейс между приложениями и реализациями GSSAPI (обычно библиотеками). Эти библиотеки обеспечивают совместимый с GSS-API интерфейс, позволяя создавать приложения, способные работать с разными библиотеками безопасности; позволяя заменять библиотеки без необходимости переписывать приложения.
Отличительной особенностью приложений, реализованных с использованием GSSAPI является использование закрытых сообщений (токенов), которые скрывают подробности реализации от вышестоящих приложений. Серверная и клиентская часть приложений создаются таким образом, чтобы взаимодействовать с помощью токенов GSSAPI. Токены обычно могут передаваться через незащищённую (публичную) сеть. После обмена сторонами (клиентом и сервером) некоторым количеством сообщений, библиотека GSSAPI информирует обе стороны взаимодействия об установлении безопасного контекста.
После установления безопасного контекста защищаемые сообщения приложения могут быть «завёрнуты» (зашифрованы) с помощью GSSAPI для безопасной передачи между сервером и клиентом.
Типичные аспекты безопасности, обеспечиваемые библиотеками, реализующими GSSAPI:
- конфиденциальность
- целостность
- подлинность обеих сторон информационного обмена
GSSAPI описывает примерно 45 вызовов. Основные:
- GSS_Acquire_cred — получение пользовательского доказательства идентичности (чаще всего закрытый ключ, пароль)
- GSS_Import_name — конвертирование имени пользователя, узла сети в форму, позволяющую определить объект безопасности
- GSS_Init_sec_context — создаёт клиентский токен для отсылки на сервер (обычно вызов, в рамках модели Вызов-ответ (аутентификация))
- GSS_Accept_sec_context — обрабатывает токен, созданный с помощью GSS_Init_sec_context и, возможно, возвращает токен ответа
- GSS_Wrap — конвертирует данные приложения в форму защищённого сообщения (обычно шифрация)
- GSS_Unwrap — извлекает из защищённого сообщения данные приложения (обычно расшифровка)
GSSAPI был стандартизирован для языков C (RFC 2744) и Java (JSR-072).
К ограничениям GSSAPI можно отнести то, что он стандартизирует только аутентификацию, но не авторизацию, и что он предполагает архитектуру клиент–сервер.
Предполагая появление новых механизмов безопасности, GSSAPI включает в себя специальный псевдо-механизм, SPNEGO, который позволяет обнаруживать и использовать механизмы не существовавшие на момент, когда приложение было собрано.
Связь с Kerberos
[править | править код]GSSAPI часто применяется в связке с Kerberos. В отличие от GSSAPI, API Kerberos не стандартизирован (и существуют несовместимые API). GSSAPI позволяет использовать разные реализации Kerberos без изменения кода приложения.
Близкие технологии
[править | править код]Основные термины GSSAPI
[править | править код]- Name (имя) — двоичная строка для обозначения идентификатора (имя пользователя, приложения и т. д.) Например, Kerberos использует формат 'user@REALM для пользователей и service/hostname@REALM для приложений.
- Credential (удостоверение) — информация, доказывающая подлинность объекта (обычно пароль или закрытый ключ).
- Context (контекст) — состояние канала связи
- Token (токен) — непрозрачное (для приложения) сообщение, которое отсылается на этапе установления соединения или в ходе передачи защищённого сообщения
- Mechanism (механизм) — реализация нижележащего уровня GSSAPI, обеспечивающая фактические имя, удостоверение и токены. Типичные механизмы: Kerberos, NTLM, DCE, SESAME, SPKM, LIPKEY.
- Initiator/acceptor (инициатор/получатель) — сторона, отправляющая первый токен является инициатором; противоположная сторона — получатель. Обычно получателем является сервер, а инициатором клиент.
История
[править | править код]- Июль 1991: рабочая группа IETF CAT (Common Authentication Technology) провела встречу в Атланте под руководством Джона Линна (John Linn)
- Сентябрь 1993: Опубликована GSSAPI версия 1 (RFC 1508, RFC 1509)
- Май 1995: В составе Windows NT 3.51 вышла реализация SSPI
- Июнь 1996: Вышел механизм Kerberos для GSSAPI (RFC 1964)
- Январь 1997: GSSAPI версия 2 (RFC 2078)
- Октябрь 1997: Опубликован стандарт SASL, включающий механизм GSSAPI (RFC 2222)
- Январь 2000: Обновление 1 для GSSAPI версии 2 (RFC 2743, RFC 2744)
- Август 2004: Встреча рабочей группы KITTEN (продолжение работы CAT)
- Май 2006: Стандартизировано использование GSSAPI для SSH (RFC 4462)
См. также
[править | править код]Ссылки
[править | править код]- RFC 2743 The Generic Security Service API Version 2 update 1
- RFC 2744 The Generic Security Service API Version 2: C-Bindings
- RFC 1964 The Kerberos 5 GSS-API mechanism
- RFC 4121 The Kerberos 5 GSS-API mechanism: Version 2
- RFC 4178 The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
- RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM)
- RFC 2847 LIPKEY — A Low Infrastructure Public Key Mechanism Using SPKM
- Kitten working group — next generation GSS-API
- GSS-API Programming Guide from Sun