Принцип единого входа (Single sign-on)

7.3.1 Аутентификация

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

Сейчас мы опишем последовательность аутентификации, которая выполняется с применением для аутентификации по протоколу SASL сертификатов X.509v3. Во время протокольного обмена в рамках аутентификации механизм SASL выполняет аутентификацию, передавая личность авторизации [известную как идентификатор пользователя (userid)] от клиента к серверу и договариваясь об использовании определенного механизмом уровня безопасности.

Когда сервер LDAP получает от клиента запрос связывания LDAP, он обрабатывает запрос следующим образом:

1. Сервер анализирует запрос связывания LDAP и осуществляет выборку из него следующей информации:
   • отличительное имя (DN), с применением которого клиент предпринимает попытку пройти аутентификацию;
   • используемый метод аутентификации;
   • какое-либо содержащееся в запросе удостоверение личности (мандат), такое, как пароль;
   • если методом аутентификации является SASL, сервер производит также выборку из запроса связывания LDAP названия используемого механизма SASL.
2. Сервер нормализует отличительное имя, извлеченное из запроса.
3. Сервер извлекает какие-либо содержащиеся в запросе связывания LDAP элементы управления LDAP.
4. Если методом аутентификации является SASL, сервер определяет, поддерживается или нет указанный в запросе механизм SASL. Если механизм SASL не поддерживается сервером, то сервер отправляет клиенту код возврата ошибки и завершает процесс связывания.
5. Если механизм SASL поддерживается ( =EXTERNAL ) и тип аутентификации SSL является аутентификацией сервера и клиента, то сервер подтверждает, что сертификат клиента является действительным, был выпущен известным CA и в цепочке сертификатов клиента не существует недействительных или аннулированных сертификатов. Если пароль и отличительное имя клиента, как указано в ldap_sasl_bind, не имеют значения NULL, то затем для последующих операций LDAP в качестве аутентифицированной личности используется отличительное имя (DN), содержащееся внутри сертификата X.509v3 клиента. В противном случае либо клиент аутентифицируется анонимно (если DN и пароль имеют значение NULL), либо клиент аутентифицируется на основании предоставленной клиентом информации связывания.
6. Если методом аутентификации является Simple (Простой), то сервер осуществляет проверку на предмет того, представлено ли DN пустой строкой, либо на предмет того, что не представлен мандат пользователя.
7. Если DN представлено пустой строкой или если не определено имя (DN) либо не определен мандат, сервер предполагает, что клиент связывается анонимно и возвращает клиенту положительный результат. Для такого соединения DN и метод аутентификации остаются со значениями NULL и LDAP_AUTH_NONE соответственно.
8. Если для клиента не была заблаговременно установлена связь и в процессе операции связывания он не представил сертификат, то соединение отклоняется.

7.3.2 Управление доступом

Использование сертификатов клиента X.509 для SSL-аутентификации^{1Здесь ошибка: имеется в виду SASL-аутентификация.} клиента, как правило, очень жестко по отношению к аутентифицируемому имени. DN в сертификате клиента является именем, под которым проходит аутентификацию пользователь. Таким образом, представленное в сертификате отличительное имя DN должно быть именем, используемым элементами управления доступом к приложениям.

SASL поддерживает такое свойство, как прокси-авторизация (proxy authorization), которое позволяет аутентифицированным пользователям осуществлять запрос выполнения ими действий от лица другого пользователя. Этот шаг происходит после того, как пользователь получает отличительное имя (DN) аутентификации, и влечет за собой отправку серверу личности авторизации. После этого сервер примет решение относительно того, разрешать или нет прохождение авторизации. Если авторизация разрешена, то LDAP-соединение пользователя переключается на применение связанного DN, полученного из личности авторизации, а сеанс LDAP продолжается с применением доступа от лица нового отличительного имени (DN) авторизации.

7.4 DSAPI

Интерфейс прикладного программирования Web-сервера Domino [Domino Web Server Application Programming Interface (DSAPI)] является интерфейсом прикладного программирования на языке С (C API), который позволяет вам писать свои собственные расширения к Web-серверу Domino. Расширения DSAPI, или фильтры, уведомляются всякий раз, когда по время обработки HTTP-запроса происходит определенное событие. Сам по себе DSAPI не является методом SSO, скорее он является частью инструментария разработки, который может применяться для конструирования в интересах Domino пользовательского механизма SSO.

