Кратко

  • User Friendly Name в RFC 1484 был purported name — предполагаемым именем для поиска, где разрешалось опускать типы и уровни, а не сохранённым Distinguished Name.
  • Результат зависел от порядка локального окружения, схемы, текущих записей, альтернативных значений, правил сопоставления и иногда выбора пользователя.
  • Выбранный DN однозначно называл запись дерева, но сам не удостоверял человека, его полномочия, актуальность атрибутов или последующий результат.

Путь достраивала машина

RFC 1484 пытался снять с человека формальность X.500. Имя, услышанное на встрече, можно было набрать как обычное описание, не раскладывая его по полям Common Name, Organisation, Organisational Unit и Country.

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

Но документ называл ввод purported name. Строка была предположением, которое следовало разрешить в один или несколько DN. Удобство не уничтожило административную структуру. Оно передало её восстановление клиенту и каталогу.

Пустые места заполнялись разными способами

Типы можно было вывести из схемы по умолчанию: нижний компонент считать Common Name, верхний — Country, промежуточные — организацией и подразделениями. Контекстные и зависящие от данных схемы допускали другие выводы.

Когда правила не хватало, начинался поиск. Короткий компонент мог совпасть с местностью, организацией или альтернативным атрибутом. Ошибка могла пройти как approximate match, а аббревиатура — как точное альтернативное значение.

Следовательно, исходная строка не содержит полного основания результата. Для воспроизведения нужны язык, версия клиента и парсера, схема, базы, фильтры, состояние каталога и набор кандидатов.

RFC 1484 советовал почти всегда хранить найденный DN. Новый зарегистрированный тёзка мог сделать вчерашнее однозначное имя неоднозначным. Изменялся не ввод, а множество, относительно которого его понимали.

Локальное окружение задавало географию поиска

Каждое сопоставление происходило в environment — упорядоченном списке нелистовых DN дерева. Список менялся в зависимости от числа компонентов и должен был контролироваться пользователем.

В примере университетского клиента одно слово сначала искали внутри кафедры, затем университета, страны и корня. Для двух компонентов порядок был иным. Публичный клиент в США имел собственную последовательность.

Порядок влиял на ответ. Раннее точное совпадение могло остановить дальнейший поиск. Локально привычная аббревиатура получала преимущество, тогда как внешний клиент показывал несколько организаций. Одинаковые символы запускали разные программы.

Environment нужно считать входом решения и сохранять вместе с результатом. Без него нельзя объяснить, какие ветви даже не рассматривались.

Exact, good и poor управляли ветвлением

Алгоритм делил совпадения на exact, good и poor. Точное всегда продолжали. Хорошие следовали при отсутствии точного. Плохие, полученные приблизительным или подстрочным поиском, отдавали пользователю на выбор. Отказ от всех кандидатов мог перевести поиск к следующему элементу окружения.

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

Позднейший RFC 4511 описывает поиск LDAP через base, scope, режим aliases, ограничения размера и времени, filter и список атрибутов. До финального результата могут прийти записи и continuation references. Одна карточка на экране не доказывает полноту.

У слова «имя» было три разных объекта

RFC 1309 показывает основу X.500: запись занимает место в Directory Information Tree, а DN складывается из RDN пути от корня. Уже опубликованная статья о RFC 1309 сохраняет тему DUA/DSA, chaining, referrals, aliases и реплик. RFC 1484 разбирал другое — догадку человека о пути.

RFC 1485 задавал строковую запись уже известного DN. Затем её сменили RFC 1779, RFC 2253 и RFC 4514. Сериализация известного имени не равна поиску по неполному.

RFC 4514 не определяет единственную каноническую строку. Равенство DN устанавливает distinguishedNameMatch, а не побайтовое сравнение. Разное отображение может обозначать равные DN; похожий текст может не пройти правило.

RFC 4512 связывает типы атрибутов с синтаксисом и matching rules, требует уникальности RDN среди соседей и говорит, что DN однозначно ссылается на запись. RFC 4518 готовит международные строки к сопоставлению. Глиф, кодировка, подготовленное значение и ссылка на запись — не один факт.

Запись каталога не предъявляла паспорт

Запись представляет объект и содержит названный набор сведений. Однозначная ссылка DN не доказывает, что человек у терминала и есть этот объект, что он управляет записью или что должность действительна.

Контроль доступа может скрывать атрибуты, referral может остаться не пройден, реплика — отставать, пользователь — выбрать тёзку. Приложение всё ещё обязано отдельно аутентифицировать, авторизовать, зафиксировать версию сведений и проверить эффект.

Найденный адрес не является квитанцией доставки. Найденная учётная запись не даёт права. Exact match не устанавливает юридическую личность.

Опыт прототипа не скрывал проблемы

RFC 1484 сообщил о реализации в FRED проекта PSI Pilot и прототипе управления списками рассылки; реакция пользователей была благоприятной. Это первичное свидетельство работающего кода, не перепись внедрений.

Алгоритм плохо работал при нескольких уровнях подразделений, если пользователь пропускал не непосредственный уровень. Начальные wildcard могли быть неэффективны. Неоднозначность, полезность, производительность и варианты требовали дальнейших опытов.

Запись RFC Editor подтверждает документный статус. RFC был Experimental, а раздел безопасности прямо не обсуждал безопасность. Нельзя приписывать ему приватность, защиту от перечисления или гарантию личности.

Удобство оставалось первым шагом

Идеи Heng Lu о приоритете работающего кода, минимальной общей спецификации и локальном будущем решении и слоях реальности удерживают границы. Общей была форма. Окружение принадлежало клиенту, данные — каталогу, неоднозначный выбор — человеку, действие — приложению.

Полная история связывает произнесённое имя, purported name, environment, запрос, кандидатов, выбор, DN, версию записи, аутентификацию, авторизацию и результат. RFC 1484 улучшил человеческий вход в эту цепочку, но не заменил цепочку строкой.

Источники