учебники, программирование, основы, введение в,

 

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

Протокол LDAP
Основные свойства протокола LDAP:

  • Используется клиент-серверная модель.
  • Может быть сделано несколько запросов за один раз – каждый ответ содержит идентификатор сообщения запроса.
  • В протоколе определено 9 основных операций протокола – запрос информации (2 операции), изменение информации (4 операции), аутентификация и управление (2 операции).
  • LDAPv3 предоставляет расширенные операции и расширенные возможности управления.

Протокол LDAP описывается с использованием ASN.1, используя подмножество BER.
Для обеспечения расширяемости клиенты и серверы должны игнорировать часть последовательности элементов, чьи теги они не распознали.
Клиент указывает версию, которую он использует, как часть запроса Bind. Клиенты могут определить версии протокола, которые поддерживает сервер, по атрибуту supportedLDAPVersion из корневой записи сервера. Серверы, которые реализуют версию 3, должны предоставлять данный атрибут.
Все операции протокола инкапсулированы в общий конверт LDAPMessage, который определяется следующим образом:
LDAPMessage ::= SEQUENCE {
messageID  MessageID,
protocolOp  CHOICE {
bindRequest     BindRequest,
bindResponse    BindResponse,
unbindRequest   UnbindRequest,
searchRequest   SearchRequest,
searchResEntry  SearchResultEntry,
searchResDone   SearchResultDone,
searchResRef    SearchResultReference,
modifyRequest   ModifyRequest,
modifyResponse  ModifyResponse,
addRequest      AddRequest,
addResponse     AddResponse,
delRequest      DelRequest,
delResponse     DelResponse,
modDNRequest    ModifyDNRequest,
modDNResponse   ModifyDNResponse,
compareRequest  CompareRequest,
compareResponse CompareResponse,
abandonRequest  AbandonRequest,
extendedReq     ExtendedRequest,
extendedResp    ExtendedResponse,
... },
controls [0] Controls OPTIONAL
}
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (231 – 1) --
LDAPMessage обеспечивает конверт, содержащий общие поля, необходимые всем обменам протокола. В настоящий момент общими полями являются только messageID и controls.
MessageID из запроса должно иметь ненулевое значение, отличное от значений в любых других запросах для данного соединения LDAP, частью которого является данное сообщение. Обычно клиенты увеличивают значение messageID для каждого запроса.
Ответы сервера содержат значение messageID из соответствующего запроса.
Control представляет собой способ специфицировать информацию расширения для сообщения LDAP. Control только изменяет семантику сообщения, к которому он присоединен.
Controls ::= SEQUENCE OF Control
Control ::= SEQUENCE {
controlType  LDAPOID,
criticality  BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL
}
Поле controlType должно быть представлено в UTF-8 в виде OBJECT IDENTIFIER, который однозначно идентифицирует control. Это предотвращает конфликты между именами control.
Поле criticality является либо TRUE, либо FALSE, и встречается в сообщениях запроса, которые имеют соответствующее сообщение ответа. Для всех других сообщений (например, abandonRequest, unbindRequest и всех сообщений ответа) поле criticality устанавливается в FALSE.
Если сервер распознает тип control, и он соответствует операции, сервер при выполнении операции будет использовать control.
Если сервер не распознает тип control, или он не соответствует операции, и поле criticality есть TRUE, сервер не должен выполнять операцию и вместо этого возвращает resultCode unavailableCriticalExtension.
Если control не распознан или соответствующий бит в поле criticality есть FALSE, сервер должен игнорировать control.
LDAPResult является структурой данных, используемой в протоколе для возвращения от сервера к клиенту индикатора успеха или ошибки. Для различных запросов сервер будет возвращать ответы LDAPResult или ответы, содержащие компоненты LDAPResult для указания заключительного статуса запроса операции протокола.
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success                      (0),
operationsError              (1),
protocolError                (2),
timeLimitExceeded            (3),
sizeLimitExceeded            (4),
compareFalse                 (5),
compareTrue                  (6),
authMethodNotSupported       (7),
strongAuthRequired           (8),
-- 9 зарезервировано --
referral                     (10),
adminLimitExceeded           (11),
unavailableCriticalExtension (12),
confidentialityRequired      (13),
saslBindInProgress           (14),
noSuchAttribute              (16),
undefinedAttributeType       (17),
inappropriateMatching        (18),
constraintViolation          (19),
attributeOrValueExists       (20),
invalidAttributeSyntax       (21),
-- 22-31 не используются --
noSuchObject                 (32),
aliasProblem                 (33),
invalidDNSyntax              (34),
-- 35 зарезервировано для неопределенного --
-- isLeaf --
aliasDereferencingProblem    (36),
-- 37-47 не используются --
inappropriateAuthentication  (48),
invalidCredentials           (49),
insufficientAccessRights     (50),
busy                         (51),
unavailable                  (52),
unwillingToPerform           (53),
loopDetect                   (54),
-- 55-63 не используются --
namingViolation              (64),
objectClassViolation         (65),
notAllowedOnNonLeaf          (66),
notAllowedOnRDN              (67),
entryAlreadyExists           (68),
objectClassModsProhibited    (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs          (71),
-- 72-79 не используются --
other                        (80),
... },
-- 81-90 зарезервировано для APIs --
matchedDN LDAPDN,
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL
}
Коды результата являются расширяемыми.

