Протокол LDAP
Операции протокола LDAP
В протоколе определено 9 операций:
- Операции запроса информации.
- Search
- Compare
- Операции изменения информации.
- Add
- Delete
- Modify
- Rename
- Операции аутентификации и управления.
- Bind
- Unbind
- Abandon
Операция Bind
Операция Bind передает аутентификационную информацию от клиента к серверу.
Параметрами запроса Bind являются:
- Version: номер версии, указывает используемую версию протокола. В настоящий момент максимальная версия протокола равна 3. Заметим, что переговоры о номере версии не ведутся, клиент просто посылает данный параметр. Если сервер не поддерживает указанную версию, он отвечает protocolError в поле resultCode в сообщении BindResponce.
- Name: имя объекта Каталога, от имени которого клиент хочет установить соединение. Данное поле может иметь нулевое значение (строку нулевой длины) для анонимного соединения или при использовании SASL-аутентификации.
- Authentication: информация, используемая для аутентификации имени, указанного в запросе Bind. Серверы, которые не поддерживают выбор, предлагаемый клиентом, будут возвращать authMethodNotSupported в коде результата для запроса Bind. Аутентификацию с использованием механизмов SASL мы рассматривать не будем.
Ответ Bind определяется следующим образом.
BindResponce содержит статус запроса клиента на аутентификацию.
Если доступ разрешен, то resultCode будет Success, в противном случае он должен содержать OperationError или другую индикацию неудачной аутентификации. Если сервер не поддерживает требуемую клиенту версию протокола, он должен установить resultCode в protocolError.
Операция Unbind
Назначение операции Unbind состоит в завершении сессии протокола.
Операция Unbind не имеет ответа. После передачи UnbindRequest клиент должен предполагать, что сессия протокола завершена. После получения UnbindRequest сервер должен предполагать, что клиент завершил сессию, и все исходящие ответы сервер сбрасывает и закрывает соединение.
Операция Search
Операция Search позволяет клиенту запрашивать выполнение поиска на сервере. Это может использоваться для чтения атрибутов из единственной записи, из записей, непосредственно следующих за конкретной записью, или из целого поддерева записей.
Сообщение Search Request имеет следующие параметры:
baseObject - LDAPDN,
scope
baseObject (0),
singleLevel (1),
wholeSubtree (2) ,
derefAliases
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF Filter,
or [1] SET SIZE (1..MAX) OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion
}
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- по крайней мере один должен присутствовать,
-- initial и final могут быть указаны только один раз
substrings SEQUENCE OF CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue }
}
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE
}
Перечислим параметры Search Request:
- BaseObject: базовый объект, относительно которого будет выполняться поиск.
-
Scope: указание области поиска.
Может существовать три типа области поиска:
- baseObject - ограничивается только базовым объектом.
- singleLevel - ограничивается только непосредственно подчиненными объектами.
- wholeSubtree - поиск во всем поддереве данной записи.
-
DerefAliases: указание того, как выполняется поиск объекта. Семантика возможных значений данного поля следующая:
- NeverDerefAliases: не выполняются переходы по ссылкам для aliases при поиске или при размещении базового объекта поиска.
- DerefInSearching: выполняется переход по ссылкам aliases, подчиненных базовому объекту поиска.
- DerefFindingBaseObj: выполняется переход по ссылкам aliases, размещенных в базовом объекте по-иска, но не в подчиненных базовому объекту.
- DerefAlways: выполняется переход по ссылкам aliases как при поиске, так и при размещении базового объекта поиска.
- SizeLimit: ограничение максимального количества записей, возвращаемых в качестве результата поиска. Значение 0 в данном поле указывает, что при поиске нет ограничения. Сервер сам определяет максимальное количество возвращаемых записей.
- TimeLimit: ограничение, определяющее максимальное время поиска (в секундах). Значение 0 в данном поле указывает, что ограничений по времени при запросах клиента не существует.
- TypesOnly: индикатор того, что результаты поиска содержат и типы, и значения атрибутов или только типы атрибутов. При установке данного значения в TRUE будут возвращаться только типы атрибутов. При установке данного значения в FALSE будут возвращаться и типы, и значения атрибутов.
-
Filter: фильтр определяет условия, которые должны быть выполнены. and, or и not используются для комбинирования фильтров. По крайней мере один элемент фильтра должен присутствовать.
Сервер должен вычислить фильтры. Результатом вычисления фильтра должно быть либо "TRUE", либо "FALSE", либо "Undefined". Если фильтр вычисляет TRUE для конкретной записи, то атрибуты данной записи возвращаются как часть результата поиска. Если фильтр вычисляет FALSE или Undefined, то данная запись при поиске игнорируется.
Правило соответствия для элемента фильтра equalityMatch определяется правилом соответствия EQUALITY для типа атрибута.
Правило соответствия для AssertionValues фильтра определяется правилом соответствия SUBSTR для типа атрибута.
Правило соответствия для элементов фильтра greaterOrEqual и lessOrEqual определяется правилом соответствия ORDERING для типа атрибута.
Семантика соответствия для элементов фильтра approxMatch определяется реализацией.
- Attributes: список атрибутов, возвращаемый для каждой записи, которая соответствует фильтру поиска. Могут использоваться два специальных значения: пустой список без атрибутов и атрибут, описываемый строкой "*". Оба значения говорят о том, что возвращаются все пользовательские атрибуты.
Следует заметить, что если запрошены все пользовательские атрибуты, некоторые атрибуты записи могут не включаться в результаты поиска в соответствии с политикой управления доступом или другими ограничениями. Более того, серверы не будут возвращать атрибуты выполнения, такие как objectClasses или attributeTypes, если они явно не перечислены.
Результаты поиска вычисляются сервером после получения им SearchRequest и возвращаются в Search Responses, которые являются LDAP-сообщениями, содержащими типы данных SearchResultEntry, либо SearchResultReference, либо SearchResultDone.
SearchResultEntry::= SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList
}
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue
}
-- следуетзаметить, что PartialAttributeList может
-- иметь ноль элементов (если ни один из атрибутов затре-бованной записи
-- не может быть возвращен) и что множество vals
-- может также иметь ноль элементов (если запрошены только типы или
-- все значения были исключены из результата)
SearchResultReference::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- по крайней мере один элемент LDAPURL должен присут-ствовать
SearchResultDone ::= [APPLICATION 5] LDAPResult
После получения Search Request сервер будет выполнять необходимый поиск в DIT.
Сервер может возвращать как найденные записи (SearchResultEntry), так и ссылки на другие серверы для продолжения поиска (SearchResultReference).
Для завершения поиска клиент может создать новую операцию поиска для каждого полученного SearchResultReference.
Операция Modify
Операция Modify позволяет клиенту запросить модификацию записи на сервере. Запрос Modify имеет следующие параметры:
object LDAPDN,
modification
operation
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue
}
Перечислимпараметрызапроса Modify:
- Object: модифицируемый объект. Значение данного поля содержит DN модифицируемой записи. Сервер не использует никаких alias для определения модифицируемой записи.
-
Modification: список выполняемых изменений. Список из-менений должен быть выполнен в том порядке, в котором он перечислен, как одна атомарная операция. Хотя отдельные из-менения могут нарушать схему Каталога, результирующая запись, после того как весь список изменений выполнен, должна соответствовать требованиям схемы Каталога. Значения поля operation имеют следующую семантику:
- Add: добавление перечисленных значений для данного атрибута; при необходимости атрибут создается.
- Delete: удаление перечисленных значений для данного атрибута; весь атрибут удаляется, если никаких значений не указано или если удалены все текущие значения атрибута.
- Replace: замена значений данного атрибута новыми; если атрибута не существует, он создается. Если при замене не указаны новые значения, то атрибут удаляется, если он есть, и игнорируется, если атрибута не существует.
Результат изменения, которое пытался выполнить сервер при получении Modify Request, возвращается в Modify Response.
При получении Modify Request сервер выполняет необходимые изменения в DIT.
Сервер возвращает клиенту единственный Modify Response, указывающий либо на успешное завершение изменения DIT, либо на причину неудачного завершения. Заметим, что в силу требования атомарности применения списка изменений в Modify Request, клиент может считать, что ни одно изменение DIT не выполнено, если полученный Modify Response указывает на какую-либо ошибку, и что все запрошенные изменения про-шли успешно, если Modify Response указывает на успешное завершение операции изменения.
Операция Modify не может быть использована для удаления из записи любого полного уникального имени и тех значений, которые формируют относительное уникальное имя записи. Попытка сделать это приведет к тому, что сервер вернет ошибку notAllowedOnRDN. Для переименования записи используется операция Modify DN, которая будет описана ниже.
Операция Add
Операция Add позволяет клиенту запросить добавление записи в Каталог. Add Request имеет следующие параметры:
entry LDAPDN,
attributes AttributeList
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue
Параметрами Add Request являются:
- Entry: полное уникальное имя добавляемой записи. Заметим, что сервер не определяет никаких aliases при размещении добавляемой записи.
- Attributes: список атрибутов, которые определяют содержание добавляемой записи. Клиенты должны включать в этот список полные значения (которые формируют RDN записи), атрибут objectClass и значения всех обязательных атрибутов классов объектов данной записи. Клиенты не должны указывать атрибуты, которые не могут модифицироваться пользователем, такие как createTimestamp или creatorName атрибуты, так как сервер создает их автоматически.
Запись, указанная в поле entry в AddRequest, существовать не должна. Непосредственный родитель добавляемых записей объекта должен существовать. Например, если клиент пытается добавить CN=JS, DC=Example,DC=NET, но запись DC=Example, DC=NET не существует, а запись DC=NET существует, то сервер вернет ошибку noSuchObject с полем matchedDN, содержащим DC=NET. Если родительская запись существует, но не находится в контексте именования, поддерживаемом сервером, сервер должен возвратить ссылку на сервер, содержащий родительскую запись.
Операция Delete
Операция Delete позволяет клиенту запросить удаление записи из Каталога.
Сообщение Delete Request состоит из DN удаляемой записи. Заметим, что сервер не переходит по aliases, и что только концевые записи (которые не имеют подчиненных записей) могут быть удалены с помощью данной операции.
Результат операции удаления, выполненной сервером при получении сообщения Delete Request, возвращается в сообщении Delete Response.
Операция Modify DN
Операция Modify DN позволяет клиенту изменить левый компонент имени записи в Каталоге и/или переместить поддерево записей на новое место в Каталоге. Сообщение Modify DN Request имеет следующие параметры:
entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN, newSuperior [0] LDAPDNOPTIONAL
Параметрами Modify DN Request являются:
- Entry: DN изменяемой записи. Эта запись может как иметь подчиненные записи, так и не иметь их. Заметим, что сервер не переходит ни по каким aliases для изменяемой записи.
- Newdn: RDN определяет левый компонент нового имени записи.
- Deleteoldrdn: Параметр типа boolean, который указывает, должно ли старое значение атрибута RDN оставаться в качестве атрибута записи или оно должно удаляться из записи.
- newSuperior: если присутствует, то это DN существующего объекта, который становится непосредственным родителем существующей записи.
Результат попытки изменения имени сервером при получении сообщения Modify DN Request возвращается в сообщении Modify DN Response.
Например, если запись, указанная в параметре entry, была cn=OlgaLaponina, c=RU, newdn параметр был cn=Olga R. Laponina и newSuperior параметр отсутствовал, то эта операция пытается переименовать запись, чтобы она имела вид cn= Olga R. Laponina, c=RU. Если запись с таким именем уже существует, то операция завершится с кодом ошибки entryAlreadyExists.
Объект, указанный в newSuperior, должен существовать. Например, если клиент пытается добавить CN=JS, DC=EXAMPLE, DC=NET, запись DC=EXAMPLE, DC=NET не существует, запись DC=NET существует, то сервер возвратит ошибку noSuchObject с полем matchedDN, содержащим DC=NET.
Если параметр deleteoldrdn есть TRUE, то значения, формирующие старый RDN, удаляются из записи. Если параметр deleteoldrdn есть FALSE, то значения, формирующие старый RDN, остаются как значения неуникального атрибута записи. Сервер может не выполнить операцию и вернуть код ошибки, если установка параметра deleteoldrdn противоречит Схеме.
Операция Compare
Операция Compare позволяет клиенту сравнить утверждение с записью в Каталоге. Compare Request имеет следующие параметры:
entry LDAPDN, ava AttributeValueAssertion
Перечислим параметры CompareRequest:
- Entry: имя сравниваемой записи. Заметим, что сервер не должен рассматривать aliases записи при выполнении сравнения.
- Ava: утверждение, с которым сравнивается атрибут записи.
Результат сравнения, выполненного сервером при получении Compare Request, возвращается в Compare Response.
При получении Compare Request сервер пытается выполнить запрошенное сравнение, используя правило соответствия EQUALITY для типа атрибута. Заметим, что как ошибки, так и результат сравнения возвращаются в одной и той же конструкции.
Заметим, что управление доступом может быть организовано таким образом, чтобы значения некоторых атрибутов (таких как userPassword) сравнивались или запрашивались другими способами.
Операция Abandon
Операция Abandon предоставляет возможность создания запроса на прерывание сервером выполняющейся операции.
MessageID должен быть тот же, что был в операции, запрошенной ранее для данного LDAP-соединения. Сам запрос Abandon не имеет собственного MessageID. Он должен отличаться от идентификатора более ранней операции, для которой был выполнен Abandon.
Для операции Abandon ответ не определен. При передаче операции Abandon сервер может прервать операцию, идентифицированную MessageID в Abandon Request. Ответы операции при успешном прерывании операции не посылаются. Клиенты могут определить, что операция прервана, выполнив новую операцию bind.
Операции Abandon и Unbind не могут быть прерваны. Возможность прервать другие операции (в частности, модификации) определяется сервером.
В том случае, если сервер получил Abandon Request для операции Search в середине передаваемых ответов на поиск, сервер должен немедленно прекратить передачу ответов и не должен посылать SearchResponseDone. Конечно сервер должен гарантировать, что передаются только корректные блоки данных LDAPMessage.
Клиенты не должны несколько раз посылать запросы Abandon для одной и той же операции, но должны обрабатывать полученные результаты прерванных операций (так как они могли быть уже переданы после полу-чения Abandon и не могли быть прерваны).
Серверы сбрасывают запросы Abandon для тех MessageID, которые они не распознали, для операций, которые не могут быть прерваны, и для операций, которые уже прерваны.
Дополнительные операции
В версию 3 LDAP добавлен расширенный механизм, позволяющий определять дополнительные операции для сервисов, которые ранее не были доступны в протоколе LDAP, например для операций цифровой подписи.
Расширенная операция позволяет клиенту делать запросы и получать ответы с предопределенными синтаксисом и семантикой. Каждый запрос должен иметь уникальный OBJECT IDENTIFIER.
requestName LDAPOID, requestValue OCTET STRING OPTIONAL
requestName есть OBJECT IDENTIFIER операции requestValue содержит информацию в том виде, в котором она определена в операции. Данная информация инкапсулирована в строку октетов.
Сервер отвечает LDAPMessage, содержащим ExtendedResponse.
COMPONENTS OF LDAPResult, ResponseName LDAPOID OPTIONAL, Response OCTET STRING OPTIONAL
Если сервер не распознал имя запроса, он должен вернуть только поля ответа из LDAPResult, содержащие код ошибки protocolError.