Network Working Group Request for Comments: 4370 Категория: Standards Track R. Weltman (Yahoo!, Inc.) Февраль 2006 года
Этот документ определяет стандарт протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) The Internet Society (2006).
Этот документ определяет элемент управления Proxy Authorization Control в протоколе Lightweight Directory Access Protocol (LDAP). Элемент управления Proxy Authorization Control позволяет клиенту запросить обработку какой-либо операции с правами предоставленной в запросе авторизационной идентификационной сущности, вместо того, чтобы выполнять её с правами текущей авторизационной идентификационной сущности, ассоциированной с соединением, в рамках которого выполняется операция.
Прокси-авторизация позволяет клиенту запросить обработку какой-либо операции с правами предоставленной в запросе авторизационной идентификационной сущности, вместо того, чтобы выполнять её с правами текущей авторизационной идентификационной сущности, ассоциированной с соединением, в рамках которого выполняется операция. В этом документе определяется поддержка прокси-авторизации с помощью механизма элементов управления [RFC2251]. Протокол Lightweight Directory Access Protocol [LDAPV3] поддерживает использование Simple Authentication and Security Layer [SASL] для аутентификации, а также для предоставления авторизационной идентификационной сущности, отличной от аутентификационной идентификационной сущности, при этом данная авторизационная идентификационная сущность применяется ко всему сеансу LDAP. Элемент управления Proxy Authorization Control предоставляет механизм для указания авторизационной идентификационной сущности отдельно для каждой операции в помощь тем клиентам, которым необходимо выполнять операции так, будто они выполняются от имени нескольких пользователей.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "SHOULD" (следует), "SHOULD NOT" (не следует) и "MAY" (возможно) в данном документе должны интерпретироваться так, как описано в [KEYWORDS].
Поддержка элемента управления Proxy Authorization Control обозначается наличием идентификатора объекта (Object Identifier, OID) "2.16.840.1.113730.3.4.18" в атрибуте supportedControl [RFC2252] в корневой специфичной для DSA записи (DSE) сервера.
Одиночный элемент управления Proxy Authorization Control может быть включен в сообщение запроса любой операции search, compare, modify, add, delete, modify Distinguished Name (DN), либо операции-расширения. Исключения составляют любые расширения, вызывающие изменение аутентификации, авторизации или конфиденциальности данных [RFC2829], такие как Start TLS [LDAPTLS], задействующие часть поля controls последовательности LDAPMessage, как определено в [RFC2251].
В поле controlType элемента управления Proxy Authorization Control указывается "2.16.840.1.113730.3.4.18".
Поле criticality должно (MUST) присутствовать и должно (MUST) быть установлено в TRUE. Это требование защищает клиентов от отправки запроса, который выполняется с непреднамеренно предоставленной авторизационной идентификационной сущностью.
Клиенты должны (MUST) включать флаг criticality и должны (MUST) устанавливать его в TRUE. Серверы должны (MUST) отклонять любые запросы, содержащие элемент управления Proxy Authorization Control без флага criticality, либо если этот флаг установлен в FALSE, с ошибкой protocolError. Эти требования защищают клиентов от отправки запроса, который выполняется с непреднамеренно предоставленной авторизационной идентификационной сущностью.
Поле controlValue должно (SHALL) присутствовать и должно (SHALL) либо содержать конструкцию authzId [AUTH], представляющую авторизационную идентификационную сущность для данного запроса, либо быть пустым, если будет использоваться ассоциирование запроса с анонимным пользователем.
Механизм определения прокси-полномочий доступа зависит от принятой на сервере политики прокси-авторизации.
Если запрашиваемая авторизационная идентификационная сущность распознана сервером и клиент имеет право применить данную запрашиваемую авторизационную идентификационную сущность, запрос будет выполнен так, как если бы он был отправлен от имени этой прокси-авторизационной идентификационной сущности; в противном случае будет возвращён результирующий код 123.
Здесь приводится одно из возможных взаимодействий между прокси-авторизацией и нормальным контролем доступа. В процессе оценки записей, которые требуется вернуть в ответ на поисковый запрос, может возникнуть ситуация, когда какая-либо запись, которая должна быть возвращена для данного запроса (если бы он был отправлен напрямую от имени прокси-авторизационной идентификационной сущности), может быть не возвращена, если сервер обнаружит, что у текущего запрашивающего при выполнении операции поиска в отношении данной записи нет полномочий выступать от имени запрашиваемой идентификационной сущности, даже если эта запись попадает в поисковый диапазон запроса в рамках базового DN, подразумевающего такие полномочия. Это означает, что в ответ на такой запрос может быть возвращено меньше записей (либо вообще не возвращено записей), чем в случае, если бы этот запрос выполнялся напрямую прокси-авторизационной идентификационной сущностью. Примером такого случая может быть система с детальным контролем доступа, в рамках которой запрашивающий прокси-права имеет прокси-права на доступ вершине дерева поиска, но не имеет таких прав доступа в какой-либо точке или точках (поддеревьях) внутри этого дерева.
Элемент управления Proxy Authorization Control подчиняется общим соображениям безопасности LDAP [RFC2251] [AUTH] [LDAPTLS]. Он может передаваться как по защищенному, так и по незащищенному каналу.
Данный элемент управления позволяет передать дополнительную авторизационную идентификационную сущность. В некоторых окружениях эти идентификационные сущности могут содержать конфиденциальную информацию, которую требуется защищать от несанкционированного доступа.
Обратите внимание, что сервер ответственен за определение того, должен ли быть удовлетворён запрос прокси-авторизации. "Анонимным" пользователям не следует (SHOULD NOT) позволять выдавать себя за других.
OID "2.16.840.1.113730.3.4.18" зарезервирован для элемента управления Proxy Authorization Control. Он зарегистрирован как механизм протокола LDAP [RFC3383].
Результирующий код (123) был назначен IANA для случая, когда сервер не выполняет запрос с использованием идентификационной сущности прокси-авторизации.
Данный документ рецензировали: Mark Smith, ранее работавший в Netscape Communications Corp., Mark Wahl, ранее работавший в Sun Microsystems, Inc., Kurt Zeilenga из OpenLDAP Foundation, Jim Sermersheim из Novell и Steven Legg из Adacel.
[KEYWORDS] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[LDAPV3] Hodges, J. и R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, сентябрь 2002 г.
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, октябрь 1997 г.
[AUTH] Wahl, M., Alvestrand, H., Hodges, J. и R. Morgan, "Authentication Methods for LDAP", RFC 2829, май 2000 г.
[LDAPTLS] Hodges, J., Morgan, R. и M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, май 2000 г.
[RFC2251] Wahl, M., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, декабрь 1997 г.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, декабрь 1997 г.
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. и R. Morgan, "Authentication Methods for LDAP", RFC 2829, май 2000 г.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, сентябрь 2002 г.
Rob Weltman
Yahoo!, Inc., 701 First Avenue, Sunnyvale, CA 94089, USA
Телефон: +1 408 349-5504
EMail: robw@worldspot.com
Copyright (C) Internet Society (2006).
На этот документ распространяются права, лицензии и ограничения, содержащиеся в BCP 78, и, за исключением случаев, изложенных в нём, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и АВТОР ДОКУМЕНТА, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ, ИЛИ КОТОРОЙ ОН/ОНА СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВЫЕ ИМЕЮТСЯ), INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
IETF не занимает никакой позиции относительно действительности или области действия каких-либо прав на интеллектуальную собственность или других прав, которые могут заявляться как относящиеся к реализации или использованию технологий, описанных в данном документе, либо в подтверждении которых могут или не могут быть доступны какие-либо лицензии; кроме того, IETF не заявляет о том, что она будет предпринимать какие-либо независимые усилия по выявлению подобных прав. Информацию по процедурам в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии поданных в секретариат IETF заявлений о правах на интеллектуальную собственность (Intellectual Property Rights, IPR), а также какие-либо документы, подтверждающие лицензию и предназначенные для предоставления доступа к ним, либо результаты попыток получения генеральных лицензий или разрешений на пользование подобными правами собственности могут быть получены теми, кто занимается реализацией, или пользователями данной спецификации из он-лайн репозитория IPR IETF по адресу http://www.ietf.org/ipr.
IETF просит всех заинтересованных лиц довести до её сведения любые авторские права, патенты или патентные заявки, либо другие права собственности, которые могут касаться технологий данного стандарта и могут потребоваться для его реализации. Пожалуйста, направляйте информацию в IETF по адресу ietf-ipr@ietf.org.
Финансирование функций RFC Editor обеспечивается IETF Administrative Support Activity (IASA).