Network Working Group Request for Comments: 2589 Категория: Standards Track Y. Yaacovi (Microsoft), M. Wahl (Innosoft International, Inc.), T. Genovese (Microsoft) Май 1999 года
Этот документ определяет стандарт протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) The Internet Society (1999). Все права защищены.
В этом документе определяются требования для динамических служб каталогов, а также даётся спецификация формата запроса и ответа операций-расширений для поддержки клиент-серверного взаимодействия в среде динамических каталогов.
Протокол Lightweight Directory Access Protocol (LDAP) [1] поддерживает простой доступ к статическим службам каталогов, позволяющий относительно быстро выполнять поиск и обновление. В статических службах каталогов хранится информация о людях, которая не теряет своей актуальности и значимости в течение длительного периода времени.
Отличие динамических служб каталогов в том, что хранящаяся в них информация остаётся актуальной и значимой лишь в том случае, если она периодически подновляется. Такая информация хранится в виде динамических записей в каталоге. Типичный пример использования: клиент или человек может быть либо онлайн, тогда его запись присутствует в каталоге, либо оффлайн, тогда его запись исчезает из каталога. Хотя операции протокола и атрибуты, используемые динамическими службами каталогов, аналогичны тем, которые используются в статических службах каталогов, клиенты, хранящие динамическую информацию в каталоге, должны периодически подновлять эту информацию, чтобы предотвратить её исчезновение. Если динамические записи не были подновлены до истечения заданного таймаута, они будут удалены из каталога. Например, такое произойдёт, если клиент, создавший записи, прекратит работу в системе (окажется оффлайн).
Также в данном документе описывается механизм, с помощью которого сервер может контролировать ход работы и информировать клиентов о том, как часто им следует подтверждать факт своего присутствия.
Предполагаемые расширения протокола должны разрешать доступ к динамической информации в каталоге в стандартной манере LDAP, что позволит клиентам одним и тем же способом получать доступ как к статической, так и к динамической информации.
По определению, динамические записи не являются постоянными, и клиенты, породившие эти записи, могут завершить работу правильно или неправильно. Предполагаемые расширения должны предоставлять серверу возможность сообщать, остаются ли записи действительными, и делать это способом, у которого есть возможность масштабирования. Также должен быть предусмотрен механизм, позволяющий клиенту восстановить свою запись на сервере.
У клиента должна быть возможность в стандартной манере LDAP определить, поддерживает ли сервер динамические расширения.
Наконец, чтобы клиенты могли широко использовать динамические расширения, такие расширения должны быть зарегистрированы как стандартные операции-расширения LDAP.
В протоколе Lightweight Directory Access Protocol (LDAP) [1] разрешено добавление запросов и ответов дополнительных операций. В данной спецификации эта возможность используется для полноценной интеграции с LDAP каталогов, содержащих динамическую информацию.
Описанный в данном документе подход определяет динамические записи с целью сделать возможным реализацию каталогов с динамической информацией. Релизации динамических каталогов должны быть способны поддерживать динамические записи каталога.
Динамическая запись представляет собой объект в дереве каталога, у которого есть ассоциированное с ним время жизни. Это время жизни задаётся при создании записи. Время жизни автоматически уменьшается, и когда оно истекает, динамическая запись исчезает. Путём вызова операции-расширения подновления (определена ниже), цель которой — повторно установить время жизни, клиент может продлить существование записи ещё на некоторое время.
Динамическая запись создаётся путём включения в список атрибутов атрибута objectClass со значением, приведённым в разделе 5, при создании записи. При этом должны быть соблюдены все стандартные ограничения контроля доступа.
Описанная в этом документе операция-расширение позволяет клиенту подновлять динамическую запись путём периодического вызова операций подновления, содержащих имя этой записи. При обработке операций Search, Compare, Add, Delete, Modify и ModifyDN динамические записи будут рассматриваться так же, как и нединамические записи. Однако, если клиент прекращает отправлять запросы операции подновления для записи, то сервер автоматически и без предупреждения удалит эту запись из каталога. Такое удаление будет рассматриваться так же, как если бы запись была удалена стандартной операцией протокола LDAP.
Способа преобразовать статическую запись в динамическую и наоборот не существует. Если клиент использует операцию Modify для добавления значения dynamicObject атрибуту objectClass в статической записи, сервер должен вернуть одну из служебных ошибок: "objectClassModsProhibited" (если на сервере в принципе запрещена модификация объектных классов) или "objectClassViolation" (если модификация объектных классов на сервере в общем случае разрешена).
Динамическая запись может быть удалена клиентом с использованием операции Delete. При этом должны быть соблюдены все стандартные ограничения контроля доступа.
Нединамическая запись не может быть добавлена в качестве подчинённой к динамической записи. При попытке такого добавления сервер должен вернуть соответствующую ошибку обновления или служебную ошибку.
Вопросы поддержки динамических атрибутов иных статических объектов выходят за рамки этого документа.
Согласно определению объектного класса dynamicObject, у записи с этим классом имеется связанное с ней время жизни, и более никаких особых свойств. Хотя наиболее распространённым динамическим объектом является объект, представляющий собой человека, как уже было сказано, не существует каких-либо специальных типов записи, связанных с объектным классом dynamicObject. Используя атрибуты динамического объекта, можно создать объект, представляющий собой практически всё, что угодно.
В частности, в виде динамических объектов могут быть представлены собрания (конференции). Полнофункциональная поддержка собраний требует специальной семантики и обработки на стороне сервера (и не входит в рамки этого документа). Описанное в этом документе расширение обеспечивает базовую поддержку собраний. Объект собрания может подновляться участниками этого собрания, при прекращении подновлений запись собрания исчезает. Один из типов собраний, который напрямую поддерживается данным расширением динамических объектов, — это собрание, управляемое инициатором.
Управляемые инициатором собрания создаются клиентом, который задаёт для записи атрибут времени жизни, и этот клиент ответственен за подновление записи собрания для того, чтобы она не исчезла. Другие могут присоединиться к собранию путём модификации соответствующих атрибутов, но им не разрешено подновлять эту запись. Когда клиент, создавший запись собрания, заканчивает работу, он может удалить запись собрания, либо она может исчезнуть по истечении времени жизни динамического объекта. Это соответствует общей модели описанных выше объектов с классом dynamicObject.
Подновление представляет собой операцию протокола, с помощью которой клиент сообщает серверу, что он всё ещё доступен, и что запись динамического каталога всё ещё остаётся актуальной и значимой. Клиент посылает запрос Refresh с периодичностью, основанной на значении так называемого клиентского периода подновления (Client refresh period, CRP). Сервер может запросить изменение этого значения клиентом. Пока сервер получает запросы Refresh до истечения времени таймаута, присутствие записи каталога на сервере гарантируется. Разработчикам клиентов следует иметь ввиду, что из-за ненадёжности сетевого соединения между клиентом и сервером пакеты запросов Refresh при передаче могут быть задержаны или потеряны. Если такое произойдёт, запись может исчезнуть, и клиенту будет необходимо определить это и повторно добавить ту же запись.
Клиент может запросить описываемую операцию путём передачи LDAP PDU, содержащего запрос расширенной операции ExtendedRequest. LDAP-запрос ExtendedRequest определяется следующим образом:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
В поле requestName должна быть установлена строка "1.3.6.1.4.1.1466.101.119.1".
В поле requestValue будет содержаться значение, представляющее собой закодированные в DER данные ASN.1 следующего типа:
SEQUENCE {
entryName [0] LDAPDN,
requestTtl [1] INTEGER
}
Поле entryName представляет собой строковое представление имени динамической записи в кодировке UTF-8 [3]. Эта запись уже должна существовать.
Значение в поле requestTtl — это время в секундах (от 1 до 31557600), запрашиваемое клиентом как время существования данной записи в каталоге до её автоматического удаления. От сервера не требуется принятия данного значения, он может вернуть клиенту другое значение TTL. Клиенты должны иметь возможность использовать это указанное сервером значение в качестве своего CRP.
Если сервер поддерживает данное расширение, то при поступлении запроса он будет возвращать LDAP PDU, содержащий ответ расширенной операции ExtendedResponse. LDAP-ответ ExtendedResponse определяется следующим образом:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
В поле responseName содержится та же строка, которая присутствовала в запросе.
В поле response будет содержаться значение, представляющее собой закодированные в DER данные ASN.1 следующего типа:
SEQUENCE {
responseTtl [1] INTEGER
}
Значение в поле responseTtl — это время в секундах, которое сервер выбрал в качестве времени жизни для данной записи. Оно не должно быть меньше того, которое запрашивал клиент, но оно может быть больше запрошенного. Однако, для того, чтобы позволить серверам поддерживать каталог в более-менее аккуратном состоянии, а также запретить клиентам злоупотреблять динамическими расширениями, серверам разрешается сокращать запрошенное клиентом значение времени жизни до минимального значения в 86400 секунд (одни сутки).
Если операция завершилась успешно, поле errorCode в части standardResponse ответа ExtendedResponse должно быть установлено в success.
При возникновении ошибки, в поле responseTtl должно быть значение 0, а поле errorCode должно содержать одно из следующих значений, подходящее по ситуации:
Если сервер не реализует данное расширение, он должен вернуть LDAP PDU, содержащий ответ расширенной операции ExtendedResponse, в котором содержится только элемент standardResponse (элементы responseName и response должны отсутствовать). В элементе LDAPResult должен быть указан результирующий код protocolError.
Разрешено вызывать данный запрос в случаях, когда LDAP работает поверх транспорта, не предусматривающего установку соединения.
При использовании транспорта, ориентированного на установку соединений, не выдвигается требований, чтобы данная операция использовала то же соединение, что и все остальные операции. Клиент может открыть несколько соединений, либо закрыть и открыть соединение по новой.
Серверы X.500/DAP могут отображать запросы и ответы операции Refresh в операцию X.500/DAP Modify(97).
У всех динамических записей в атрибуте objectClass должно быть значение dynamicObject. Данный объектный класс определён следующим образом (с использованием нотации ObjectClassDescription, описанной в [2]):
( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
DESC 'Данный класс, при его наличии в записи, указывает на то,
что у этой записи ограниченное время жизни, и она может
автоматически исчезнуть, когда это время жизни достигнет нуля.
Для этого класса не определено обязательных атрибутов, однако,
если клиент не предоставил значения для атрибута entryTtl,
сервер предоставит своё.'
SUP top AUXILIARY )
Кроме того, в динамической записи должен присутствовать операционный атрибут, определённый ниже. Он определён с использованием нотации AttributeTypeDescription, описанной в [2]:
( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
DESC 'Этот операционный атрибут поддерживается сервером, и, по-видимому,
присутствует в каждой динамической записи. Этот атрибут не присутствует,
если запись не содержит объектного класса dynamicObject. Значение
этого атрибута представляет собой время в секундах, в течение
которого запись продолжит существовать до исчезновения из каталога.
При отсутствии промежуточных операций подновления, значения, получаемые
путём прочтения атрибута двумя последовательными операциями поиска,
гарантировано не будут увеличиваться. Минимально допустимое значение - 0,
указывает на то, что запись может исчезнуть без предупреждения. Данный
атрибут помечен как неизменяемый пользователем (NO-USER-MODIFICATION),
поскольку его можно изменить только с помощью операции подновления.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
NO-USER-MODIFICATION USAGE dSAOperation )
Следующий операционный атрибут определён для того, чтобы позволить серверам поддерживать динамические записи только в части DIT. Он определён с использованием нотации AttributeTypeDescription, описанной в [2]:
( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees'
DESC 'Этот операционный атрибут поддерживается сервером и присутствует в записи
Root DSE, если сервер поддерживает описанные в данном документе
динамические расширения. В атрибуте содержится список всех поддеревьев
каталога, для которых сервер поддерживает динамические расширения.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
USAGE dSAOperation )
Клиенты могут определить, поддерживает ли сервер описываемые динамические расширения, путём проверки поля supportedExtension в записи Root DSE на предмет присутствия в нём идентификатора объекта OBJECT IDENTIFIER, описанного в разделе 4. Поскольку сервер может установить поддержку динамических расширений только на некоторых поддеревьях DIT, клиенты должны проверять операционный атрибут dynamicSubtrees в Root DSE для определения того, поддерживаются ли динамические расширения в конкретном поддереве.
После создания динамической записи клиенты несут ответственность за вызов расширенной операции Refresh для сохранения этой записи в каталоге.
Клиенты не должны ожидать, что динамическая запись будет присутствовать в DIT после того, как время её жизни истекло. Однако, не выдвигается требования, чтобы сервер удалял такую запись немедленно (некоторые серверы могут отрабатывать таймаут записей через установленные интервалы времени). Если клиент хочет убедиться, что записи не существует, ему следует запросить для такой записи выполнение RemoveRequest.
Первоначально клиенту требуется знать, как часто ему нужно посылать серверу запросы Refresh. Это значение определяется как CRP (Client Refresh Period, клиентский период подновления) и устанавливается сервером на основе entryTtl.
Поскольку данный документ не вносит изменения в LDAP-запрос AddRequest, и этот запрос не вернёт данное значение, клиент должен выполнить расширенную операцию Refresh сразу за операцией Add, создающей динамическую запись. Ответ Refresh вернёт клиенту CRP (в поле responseTtl).
Клиенты не должны выполнять запросы Refresh для динамических записей, которые создавали не они. Если анонимный клиент пытается сделать это, серверу разрешается вернуть ошибку insufficientAccessRights (50) в ответе RefreshResponse, принуждая клиента сначала выполнить подсоединение к каталогу. Имейте ввиду, что серверы, позволяющие анонимным клиентам создавать и подновлять динамические записи, не смогут обеспечить такое поведение.
Клиентам следует всегда быть готовым к ситуации, когда время жизни их записи истечёт. В этом случае операция Refresh завершится неудачей с кодом ошибки наподобие noSuchObject, и ожидается, что клиент заново создаст свою запись.
Клиентам следует быть готовым к ситуации, когда операции Refresh завершатся неудачей с ошибкой protocolError, даже если операция Add и предыдущие операции Refresh завершились успешно. Такое может произойти, если посредник (прокси-сервер) между клиентом и сервером прекратил работу, а другой посредник, на использование которого был осуществлён переход, не поддерживает расширенную операцию Refresh.
Серверы несут ответственность за удаление динамических записей, когда время их жизни истекло. Серверы не обязаны это делать немедленно.
Серверы должны обеспечивать соблюдение структурных правил, перечисленных в разделе 3.
Серверы должны обеспечить, чтобы описанные в разделе 5 операционные атрибуты присутствовали в динамических записях.
Серверы могут разрешать анонимным пользователям подновлять записи. Однако, для того, чтобы исключить возможность злонамеренного использования операции Refresh, серверы могут потребовать от клиентов, пытающихся выполнить подновление записи, сначала осуществить подсоединение к каталогу. Реализация сервера может добиться этого путём назначения ACL на атрибут entryTtl и возвращения ошибки insufficientAccessRights (50) в ответе RefreshResponse, если клиенту не разрешено подновлять данную запись. С другой стороны, это может снизить производительность сервера, а также повлиять на его масштабируемость.
Серверы могут требовать, чтобы у клиента, пытающегося создать динамическую запись, были права на удаление такой записи.
Серверы, реализующие описываемые динамические расширения, должны иметь в качестве значения в поле supportedExtension записи Root DSE описанный в разделе 4 идентификатор объекта (OBJECT IDENTIFIER) для запроса и ответа. Также они должны иметь в качестве значений атрибутов attributeTypes и objectClasses своих подзаписей подсхем конструкции AttributeTypeDescription и ObjectClassDescription из раздела 5.
Серверы могут ограничить поддержку динамических расширений, распространив их только на некоторые поддеревья DIT. Серверы указывают, для каких поддеревьев они поддерживают данные расширения, путём размещения OID поддерживаемых поддеревьев в атрибуте dynamicSubtrees, описанном в разделе 5. Если сервер поддерживает динамические расширения для всех обслуживаемых им контекстов именования, атрибут dynamicSubtrees может отсутствовать.
Предполагается, что динамическая информация изменяется очень часто. Кроме того, ожидается, что запросы Refresh будут поступать на сервер очень часто. Базы данных с хранением информации на жёстком диске, которые часто используются статическими службами каталогов, скорее всего, не подходят для хранения динамической информации. Мы рекомендуем, чтобы реализации сервера хранили динамические записи в оперативной памяти, объёма которой было бы достаточно для того, чтобы избежать подкачки. Это не является обязательным требованием.
Мы ожидаем, что серверы LDAP смогут хранить статические и динамические записи. Если сервер LDAP не поддерживает динамические записи, ему следует вернуть ответ с кодом ошибки, таким как objectClassViolation.
В некоторых случаях клиент может не получить ответа Refresh. Такое может произойти в результате сбоя сервера после получения запроса Refresh, таймаута сокета TCP/IP в случае использования транспорта с установлением соединения, либо потери пакета UDP при использовании транспорта, не предусматривающего установку соединения.
В таком случае рекомендуется, чтобы клиент немедленно выполнил повторную операцию Refresh. Если и на этот запрос Refresh не будет получено ответа, клиенту следует использовать свой первоначальный цикл Refresh, то есть посылать запрос Refresh согласно своего клиентского периода подновления (CRP).
Мы рекомендуем, чтобы реализации сервера позволяли администраторам настраивать значение по умолчанию для клиентского периода подновления (CRP), а также минимальное и максимальное значение CRP. Такие полномочия, совместно с возможностью запроса того, не поменял ли сервер CRP динамически, позволит администраторам задавать значения CRP, обеспечивающие низкий сетевой трафик подновления, или, с другой стороны, каталог с высокой степенью актуальности.
Вопросы репликации только частично рассмотрены в этом документе. IETF работает над отдельной спецификацией по репликации статических и динамических каталогов.
Разрешается реплицировать динамическую запись или статическую запись с динамическими атрибутами. Поскольку entryTtl выражается как относительное время (сколько секунд осталось до истечения срока действия записи), время на выполнение репликации записи должно быть вычтено из этого значения.
Для данной расширенной операции отсутствуют проблемы, связанные с локализацией.
В отношении расширений, описанных в этом документе, применяются стандартные для LDAP правила обеспечения безопасности. Особенных проблем безопасности, специфичных для этих расширений, нет. Однако учтите, что серверы могут разрешать анонимным клиентам подновлять записи, которые были созданы не ими. Серверы также могут контролировать доступ к подновлению записи, требуя от клиентов выполнить подсоединение к каталогу перед отправкой запроса Refresh. Это может повлиять на производительность и масштабируемость сервера.
Также следует проявлять осторожность при использовании полученной из каталога информации, которая была предоставлена клиентом, поскольку она может быть уже неактуальной. Например, во многих сетях IP-адреса автоматически назначаются, когда хост подключается к сети, и они могут быть повторно назначены, когда этот хост позднее отключится. Полученный из каталога IP-адрес может больше не принадлежать тому хосту, который поместил этот адрес в каталог. Эта проблема не относится к LDAP или динамическим каталогам.
Включенные в этот документ проектные концепции основаны на идеях, которые обсуждались в ACID и других рабочих группах IETF.
Yoram Yaacovi
Microsoft, One Microsoft way, Redmond, WA 98052, USA
Телефон: +1 206-936-9629
EMail: yoramy@microsoft.com
Mark Wahl
Innosoft International, Inc., 8911 Capital of Texas Hwy #4140, Austin, TX 78759, USA
Email: M.Wahl@innosoft.com
Tony Genovese
Microsoft, One Microsoft way, Redmond, WA 98052, USA
Телефон: +1 206-703-0852
EMail: tonyg@microsoft.com
[1] Wahl, M., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (Version 3)", RFC 2251, декабрь 1997 г.
[2] Wahl, M. Coulbeck, A., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, декабрь 1997 г.
[3] Wahl, M. и S. Kille, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, декабрь 1997 г.
Copyright (C) Internet Society (1999). Все права защищены.
Этот документ и его переводы могут быть скопированы и переработаны в другие документы. Производные работы, комментирующие или иным способом поясняющие данный документ, либо оказывающие помощь в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, целиком или частями, без каких-либо ограничений, при условии, что указанное выше уведомление об авторском праве и этот параграф будут включены во все такие копии и производные работы. Однако, в этот документ как таковой не может быть внесено каких-либо изменений, таких как удаление уведомления об авторских правах или ссылок на Internet Society или другие организации Интернет, за исключением случаев, когда это требуется для разработки стандартов Интернет (при этом должны быть пройдены процедуры получения авторских прав, определённые в стандартах Интернет), либо когда это требуется при переводе на языки, отличные от английского.
Предоставляемые выше ограниченные права являются бессрочными и не подлежат отзыву Internet Society, его наследниками или правопреемниками.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
Финансирование функций RFC Editor в настоящий момент обеспечивается Internet Society.