Система и способ предоставления доступа к защищенным услугам с однократным вводом пароля

Система и способ предоставления доступа к защищенным услугам с однократным вводом пароля

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Настоящее изобретение относится в широком смысле к аутентификации, авторизации и контролю доступа, а более конкретно - к способу и системе для аутентификации на базе инфраструктуры открытых ключей (PKI - Public Key Infrastructure). Система и способ по изобретению позволяют пользователям с помощью единственного электронного идентификатора (ИД) получить защищенный доступ ко всем видам сервисов (услуг).

Уровень техники

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

Современные решения задачи аутентификации (идентификации подлинности пользователя), ориентированные на Интернет сервис-провайдеров (ISPs, Internet Service Providers) или других провайдеров коммуникационных сервисов, основанных на Интернет-протоколе, базируются, в основном, на именах пользователей и паролях. Протокол RADIUS (Remote Authentication Dial-In User Service) подобно протоколам типа TACACS+ (Terminal Access Controller Access Control System) обеспечивает доступ к сервисам, которые предусматривают централизованное администрирование и валидацию (подтверждение соответствия) как аутентифицирующей информации, так и авторизации, которая приписана аутентифицированным именам пользователей. Группа инженеров Internet (IETF - Internet Engineering Task Force) силами своей рабочей группы Diameter продолжает работу по разработке следующего поколения подобных протоколов.

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

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

Уровень техники, достигнутый в сфере PKI, еще не имеет требуемого уровня общности. Наоборот, пользователи часто сталкиваются с использованием различных решений на базе PKI (взамен применения различных имен пользователей и паролей) для получения доступа к различным сервисам. Кроме того, не так много сервисов в настоящее время доступны через PKI, хотя подобная возможность может потенциально присутствовать применительно ко многим сервисам в форме процедур аутентификации клиента типа протоколов SSL/TLS (Secure Socket Layer/Transport Layer Security). Описываемая далее система развивает уровень техники путем разработки единой аутентификации на базе PKI. Предлагая услуги по валидации, а также, возможно, и авторизации другим сервис-провайдерам, система способна обеспечить создание инфраструктуры для широкой аутентификации на базе PKI.

Раскрытие изобретения

Таким образом, в данном описании будет представлено усовершенствованное решение задачи аутентификации, авторизации и контроля доступа, основанное на использовании сертификатов и PKI-технологии совместно с механизмами, делающими доступными платные сервисы, предлагаемые через компьютерные сети. Главные преимущества предлагаемого решения на базе PKI - это общность, возможность постепенного развития и расширенная функциональность (управление ключом шифрования, цифровая подпись). В будущем пользователь должен иметь единственный носитель ключа (например, смарт-карту), содержащий личные (секретные) ключи и сертификаты, которые формируют электронный ИД пользователя. Электронный ИД пользователя обычно состоит из двух или трех различных пар личный ключ/сертификат, служащих для различных применений. Большинство решений используют две таких пары, одну для шифрования (рассчитанного на применение только этого конкретного личного ключа), а вторую - для всех остальных применений. При этом часто рекомендуется возложить функцию цифровой подписи на отдельную, третью пару; однако эта рекомендация не нашла широкой поддержки в различных продуктах и сервисах.

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

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

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

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

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

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

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

Фирмы, выпускающие или использующие кредитные карты, начинают требовать аутентификации пользователя через Интернет, причем аутентификация пароля принимается только на короткое время. Введение общего PKI позволит таким фирмам принимать электронный ИД, который уже имеется у пользователя (при условии, что он отвечает предъявляемым квалификационным требованиям), и тем самым устранить необходимость выпуска отдельного электронного ИД для использования при осуществлении платежей.

Описываемая далее система обеспечит средства для защищенной аутентификации, авторизации и контроля доступа применительно к платным сервисам, таким как Video on Demand (VOD - "Видео по запросу"), а также средства для осуществления защищенных платежей.

Таким образом, изобретение относится в широком смысле к аутентификации, авторизации и контролю доступа, а более конкретно - к способу и системе для аутентификации на базе инфраструктуры открытых ключей (PKI - Public Key Infrastructure), позволяющей пользователям с помощью единственного электронного идентификатора (ИД) получить защищенный доступ ко всем видам сервисов (услуг). Система по изобретению развивает уровень техники путем разработки единой аутентификации на базе PKI. Благодаря тому что система предлагает услуги по валидации и, возможно, аутентификации другим сервис-провайдерам, она позволяет создать инфраструктуру для универсальной аутентификации на базе PKI.

Иными словами, изобретение относится к системе, охарактеризованной в независимом п.1 формулы изобретения. Изобретение относится также к применению, охарактеризованному в независимом п.11. Далее, изобретение относится к способу, охарактеризованному в независимом п.13 формулы изобретения. Рекомендуемые варианты изобретения представлены в зависимых пунктах формулы.

