Инфраструктура Открытого Ключа (часть 3)

Операция ModifyDN

Операция ModifyDN позволяет клиенту изменить левый компонент имени записи в Каталоге и/или переместить поддерево записей на новое место в Каталоге. ModifyDNRequest определяется следующим образом:

ModifyDNRequest ::= [APPLICATION 12] SEQUENCE
{
    entry        LDAPDN, 
    newrdn       RelativeLDAPDN, 
    deleteoldrdn BOOLEAN, 
    newSuperior  [0] LDAPDN OPTIONAL
}

Параметрами ModifyDNRequest являются:

• Entry: DN изменяемой записи. Эта запись может как иметь подчиненные записи, так и не иметь их. Заметим, что сервер не переходит ни по каким aliases для изменяемой записи.
• Newdn: RDN, который формирует левый компонент нового имени записи.
• Deleteoldrdn: Boolean параметр, который указывает, должно ли старое значение атрибута RDN оставаться в качестве атрибута записи или оно должно удаляться из записи.
• newSuperior: если присутствует, то это DN существующего объекта, который становится непосредственным родителем существующей записи.

Результат попытки изменения имени сервером при получении ModifyDNRequest возвращается в ModifyDNResponse, определенном следующим образом:

ModifyDNResponse ::= [APPLICATION 13] 
    LDAPResult

Например, если запись, указанная в параметре entry, была cn=Olga Laponina, 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 позволяет клиенту сравнить утверждение с записью в Каталоге. CompareRequest определяется следующим образом:

CompareRequest ::= [APPLICATION 14] SEQUENCE
{ 
  entry LDAPDN, 
  ava   AttributeValueAssertion 
}

Перечислим параметры CompareRequest:

• Entry: имя сравниваемой записи. Заметим, что сервер не должен рассматривать aliases записи при выполнении сравнения.
• Ava: утверждение, с которым сравнивается атрибут записи.

Результат сравнения, выполненного сервером при получении CompareRequest, возвращается в CompareResponse, определяемом следующим образом:

CompareResponse ::= [APPLICATION 15] LDAPResult

При получении CompareRequest сервер пытается выполнить запрошенное сравнение, используя правило соответствия EQUALITY для типа атрибута. Результат сравнения возвращается клиенту в CompareResponse. Заметим, что как ошибки, так и результат сравнения возвращаются в одной и той же конструкции.

Заметим, что с помощью некоторых систем Каталога можно организовать управление доступом так, чтобы значения некоторых атрибутов (таких как userPassword ) сравнивались или запрашивались другими способами.

Операция Abandon

Операция Abandon обеспечивает клиенту возможность создания запроса на прерывание сервером выполняющейся операции. AbandonRequest определяется следующим образом:

AbandonRequest ::= [APPLICATION 16] MessageID

MessageID должен быть тот же, что был в операции, запрошенной ранее для данного LDAP-соединения. Сам запрос Abandon не имеет собственного MessageID. Он должен отличаться от id более ранней операции, для которой выполнен Abandon .

Для операции Abandon ответ не определен. При передаче операции Abandon сервер может прервать операцию, идентифицированную MessageID в AbandonRequest. Ответы операции при успешном прерывании операции не посылаются. Клиенты могут определить, что операция прервана, выполняя последующую операцию Bind .

Операции Abandon и Unbind не могут быть прерваны. Возможность прервать другие операции (в частности, update ) определяется сервером.

В том случае, если сервер получил AbandonRequest для операции Search в середине передаваемых ответов на поиск, сервер должен немедленно прекратить передачу ответов и не должен посылать SearchResponseDone. Конечно сервер должен гарантировать, что передаются только корректные блоки данных LDAPMessage.

Клиенты не должны несколько раз посылать запросы Abandon для одной и той же операции, но должны обрабатывать полученные результаты прерванных операций (так как они могли быть уже переданы после получения Abandon и не могли быть прерваны).

Серверы сбрасывают запросы Abandon для тех messageIDs, которые они не распознали, для операций, которые не могут быть прерваны, и для операций, которые уже прерваны.

Расширенные операции

В данную версию LDAP добавлен расширенный механизм, позволяющий определять дополнительные операции для сервисов, которые ранее не были доступны в данном протоколе, например для операций цифровой подписи.

Расширенная операция позволяет клиенту делать запросы и получать ответы с предопределенными синтаксисом и семантикой. Каждый запрос должен иметь уникальный OBJECT IDENTIFIER.

ExtendedRequest ::= [APPLICATION 23] SEQUENCE
{ 
  requestName  [0] LDAPOID, 
  requestValue [1] OCTET STRING OPTIONAL 
}

requestName есть разделенное точками представление OBJECT IDENTIFIER, соответствующего запросу. requestValue есть информация в форме, определенной данным запросом, инкапсулированная в OCTET STRING.

Сервер отвечает LDAPMessage, содержащим ExtendedResponse.

ExtendedResponse ::= [APPLICATION 24] SEQUENCE
{ 
    COMPONENTS OF LDAPResult, 
    responseName [10] LDAPOID OPTIONAL, 
    response     [11] OCTET STRING OPTIONAL 
}

Если сервер не распознал имя запроса, он должен вернуть только поля ответа из LDAPResult, содержащие код ошибки protocolError.