Обратите внимание на то, что некоторые бизнес-партнеры IBM Lotus предлагают как стандартные, так и пользовательские решения для Web-аутентификации пользователей с применением DSAPI на основе инструментария интерфейса прикладного программирования на языке С Domino 6. За дополнительной информацией обратитесь к Web-сайту компании IBM.

Фильтр DSAPI позволяет вам настраивать обработку HTTP-запроса при возникновении определенных событий, например когда пользователь осуществляет доступ к ресурсу на сервере первый раз и вы желаете использовать специальную обработку данных аутентификации вместо обычной Web-аутентификации Domino. Процесс применяет набор предопределенных типов событий. Стек HTTP уведомляет фильтр DSAPI o событиях, после чего определенная разработчиком DSAPI логика принимает решение о том, что делать по факту наступления события. В настоящее время после события StartRequest существует 13 событий, которые могут быть перехвачены фильтром DSAPI. В зависимости от конструкции и ее реализации фильтр может поддерживать либо одно событие, либо некоторое их количество.

Реализация интерфейса DSAPI зависит от того, индикацию ("регистрацию") каких из событий фильтр поддерживает. Итак, фильтр получает от менеджера соединений стека уведомления только о тех событиях, о поддержке которых он заявил. Рис. 7.2 отображает, где фильтр DSAPI вступает в действие на HTTP-сервере Domino относительно другой обработки данных на Web-сервере.

Рис. 7.2. Технологический процесс обработки стека интернет-протокола Domino 6

В общем, события происходят в определенной последовательности. Они отражаются на состоянии стека HTTP на каждом из его шагов по обработке данных. Уведомления о событиях могут рассматриваться как возможность фильтрации (или фильтры) для изменения реализации по умолчанию для заданного шага обработки данных. При каждом событии процедуре обработки уведомления о сообщении фильтра передается структура, которая содержит дополнительную информацию и в большинстве случаев дополнительные функции обратного вызова. Фильтр может запрашивать функции обратного вызова для получения дополнительной информации или для выполнения определенной услуги. Процедура уведомления о событии вызывается только для тех событий, для которых зарегистрирован фильтр (тех, которые передаются в структуре Filter Init Data, когда фильтр загружен и проинициализирован). Типами методов запроса HTTP, при которых могут быть инициированы события, являются:

• Нет метода: метод запроса HTTP не предусмотрен.
• HEAD: метод HEAD часто используется для тестирования гипертекстовых ссылок в целях проверки достоверности, доступности и недавней модификации.
• GET: метод GET используется для выполнения выборки любой информации (в форме объекта), идентифицированной посредством Request-URL (URL-запроса).
• POST: метод POST требует, чтобы исходный сервер принимал объект, содержащийся в запросе, как новую субординантную информацию для ресурса, который идентифицирован посредством Request-URL в Requst-Line (Строка-статус).
• PUT: метод PUT требует, чтобы содержащийся в запросе элемент был сохранен по представленному Request-URL.
• DELETE: метод DELETE требует, чтобы исходный сервер удалил ресурс, идентифицированный посредством Request-URL.
• TRACE: метод TRACE.
• CONNECT: метод CONNECT.
• OPTIONS: метод OPTIONS.
• UNKNOWN: неизвестный метод запроса.
• BAD: неверный метод запроса. Ошибка.

Типы событий описаны в последующих разделах в порядке их возникновения.

Событие kFilterStartRequest

Это событие используется для того, чтобы информировать все загруженные в текущий момент фильтры о том, что запрос HTTP был принят и вскоре будет обрабатываться. На этом шаге фильтр может подготовиться к обработке запроса. Как правило, на этом шаге фильтр должен распределить свои собственные данные секретного контекста и требуемые ресурсы, необходимые для управления обработкой запроса. Параметр pEventData не используется, передается NULL. Любой фильтр, поддерживающий это событие, должен возвращать значение kFilterHandledEvent.