Операции протокола LDAP

В протоколе определено 9 операций:

  1. Операции запроса информации.
    • Search
    • Compare
  2. Операции изменения информации.
    • Add
    • Delete
    • Modify
    • Rename
  3. Операции аутентификации и управления.
    • Bind
    • Unbind
    • Abandon
Типичные переговоры LDAP операции Bind

Операция Bind передает аутентификационную информацию от клиента к серверу.
Запрос Bind определен следующим образом:

BindRequest ::= [APPLICATION 0] SEQUENCE {
    version        INTEGER (1 .. 127), 
    name           LDAPDN, 
    authentication AuthenticationChoice 
} 
AuthenticationChoice ::= CHOICE { 
    simple [0] OCTET STRING, 
-- 1 и 2 зарезервированы  
    sasl [3] SaslCredentials, 
... } 
SaslCredentials ::= SEQUENCE { 
    mechanism   LDAPString, 
    credentials OCTET STRING OPTIONAL 
} 

Параметрами запроса Bind являются:

  • Version: номер версии, указывает используемую версию протокола. В настоящий момент максимальная версия протокола равна 3. Заметим, что переговоров о номере версии не ведется, клиент просто посылает данный параметр. Если сервер не поддерживает указанную версию, он отвечает protocolError в поле resultCode в BindResponce.
  • Name: имя объекта директории, к которой клиент хочет присоединиться. Данное поле может иметь нулевое значение (строку нулевой длины) для анонимного связывания или когда используется SASL аутентификация.
  • Authentication: информация, используемая для аутентификации имени, указанного в запросе Bind. Серверы, которые не поддерживают выбор, предлагаемый клиентом, будут возвращать authMethodNotSupported в коде результата для запроса Bind. Аутентификацию с использованием механизмов SASL мы рассматривать не будем, так как эти способы аутентификации в инфраструктуре открытого ключа при доступе к репозиторию LDAP сейчас не используются.

Ответ Bind определяется следующим образом.

BindResponse ::= [APPLICATION 1] SEQUENCE { 
    COMPONENTS OF LDAPResult, 
    serverSaslCreds [7] OCTET STRING OPTIONAL 
} 

BindResponce состоит из индикации от сервера статуса запроса клиента на аутентификацию.
Если связывание прошло успешно, то resultCode будет success, в противном случае он должен содержать OperationError или другую индикацию неудачной аутентификации. Если сервер не поддерживает требуемую клиенту версию протокола, он должен установить resultCode в protocolError.

Операция Unbind

Функция операции Unbind состоит в завершении сессии протокола. Операция Unbind определяется следующим образом:

UnbindRequest ::= [APPLICATION 2] NULL 

Операция Unbind не имеет ответа. После передачи UnbindRequest клиент должен предполагать, что сессия протокола завершена. После получения UnbindRequest сервер должен предполагать, что клиент завершил сессию и все выходящие запросы им сброшены, и должен закрыть соединение.

Операция Search

Операция Search позволяет клиенту запрашивать выполнение поиска на сервере. Это может использоваться для чтения атрибутов из единственной записи, из записей, непосредственно следующих за конкретной записью, или из целого поддерева записей.
SearchRequest определяется следующим образом:

