Установление подлинности и идентификация для SSL
SSL клиенты проверяются только тогда, когда они пытаются получить доступ к ограниченным ресурсам. Например, когда пользователи пробуют открыть базу данных, у которой доступ по умолчанию закрыт, при этом требуется использовать SSL, чтобы идентифицировать. Сервер определяет, есть ли у клиента сертификат, имеется ли анонимный доступ, или клиент должен ввести имя и пароль.
Метод использования, подтверждения подлинность LDAP клиентов зависит от того, установленной переменной LDAP_STRICT_RFC_ADHERENCE в файле NOTES.INI.
Правило доверия SSL публичным ключам.
Доверенный сертификат CA подписывает ключевые пары, публичного и личного ключей, и надежно передает их клиенту.
Вы можете доверять любому серверу или клиенту, которые имеют цифровую подпись или для которого Вы имеете сертификат CA, помеченный как Trusted Root.
Пример применения доверия.
Следующий пример описывает, как клиент Hugo использует SSL, чтобы соединиться с сервером Mail-E:
* Hugo пробует доступ к базе данных на сервере Mail-E.
* Mail-E проверяет Server документ, чтобы видеть, позволяется ли SSL для протокола. Если SSL позволяется, установление подлинности продолжается. Иначе, Hugo лишается доступа на сервер с использованием SSL.
* Hugo посылает запрос, Mail-E определяет информацию относительно SSL соединения, типа поддерживаемых алгоритмов шифрования и даты истечения сертификата.
* Mail-E посылает сертификат Hugo, который содержит публичный ключ Mail-E. Hugo проверяет цифровую подпись CA на сертификате Mail-E, чтобы идентифицировать сервера Mail-E. Если Hugo имеет сертификат CA сервер Mail-E, отмеченный как Trusted Root, в своем сертификате, или если Hugo использует клиента Notes, Hugo имеет взаимный сертификат для CA, то Hugo знает, что сертификат сервера Mail-E имеет силу, и опознавательный процесс, продолжается.
В противном случае, опознавательный процесс завершается.
* Если Hugo доверяет сертификату CA Mail-E, Hugo использует алгоритм, чтобы создать ключ сессии. Он использует публичный ключ, сохраненный в сертификате Mail-E, чтобы зашифровать ключ сессии, и посылает его Mail-E. Ключ для сессии, из соображений безопасности генерируется для каждой сессии.
* Mail-E использует личный ключ Mail-E, для де шифрования ключа сессии и использует ключ сессии, чтобы шифровать данные между Hugo и Mail-E.
* Если установление подлинности клиента позволяется, следующее происходит:
· Mail-E запрашивает сертификат Hugo.
· Hugo посылает Mail-E свой сертификат.
· Mail-E проверяет цифровую подпись CA на сертификате Hugo, чтобы проверить идентичность Hugo. Если Mail-E имеет сертификат CA Hugo, отмеченным как Trusted Root в сертификате сервера, то Mail-E знает, что сертификат Hugo имеет силу.
· Mail-E проверяет имя пользователя, в Person документе и имя в сертификате Hugo и подтверждает, что публичный ключ в сертификате Hugo, соответствует публичному ключу в его Person документе. Mail-E проверяет сначала Person документы в первичном Domino Directory. Mail-E также проверяет вторичные Domino Directory и LDAP Directory, если пользователь - Web клиент, а Domino сконфигурирован для поиска во вторичных Domino Directory и LDAP Directory.
* Если Mail-E не может идентифицировать Hugo, Mail-E проверяет, позволяется ли анонимный доступ на сервер для протокола.
Если позволено, следующее происходит:
· Сервер проверяет, имеется ли запись имени Anonymous в ACL базы данных.
· Если не имеется, сервер проверяет доступ по умолчанию.
· Если доступ по умолчанию читатель и выше, то Hugo позволяется анонимный доступ к базе данных, используя уровень доступов - по умолчанию.
* Если анонимный доступ не разрешается, или если в ACL базы данных не позволяет анонимный доступ, сервер проверяет, позволяется ли идентификация, с использованием имени и пароля, на сервере, для протокола. Если доступ по имени и пароля позволяется, следующее происходит:
· Сервер просит, чтобы Hugo ввел свое имя пользователя и пароль.
· Сервер проверяет имя в Person документах для пользователя Hugo и пароль, который Hugo ввел. Сервер также проверяет вторичные Domino Directory и LDAP Directory, если пользователь - Web клиент, а Domino сконфигурирован для поиска во вторичных Domino Directory и LDAP Directory..
· Если пароль верен, сервер проверяют ACL базы данных для первой записи, из списка имен Person документа для Hugo.
* Если первая запись в поле имени, соответствует записи в ACL, Hugo получает доступ к базе данных, используя уровень доступа, указанный для этой записи.