Краткое описание чертежей

Далее изобретение будет описано со ссылками на прилагаемые чертежи.

На фиг.1 представлен общий вид архитектуры для осуществления аутентификации и авторизации.

Фиг.2 иллюстрирует альтернативный способ проверки достоверности сертификата пользователя.

На фиг.3 представлена блок-схема процесса аутентификации, проверки авторизации и доступа к сервису.

Фиг.4 иллюстрирует доступ к платному сервису.

Фиг.5 дает общее представление о службе валидации.

Осуществление изобретения

На фиг.1 представлена архитектура системы по настоящему изобретению. Аутентификация пользователя (клиента) в типичном варианте осуществляется в режиме аутентификации клиента по протоколам SSL/TLS, после чего пользователю предоставляется доступ (на сервере доступа) к сетевому интерфейсу, снабженному меню, относящемуся к комплекту сервисов, на которые пользователь может подписаться. Коммуникация между клиентом и сервером доступа должна иметь криптографическую защиту. Протоколы SSL/TLS представляют желательный вариант, поскольку соответствуют обычному способу защиты коммуникаций (HTTP) в сети и, кроме того, могут включать аутентификацию пользователя. В качестве альтернативной двусторонней связи может быть назван протокол IPSec/VPN (Internet Protocol Security/Virtual Private Network).

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

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

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

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

На фиг.2 приведена блок-схема процедур аутентификации, проверки авторизации и доступа к сервису. Применительно к службе валидации могут использоваться несколько различных протоколов. Если служба валидации должна предлагаться сервис-провайдерам в качестве отдельной услуги, то должен использоваться протокол стандартного типа. Возможной альтернативой является протокол OCSPv1 (On-line Certificate Status Protocol, version 1 - Протокол онлайнового состояния сертификата, версия 1), который позволяет осуществлять проверку статуса сертификата в отношении его отзыва и возвращает также некоторую дополнительную информацию, например имя пользователя. Однако пока нельзя передать в службу валидации полный сертификат стандартизованным образом; это можно сделать только с помощью нестандартизованного "расширения". Возможность пересылки полного сертификата обеспечит протокол OCSPv2, который находится пока в версии RFC (Request For Comments). Протокол SCVP (Simple Certificate Validation Protocol - Простой протокол валидации сертификата) имеет тот же статус, что и OCSPv2, и обеспечивает те же функциональные возможности. XKMS (XML Key Management Specification - Спецификация использования открытого ключа на языке XML), как и другие механизмы на базе схем XML, является еще одной альтернативой, в частности, с применением протокола SOAP (Simple Object Access Protocol - Простой протокол доступа к объекту).

Располагая подтвержденной идентификацией пользователя, сервер доступа запрашивает службу авторизации о правах доступа, которые должны быть предоставлены поименованному пользователю. Запрос может быть расширен за счет дополнительной информации, например, касающейся качества процедуры аутентификации пользователя, а также контекстной информации типа текущего местоположения пользователя, времени дня и т.д. Доступ к службе авторизации должен быть основан на стандартном протоколе, каковым может служить, в частности, LDAP (Lightweight Directory Access Protocol - Упрощенный каталог службы протоколов), RADIUS, его планируемый заменитель DIAMETER или какой-либо иной протокол.

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

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

Блок-схема, приведенная на фиг.2, показывает операции (шаги), выполняемые в рамках процедур аутентификации, проверки авторизации и доступа к сервису.

Далее будет описан типичный вариант установления связи и доступа к сервисам. Оборудование пользователя или его домашняя сеть подсоединены к инфраструктуре, предлагаемой оператором сети, через какую-либо точку доступа, которая в типовом случае обеспечивает протоколы в канале данных или в слое доступа, или в сетевом слое (например, IP-протокол). На фиг.1 точка доступа не изображена, поскольку она функционирует только в качестве трассировщика в части сетевого доступа между пользователем и сервером доступа. Точка доступа может быть разделена на два компонента, один из которых предлагает услуги на уровне канала данных/слоя доступа, тогда как второй является IP-трассировщиком.

Когда оборудование пользователя подсоединяется к сетевой инфраструктуре, в типичном случае оно получает доступ по умолчанию, т.е. минимальный набор разрешенных коммуникационных трактов. В архитектуре, представленной на чертеже, должен быть активирован тракт к серверу доступа; кроме того, обычно активируется также Domain Name Service (DNS - доменная система имен). К этой минимальной конфигурации могут быть добавлены и другие сервисы/тракты.

Когда пользователь на своем оборудовании открывает браузер, то для того, чтобы пользователь мог получить доступ к сервисам, на браузере должен быть задан Uniform Resource Locator (URL - Унифицированный указатель ресурсов) сервера доступа. Далее пользователь должен пройти процедуру аутентификации и проверки авторизации, после чего ему будет предоставлен доступ к сервисному меню.

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