SearchRequest ::= [APPLICATION 3] SEQUENCE {
  baseObject  LDAPDN, 
  scope  ENUMERATED { 
    baseObject   (0), 
    singleLevel  (1), 
    wholeSubtree (2) }, 
  derefAliases     ENUMERATED { 
    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 
} 

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

  • BaseObject: LDAPDN, являющееся записью базового объекта, относительно которого будет выполняться поиск.
  • Scope: индикатор области выполняемого поиска.

Может существовать три типа области поиска:

    • baseObject: ограничивается только базовым объектом.
    • singleLevel: ограничивается только непосредственно подчиненными объектами.
    • wholeSubtree: поиск во всем поддереве данной записи.
  • DerefAliases: индикатор того, как alias объектов обрабатываются при поиске. Семантика возможных значений данного поля следующая:
    • 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: список атрибутов, возвращаемый для каждой записи, которая соответствует фильтру поиска. Могут использоваться два специальных значения: пустой список без атрибутов и атрибут, описываемый строкой «*». Оба значения говорят о том, что возвращаются все атрибуты пользователя.

Атрибуты должны быть поименованы самое большее один раз в списке и возвращаться самое большее один раз в записи. Если в списке существуют описания атрибутов, которые не распознаны, они игнорируются сервером.
Если клиент не хочет, чтобы возвращались какие-либо атрибуты, он может указать список, содержащий только атрибут с OID «1.1». Этот OID был выбран произвольно и не соответствует никакому используемому атрибуту.
Следует заметить, что если запрошены все атрибуты пользователя, некоторые атрибуты записи могут не включаться в результаты поиска в соответствии с политикой управления доступом или другими ограничениями. Более того, серверы не будут возвращать атрибуты выполнения, такие как objectClasses или attributeTypes, если они явно не перечислены, т.к. эти атрибуты могут иметь большое число значений.
Результаты поиска вычисляются сервером после получения им SearchRequest и возвращаются в SearchResponses, которые являются сообщениями LDAP, содержащими типы данных SearchResultEntry, либо SearchResultReference, либо SearchResultDone.

SearchResultEntry ::= [APPLICATION 4] 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 

После получения SearchRequest сервер будет выполнять необходимый поиск в DIT.
Сервер может возвращать как найденные записи (SearchResultEntry), так и ссылки на другие серверы для продолжения поиска (SearchResultReference).
Для завершения поиска клиент может создать новую операцию поиска для каждого полученного SearchResultReference.
Например, предположим, что сервер (hosta), с которым соединяются, имеет запись DC=Example, DC=NET и запись CN=Manager, DC=Example, DC=NET. Он знает, что один из LDAP-серверов, hostb или hostc, имеет поддерево OU=People, DC=Example, DC=NET и что LDAP-сервер hostd имеет поддерево OU=Roles, DC=Example, DC=NET. Если сделан запрос поиска по поддереву DC=Example, DC=NET, он может возвратить следующее:

SearchResultEntry for DC=Example,DC=NET 
SearchResultEntry for CN=Manager,DC=Example,
                      DC=NET 
SearchResultReference { 
    ldap://hostb/OU=People,DC=Example,DC=NET
    ldap://hostc/OU=People,DC=Example,DC=NET
} 
SearchResultReference { 
    Lightweight Directory Access Protocol 
       Version 3 
    ldap://hostd/OU=Roles,DC=Example,DC=NET 
} 
SearchResultDone (success)

В качестве продолжения примера, если клиент соединяется с сервером hostb и создает запрос для поддерева «OU=People, DC=Example, DC=NET», сервер может вернуть следующее:

SearchResultEntry for OU=People,DC=Example,DC=NET 
SearchResultReference { 
    ldap://hoste/OU=Managers,OU=People,
    DC=Example,DC=NET 
} 
SearchResultReference { 
    ldap://hostf/OU=Consultants,OU=People,
    DC=Example,DC=NET 
} 
SearchResultDone (success) 

Если сервер, с которым установлено соединение, не имеет базового объекта для поиска, то он возвращает клиенту ссылку (referral). Например, если клиент запросил у hosta поиск поддерева DC=Example, DC=ORG, сервер может вернуть только SearchResultDone, содержащий referral.

SearchResultDone (referral) { 
    ldap://hostg/DC=Example,DC=ORG??sub

}

Операция Modify

Операция Modify позволяет клиенту запросить модификацию записи на сервере. Запрос Modify определяется следующим образом:

ModifyRequest ::= [APPLICATION 6] SEQUENCE {
  object       LDAPDN, 
  modification SEQUENCE OF SEQUENCE { 
    operation ENUMERATED { 
      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: замена всех существующих значений данного атрибута новыми перечисленными значениями; если атрибута не существует, он создается. Замена без указания значения удаляет весь атрибут, если он есть, и игнорируется, если атрибута не существует.

Результат модификации, которую пытался выполнить сервер при получении ModifyRequest, возвращается в ModifyResponse, который определяется следующим образом:

ModifyResponse ::= [APPLICATION 7] LDAPResult 

При получении ModifyRequest сервер выполняет необходимые модификации в DIT.
Сервер возвращает клиенту единственный ModifyResponse, указывающий либо на успешное завершение модификации DIT, либо на причину неудачного завершения. Заметим, что при требовании атомарности применения списка модификаций в ModifyRequest клиент может считать, что ни одна модификация DIT не выполнена, если полученный ModifyResponse указывает на какую-либо ошибку, и что все запрошенные модификации прошли удачно, если ModifyResponse указывает на успешное завершение операции модификации.
Операция Modify не может быть использована для удаления из записи любого полного уникального имени и тех значений, которые формируют относительное уникальное имя записи. Попытка сделать это приведет к тому, что сервер вернет ошибку notAllowedOnRDN. Для переименования записи используется операция ModifyDN, которая будет описана ниже.

Операция Add

Операция Add позволяет клиенту запросить добавление записи в Каталог. AddRequest определяется следующим образом:

AddRequest ::= [APPLICATION 8] SEQUENCE {
    entry      LDAPDN, 
    attributes AttributeList 
} 
AttributeList ::= SEQUENCE OF SEQUENCE { 
    type AttributeDescription, 
    vals SET OF AttributeValue 
} 

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

  • Entry: полное уникальное имя добавляемой записи. Заметим, что сервер не определяет никаких aliases при размещении добавляемой записи.
  • Attributes: список атрибутов, которые определяют содержание добавляемой записи. Клиенты должны включать в этот список полные значения (которые формируют собственный RDN записи), атрибут objectClass и значения всех обязательных атрибутов перечисленных классов объектов. Клиенты не должны указывать NO-USER-MODIFICATION атрибуты, такие как createTimestamp или creatorName атрибуты, так как сервер поддерживает их автоматически.

Запись, указанная в поле AddRequest, существовать не должна. Непосредственный родитель добавляемых записей объекта должен существовать. Например, если клиент пытается добавить CN=JS, DC=Example, DC=NET, а запись DC=Example, DC=NET не существует и запись DC=NET существует, то сервер вернет ошибку noSuchObject с полем matchedDN, содержащим DC=NET. Если родительская запись существует, но не находится в контексте именования, поддерживаемом сервером, сервер должен возвратить ссылку на сервер, содержащий родительскую запись.
При получении AddRequest сервер пытается добавить запрошенную запись. Результат попытки добавления будет возвращен клиенту в AddResponse, определенном следующим образом:

AddResponse ::= [APPLICATION 9] LDAPResult 

Успешный ответ указывает на то, что новая запись добавлена в Каталог.

Операция Delete

Операция Delete позволяет клиенту запросить удаление записи из директории. DeleteRequest определяется следующим образом:

DelRequest ::= [APPLICATION 10] LDAPDN 

DeleteRequest состоит из Distinguished Name удаляемой записи. Заметим, что сервер по aliases не переходит и что только концевые записи (которые не имеют подчиненных записей) могут быть удалены с помощью данной операции.
Результат операции удаления, выполненной сервером при получении DeleteRequest, возвращается в DeleteResponse, определяемом следующим образом:

DelResponse ::= [APPLICATION 11] LDAPResult 

При получении DeleteRequest сервер пытается выполнить удаление указанной записи. Результат возвращается клиенту в DeleteResponse.

Операция 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.

 

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика