Инфраструктуры открытых ключей

Перекрестный сертификат Интернета

Несмотря на тему о сертификатах, давайте потратим немного времени для рассмотрения перекрестных сертификатов в Интернете, так как мы уже рассмотрели тему об перекрестных сертификатах в инфраструктуре открытых ключей Notes.

Перекрестный сертификат Интернета, как и обычный интернет-сертификат, является сертификатом, который подтверждает идентичность пользователя или сервера. Этот тип сертификата гарантирует получателю зашифрованного S/MIME-сообщения, что сертификат отправителя может быть доверенным, и то, что используемый для подписи S/MIME-сообщения сертификат является действительным. Также он подтверждает идентичность сервера в том случае, когда клиент Notes использует для доступа к интернет-серверу протокол SSL.

Перекрестный сертификат Интернета сохраняется в документе Certificate персональной адресной книги пользователя и может быть применен только тем пользователем, для которого он был выпущен. Перекрестный сертификат Интернета может быть выпущен для "листового" сертификата (leaf certificate)2 (что означает – для сертификата, выпущенного центром сертификации для пользователя или сервера) или для самого СА.

Создание перекрестного сертификата для листового сертификата отображает доверие только к пользователю сертификата (к примеру, к отправителю подписанного сообщения или к получателю зашифрованного сообщения). Перекрестный сертификат для СА отображает доверие для всех владельцев, которые имеют выпущенный этим СА сертификат.

Если СА перекрестно сертифицировал СА, то этим оказывается доверие СА на выпуск сертификатов для пользователей и серверов, находящихся ниже в иерархическом дереве имен. К примеру, после перекрестной сертификации Sales/Acme доверие оказывается Sales/ABC на выпуск сертификата для Fred/Sales/Acme. В качестве альтернативы после создания перекрестного сертификата для Fred/Sales/Acme доверие оказывается только Fred/Sales/Acme.

За подробной информацией о том, как создать перекрестный сертификат Интернета для СА, обратитесь к разделу "Создание перекрестного сертификата Интернета для СА " базы данных помощи Lotus Domino Administrator 6.

Мы покажем сертификаты X.509 в действии достаточно кратко. Перед тем как мы сможем сделать это, необходимо повторно просмотреть материал об аутентификации, так как она важна в Интернете настолько же, насколько она важна в среде Notes. Для напоминания о том, почему так важна аутентификация, обратитесь к разделу "Аутентификация".

6.2.4 Аутентификация Web-клиента

В этом разделе мы опишем различные методы, которые доступны для проведения аутентификации пользователей Интернета и интранета.

Протоколом связи прикладного уровня, используемым в WWW, является протокол HTTP (Hypertext Transfer Protocol). В HTTP включена схема с использованием простого имени пользователя и аутентификации на основе пароля, известная как основная (или базовая) аутентификация. Реализация основной аутентификации является специфической для каждого сервера, но обычно все они используют ее в двух целях:

• как механизм для идентификации того, какой пользователь осуществляет доступ к серверу;
• для ограничения доступа пользователей к отдельным страницам (идентифицированных URL-адресами).

После того как установлен доступ на основе имени и пароля и для интернет- или интранет-пользователей созданы документы Person, Domino будет осуществлять аутентификацию пользователей в тех случаях, когда:

• они предпринимают попытки сделать что-либо, для чего ограничен доступ;
• на сервере не разрешен анонимный доступ.

К примеру, когда пользователь пытается открыть базу данных, которая имеет список управления доступом (ACL) с параметром No Access (Нет доступа) по умолчанию, Domino запрашивает пользователя о действительном имени пользователя и пароле. Аутентификация пройдет удачно только в том случае, если пользователь предоставит имя и пароль, которые соответствуют имени и паролю, хранящимся в документе Person пользователя, и если ACL базы данных предоставит этому пользователю доступ. Аутентификация анонимных пользователей не производится.

Существует возможность использовать доступ по имени и паролю и анонимный доступ вместе с протоколом TCP/IP и протоколом SSL (который мы подробно рассмотрим в следующем разделе). Анонимный доступ и доступ на основе имени и пароля вместе с протоколом TCP/IP описаны здесь.