Коммуникационные сервисы. Когда пользователь выбирает коммуникационный сервис, его запрос должен быть привязан к точке доступа пользователя для того, чтобы создать тракт в направлении выбранной точки назначения. Тракт может быть активирован в IP-слое, открывая возможности для графика от IP-адреса (адресов) пользователя к конкретной точке (конкретным точкам) назначения. Тракт может быть активирован также в слое канала данных, например, путем формирования виртуального контура АТМ (Asynchronous Transfer Mode - Режим асинхронной передачи).

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

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

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

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

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

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

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

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

Медийные/мультимедийные сервисы. Как уже упоминалось, (мульти)медийные сервисы могут рассматриваться как комбинация коммуникационных и сетевых сервисов. Некоторые медийные сервисы могут быть реализованы как полностью сетевые или как полностью коммуникационные; однако обычный сценарий соответствует сервису, обеспечивающему сетевой интерфейс для запуска сервиса и реализацию сервиса, которая использует функциональные возможности сети.

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

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

На фиг.4 приведен пример аутентификации, авторизации и доступа к платному сервису, такому как Video on Demand (VOD), а также защищенного платежа (в режиме платы за фактическое использование).

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

Далее изобретение будет описано более подробно со ссылкой на фиг.2.

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

-поддерживать HTTPS (HTTP по протоколу SSL/TLS) или, альтернативно, быть способным обеспечивать другие средства формирования защищенных коммуникационных каналов;

- иметь возможность аутентифицировать себя клиентам/пользователям, предпочтительно с использованием PKI-технологии (в частности, в режиме аутентификации сервера по протоколу SSL/TLS);

- поддерживать протоколы, необходимые для осуществления коммуникации со службами валидации и авторизации;

- поддерживать один или более протоколов для аутентификации клиента/пользователя на базе PKI-технологии, как правило, по протоколу SSL/TLS;

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

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

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

При этом имеются два альтернативных способа: если применяется иной метод аутентификации на базе PKI, то сессия по протоколу SSL/TLS может быть проведена только для аутентификации сервера, после чего в созданном тем самым защищенном канале может выполняться протокол аутентификации пользователя. Если при выборе метода аутентификации существуют несколько альтернатив, то для выбора метода пользователю может быть предоставлена чисто текстовая страница (например, http-страница). После осуществления выбора метода аутентификация будет продолжена, например, путем установления SSL/TLS-сессии для аутентификации клиента.

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

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

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

Служба валидации оптимизирована для обработки сертификатов. Она получает сертификат или идентификацию сертификата и его издателя и выполняет следующие действия:

- считывает имя издателя;

- получает открытый ключ издателя из списка "хороших" ключей, прошедших предшествующую оценку; при этом все операции по перекрестной сертификации или построению иерархий также проводятся заранее, а все открытые ключи издателя непосредственно принимаются как истинные, т.е. в обработке цепочек сертификатов нет необходимости;

- выполняет проверку отзыва, предпочтительно с обращением к локальной, предварительно обработанной информации об отзывах, собранной путем периодического получения списков отозванных сертификатов (Certificate Revocation List - CRL);

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

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

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

Для работы со службой валидации могут быть применены несколько протоколов. В настоящее время доступным является, в частности, протокол OCSP version 1. Однако он не включает стандартизованный метод передачи полного сертификата. Такая возможность введена в OCSP-протокол version 2, который в настоящее время имеется в Интернет в виде предварительной версии. Альтернативными протоколами, которые способны заменить или дополнить OCSP-протокол, являются вышеупомянутые SCVP, который в настоящее время является версией, имеющейся в Интернет, и XKMS. Протоколы могут быть основаны также на протоколе SOAP (по существу, представляющем комбинацию XML и HTTP) или на аналогичных технологиях; кроме того, может быть разработан и какой-то специальный протокол на правах частной собственности. Все подобные протоколы, в дополнение к ответу типа "да/нет/неизвестен" на запрос о валидации, должны обеспечивать также возможность возврата дополнительной информации лицу, направившему запрос.

OCSP-протокол разработан прежде всего в качестве замены практики выпуска списков CRL одной организацией, ответственной за выдачу сертификатов. Вместо списков CRL или в дополнение к ним издатель сертификатов обеспечивает OCSP-интерфейс, который отвечает на запросы относительно действительности сертификатов, выпущенных именно данным издателем сертификатов. В контексте изобретения служба валидации будет обеспечивать единый OCSP-сервис для всех тех организаций, выдающих сертификаты, которые могут взаимодействовать с данной службой.

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

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

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

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

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

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

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

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

- Развертывание виртуальной сети VPN. Обработка на этом этапе будет примерно такой же, что и по сценарию аутентификации клиента по протоколу SSL.

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