Этот раздел применим также к Web-клиентам, осуществляющим доступ к Web-серверу Domino, для которого была разрешена аутентификация сеанса.

Аутентификация по имени и паролю (Name-and-password authentication)

Аутентификация по имени и паролю, известная также как основная парольная аутентификация, использует для опроса пользователей на предмет их имен и паролей протокол типа "запрос/ответ", после чего контролирует точность паролей путем проверки их по отношению к безопасному хешу паролей, хранящихся в документах Person каталога Domino.

Когда это настроено, Domino запрашивает имя и пароль только в тех случаях, когда интернет- или интранет-пользователь пытается получить доступ к защищенному ресурсу сервера. Интернет- или интранет-доступ отличается от доступа клиента Notes и сервера Domino тем, что сервер Domino запрашивает клиента Notes или сервер Domino на предмет имени и пароля, когда клиент или сервер осуществляют первоначальные попытки получить доступ к серверу.

Если администратор желает назначить доступ к базе данных со стороны интернет- или интранет-клиента, основываясь на обеспечиваемой ACL безопасности Domino, то данный человек должен создать для этого клиента документ Person в каталоге Domino либо, на свой выбор, во вторичном каталоге Domino или внешнем каталоге LDAP. Клиенты, которые не имеют документов Person, рассматриваются как анонимные и могут получить доступ только к тем серверам и базам данных, к которым разрешен анонимный доступ.

Аутентификация по имени и паролю позволяет Domino определить местоположение документа Person (если он существует) для обеспечения доступа клиента к серверу. Доступ к ресурсам сервера может быть разрешен только после идентификации клиента. К примеру, если мы хотим задать Алисе доступ к базе данных с правами Editor (Редактор), а все остальные осуществляют доступ к базе данных с правами Author (Автор), для Алисы необходимо создать документ Person. Существует возможность настроить список управления доступом (ACL) к базе данных для включения туда Алисы с правами Editor, а анонимных пользователей (Anonymous) с правами Author.

Аутентификацию по имени и паролю можно использовать либо с TCP/IP, либо с SSL на любых серверах, на которых используется интернет-протокол (LDAP, POP3, HTTP, SMTP, IIOP или IMAP).

Пример аутентификации по имени и паролю с использованием протокола HTTP показан на рис. 6.20. Сам процесс описан ниже.

Рис. 6.20. Аутентификация по имени и паролю с использованием протокола HTTP

1. Пользователь щелкает мышью на странице с ограниченным доступом (результатом чего, как правило, является операция GET протокола HTTP).
2. Сервер проверяет, разрешен ли к этой странице анонимный доступ. Если не разрешен, сервер отклоняет запрос (как правило, путем отправки назад ответа Private (Конфиденциально) из области состояния 401 HTTP). После получения от сервера этого ответа Web-браузер выводит диалоговое окно простой аутентификации и предлагает пользователю ввести его имя и пароль.
3. Web-браузер повторно отправляет идентичный запрос, который в основном подобен операции GET протокола HTTP в шаге 1, за исключением того, что в заголовках передаются ID пользователя и пароль (зашифрованные в формате Base64).
4. Сервер производит аутентификацию пользователя и, если операция прошла успешно, предоставляет пользователю запрашиваемую информацию. Если операция аутентификации проходит неудачно, то сервер отправляет пользователю сообщение об ошибке аутентификации.

В общем, на рисунке показано, что, когда клиент запрашивает определенный URL-адрес, сервер проверяет, требуется ли для данного URL-адреса применять аутентификацию. Если да, то сервер отклоняет запрос с кодом состояния 401. На экране пользователя появляется диалоговое окно, запрашивающее ID пользователя и пароль. Когда пользователь представляет их, браузер повторно отправляет первоначальный запрос, но с добавлением в него следующего MIME-элемента с HTTP-заголовком:

Authorization : Basic <user ID and password block>

ID пользователя ( user ID ) и блок пароля ( password block ) сконструированы путем создания строки формы UserID:Password с последующим кодированием ее с помощью алгоритма Base64.

Запрос пароля у пользователей не производится каждый раз повторно при доступе к странице с ограниченным доступом, потому что браузер кеширует в памяти ID пользователя, пароль, имя сервера и название области. Таким образом, если он получает другой код состояния 401 для той же комбинации "сервер/область", браузер может повторно выдать запрос с применением соответствующих ID пользователя и пароля.

Некоторые браузеры идут дальше и просто отправляют ID пользователя и пароль любому URL-адресу, которому это, вероятно, необходимо. Как Opera и Mozilla, Netscape Navigator и Internet Explorer отправляют информацию с любым URL, который находится в том же логическом каталоге.

Целью этих технических приемов является уменьшение сетевого трафика и увеличение быстроты реакции путем исключения определенного количества неверных запросов и ответов с кодом состояния 401. К сожалению, они имеют и нежелательный побочный эффект, заключающийся в повторной передаче ID пользователя и пароля в тех случаях, когда, возможно, в этом нет необходимости.

Однако существуют способы для ослабления этого явления. Для каждого разрешенного на сервере интернет-протокола существует возможность указать метод обеспечения безопасности. К примеру, администратор может разрешить для соединений HTTP аутентификацию клиента с применением сертификата, но для соединений LDAP, которые используют протокол TCP/IP, потребовать обеспечения безопасности с применением имени и пароля. Либо администратор может использовать обеспечение безопасности с применением имени и пароля при анонимном доступе и при аутентификации клиента SSL, например для разрешения пользователям с сертификатами клиентов SSL проводить аутентификацию с использованием аутентификации клиента SSL и для разрешения прочим пользователям вводить имя и пароль, если они не имеют сертификата клиента SSL.

Примечание. Аутентификация с использованием имени и пароля не поддерживается, когда сервер Domino работает как SMTP-клиент, например когда сервер Domino соединяется с SMTP-сервером для передачи почты. Аутентификация с использованием имени и пароля поддерживается только в тех случаях, когда сервер Domino работает как SMTP-сервер, а именно когда SMTP-клиенты получают доступ к серверу Domino.

Существует возможность выбрать уровень ограничения, который Domino применяет при аутентификации пользователей в каталогах Domino и каталогах LDAP. Это применимо ко всем интернет-протоколам (HTTP, LDAP, IMAP, POP3). Использование этой установки делает серверы менее уязвимыми для атак по безопасности путем уточнения того, как Domino осуществляет поиск имен и проводит аутентификацию интернет-клиентов. Domino также применяет эту установку, когда расположенный на сервере Domino Java-апплет производит аутентификацию пользователей по протоколу IIOP Domino.

Меньшее количество вариантов имени с более высокой степенью обеспечения безопасности (Fewer name variations with higher security)

Опция Fewer name variations with higher security является установкой по умолчанию и рекомендуется для обеспечения наилучшей безопасности. Этот метод аутентификации менее уязвим для атак, потому что попытка простой аутентификации не порождает так много совпадений, уменьшая вероятность соответствия предполагаемого пароля. Пользователям требуется ввести только те элементы, которые перечислены в табл. 6.2 в диалоговом окне введения имени и пароля Web-браузера или другого интернет-клиента.

Большее количество вариантов имени с более низкой степенью обеспечения безопасности (More name variations with lower security)

Domino пытается производить аутентификацию пользователей на основе введенных имен и паролей. Этот метод аутентификации может быть уязвим для хакеров, которые подбирают имена и пароли в попытке применить для доступа к серверу легальную учетную запись пользователя. Эта опция дает возможность пользователям вводить любые из перечисленных в табл. 6.3 элементов в диалоговом окне введения имени и пароля Web-браузера.

Если аутентификация по имени и паролю рассматривается для сервера HTTP, то существует дополнительный метод, который может использоваться совместно с ней: аутентификация на основе сеанса.

Аутентификация по имени и паролю отправляет имя и пароль в незашифрованном формате, причем отправка происходит при каждом запросе. Аутентификация на основе сеанса отличается тем, что имя пользователя и пароль заменяются на cookie.

Имя пользователя и пароль отправляются по сети только один раз, когда пользователь подключается к серверу. Впоследствии для аутентификации применяется cookie.

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

Аутентификация по имени и паролю при незащищенных соединениях

Аутентификация по имени и паролю при незащищенных соединениях (не являющихся SSL-соединениями) применяется для идентификации пользователей без обеспечения наилучшей безопасности при доступе к данным на сервере, например когда администратор желает отобразить другую информацию для других пользователей при предоставлении имени пользователя и когда информация в базе данных не является конфиденциальной. Между пользователем и сервером в зашифрованном виде не передается никакая информация, включая имя и пароль. В этом случае аутентификации по имени и паролю некоторые хакеры удерживаются от проведения атак, что, впрочем, не предотвращает действия других по прослушиванию сетевых пересылок и подбору паролей.

Аутентификация по имени и паролю по протоколу SSL

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

Настройка аутентификации по имени и паролю

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

За дополнительной информацией о DSAPI обратитесь к инструментарию программного интерфейса приложений для криптографии Lotus для Domino и Notes. Этот инструментарий доступен по следующему адресу:

http://www.lotus.com/techzone

Сеансовая аутентификация по имени и паролю (Session-based name-and-password authentication)

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

Сеансом считается время, в течение которого Web-клиент проводит работу на сервере с наличием cookie. Для указания параметров, которые разрешат сеансовую аутентификацию и дадут возможность управлять ею, в зависимости от желаемой конфигурации должен быть отредактирован документ Web Site или документ Server.

Кроме того, при разрешении сеансовой аутентификации существует два варианта выбора: опция использования для отдельного сервера и опция для мультисерверного использования. Выбор опции применения для отдельного сервера вызывает генерирование cookie, который принимается на обработку только тем сервером, который его сгенерировал, тогда как опция для мультисерверного использования генерирует cookie, который позволяет применить принцип единственной подписи при работе с любым сервером, который участвует в совместном употреблении документа конфигурации принципа единственной подписи для Web.

Для применения аутентификации на основе сеанса Web-клиенты должны использовать браузер, который поддерживает cookies.

Свойства сеансовой аутентификации по имени и паролю

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

Кастомизация HTML-формы начала сеанса

HTML-форма начала сеанса дает возможность пользователю вводить имя и пароль, после чего применять эти имя и пароль на протяжении всего пользовательского сеанса. Браузер отправляет имя и пароль серверу с использованием набора символов сервера. При сеансовой аутентификации по протоколу HTTP пользователь может ввести имя с применением любых печатаемых символов из кодовой таблицы Unicode. Однако пароль пользователя должен быть введен любыми печатаемыми символами из кода US-ASCII.

Примечание. Диапазон печатаемых символов не допускает наличия управляющих символов.

Domino предусматривает HTML-форму по умолчанию ($$LoginUserForm), которая предоставляется и конфигурируется в базе данных конфигурации Domino (DOMCFG. NSF). Вы можете настроить эту форму или создать новую собственную форму, содержащую дополнительную информацию, которая может быть представлена пользователю. К примеру, вы можете модифицировать форму так, чтобы она выглядела единообразной по стилю с оставшейся частью вашего интернет- или интранет-сайта.

Временной период окончания сеанса по умолчанию

Вы можете задать временной период окончания сеанса по умолчанию для отключения Web-клиента от сервера после указанного периода отсутствия его активности. Это приведет к тому, что cookie, который Domino применяет для отслеживания сеанса пользователя, окончит функционирование.

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

Если для сервера разрешена аутентификация по имени и паролю на основе сеанса, то пользователи могут также добавлять в конец URL-адреса ?logout для окончания сеанса, например:

http://acmeserver/sessions.nsf?logout

Также существует возможность по окончании сеанса осуществлять перенаправление к элементу дизайна или к URL-адресу, для примера приведем следующие адреса:

http://acmeserver/sessions.nsf?logout&redirectto=/logoutDB.nsf/logoutApp?Open
http://acmeserver/sessions.nsf?logout&redirectto=http://www.sales.com

Существует возможность встроить такое выражение в приложение (к примеру, используя его в кнопке) или вписать его как URL-адрес.

Максимальное количество пользовательских сеансов

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