Контекст устойчивой авторизации на основе внешней аутентификации

Контекст устойчивой авторизации на основе внешней аутентификации

Иллюстрации

Показать все

Реферат

Родственные патентные заявки

Настоящая патентная заявка связана с патентной заявкой США № 09/886146 на «Способы и системы для управления объемом делегирования полномочий аутентификации», поданной 20 июня 2001 года и которая включена в настоящее описание посредством ссылки.

Область техники

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

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

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

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

Обычно регистрация пользователя в компьютере и аутентификация пользователя для управления сетевым доступом представляют собой две отдельные процедуры. Тем не менее, чтобы минимизировать трудности пользователя при реализации различных схем управления доступом, регистрацию пользователя и аутентификацию пользователя для сетевого доступа иногда выполняют вместе. Например, в случае, когда аутентификация пользователя реализуется согласно протоколу Kerberos, когда пользователь регистрируется в компьютере, компьютер также может инициировать процесс аутентификации Kerberos. В процессе аутентификации Kerberos компьютер устанавливает связь с центром распределения ключей Kerberos (KDC), чтобы сначала получить мандат на получение разрешения (TGT) для пользователя. Затем компьютер может использовать TGT для получения для себя от KDC мандата на сеанс.

В процессе своей эволюции сети обросли множеством ярусов, состоящих из компьютеров-серверов/сервисов, расположенных таким образом, чтобы обеспечить обработку запросов клиентских компьютеров. Простым примером этого является клиентский компьютер, запрашивающий Web-сайт Всемирной паутины через Интернет. Здесь может иметься входной (клиентский) web-сервер, который обрабатывает форматирование и соответствующий деловой регламент запроса, и оконечный сервер (сервер базы данных), который управляет базой данных для Web-сайта. Для дополнительной защиты Web-сайт может быть конфигурирован таким образом, что протокол аутентификации направляет (или делегирует) полномочия (“верительные данные”), такие как, например, TGT пользователя, и/или, возможно, другую информацию от клиентского сервера на оконечный сервер. Такая практика находит все большее распространение на многих Web-сайтах и/или в других многоярусных сетях.

Делегирование и другие аналогичные способы полезны тогда, когда все серверы/сервисы и клиент согласны использовать один и тот же процесс аутентификации. Однако на сегодняшний день используется не один процесс аутентификации. В совместно рассматриваемой патентной заявке США №09/886146 предлагается усовершенствованный процесс управления делегированием.

Если пользователь аутентифицирован для работы в сети/системе, то тогда для предотвращения доступа этого пользователя к ресурсам, на доступ к которым у него нет полномочий, обычно выполняют одну или несколько дополнительных проверок авторизации, необходимых для управления доступом. Как только пользователь будет аутентифицирован и пройдет необходимые проверки для управления доступом, этот пользователь объявляется «авторизованным». В некоторых системах управление доступом основано, например, на списках управления доступом (ACL) для различных сервисов и ресурсов (то есть объектов). Список ACL обычно включает записи управления доступом (ACE), в которых может быть включено нулевое или большее количество идентификаторов защиты (SID). Идентификаторы SID могут быть связаны с одним пользователем или группами пользователей, которым разрешен доступ к данному объекту. Если в списке ACL нет идентификаторов SID, то тогда ни один пользователь не будет иметь доступ к данному объекту. Если в списке ACL имеются идентификаторы SID, то тогда пользователям, которые смогут сформировать по меньшей мере один совпадающий SID, будет разрешен доступ к данному объекту.

Таким образом, когда аутентифицированный пользователь регистрируется, для этого пользователя создается контекст аутентификации, например, путем формирования маркера (например, маркера доступа), который связан с этим пользователем. Маркер обычно содержит идентификаторы SID, которые связаны с этим пользователем. Например, маркер пользователя может включать уникальный SID, присвоенный данному пользователю, плюс групповой SID, присвоенный подразделению предприятия пользователя. Когда пользователь пытается получить доступ к объекту, ACL объекта сравнивают с маркером пользователя. Если маркер пользователя содержит по меньшей мере один SID, который совпадает с SID в списке ACL объекта, то тогда аутентифицированный пользователь получает право доступа к объекту до некоторой степени. Например, пользователю может быть разрешено считывать или записывать файл, созданный другими работниками его отдела (то есть другим членом группы).

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

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

Сущность изобретения

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

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

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

для данного вычислительного ресурса (ресурсов).

Согласно другим аспектам настоящего изобретения предлагается способ для преобразования идентификатора PUID в соответствующий идентификатор SID. Этот способ включает прием идентификатора PUID, разделение его по меньшей мере на одну часть идентификатора субполномочий и по меньшей мере одну часть идентификатора-члена и компоновку части идентификатора субполномочий и части идентификатора-члена для формирования SID.

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

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

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

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

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

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

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

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

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

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

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

Подробное описание изобретения

Обзор

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

В следующем разделе описывается пример вычислительной среды. В последующих разделах кратко описаны типовые технологии S4U2proxy и S4U2self, которые являются предметом совместно рассматриваемой патентной заявки США №09/886146.

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

Типовая вычислительная среда

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

На фиг. 1 показан пример подходящей вычислительной среды 120, в которой можно реализовать описанные далее способы и системы.

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

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

Как показано на фиг. 1, вычислительная среда 120 включает в себя вычислительное устройство общего назначения в виде компьютера 130. Компоненты компьютера 130 могут включать один или несколько процессоров или блоков 132 обработки данных, системную память 134 и шину 136, которая связывает различные системные компоненты, включая системную память 134, с процессором 132.

Шина 136 представляет собой шинную структуру одного или нескольких типов, включая шину памяти или контроллер памяти, периферийную шину, ускоренный графический порт и процессор или локальную шину, использующую любую из множества различных шинных архитектур. Как пример, но не ограничение, указанные архитектуры включают шину ISA (архитектура шины промышленного стандарта), шину MCA (микроканальная архитектура), шину EISA (расширенная архитектура ISA), локальную шину VESA (стандарт высокоскоростной локальной видеошины) и шину PCI (межсоединение периферийных компонентов), известную также как шина Mezzanine.

Компьютер 130 обычно содержит различные машинно-считываемые носители. Такими носителями могут быть любые имеющиеся в наличии носители, доступные компьютеру 130, к которым относятся как энергозависимые, так и энергонезависимые носители, съемные и несъемные носители.

На фиг. 1 системная память 134 включает в себя машинно-считываемый носитель в виде энергозависимой памяти, такой как память 140 с произвольным доступом (ОЗУ) и/или энергонезависимой памяти, такой как память 138 только для считывания (ПЗУ). Базовая система 142 ввода/вывода (BIOS), содержащая базовые подпрограммы, которые помогают пересылать информацию между элементами в компьютере 130, к примеру, во время запуска, хранится в ПЗУ 138. ОЗУ 140 обычно содержит модули данных и/или программные модули, которые непосредственно доступны процессору 132 и/или которыми этот процессор оперирует в данный момент.

Компьютер 130 может дополнительно включать другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные запоминающие носители. Например, на фиг.1 показан дисковод 144 жестких дисков для считывания и записи на несъемный, энергонезависимый магнитный носитель (не показан; обычно называемый «жестким диском»), накопитель 146 на магнитном диске для считывания и записи на съемный энергонезависимый магнитный диск 148 (например, «гибкий диск») и накопитель 150 на оптическом диске для считывания или записи на съемный энергонезависимый оптический диск 152, такой как ПЗУ на компакт-диске для считывания/считывания и записи (CD-ROM/R/RW), ПЗУ на цифровом универсальном диске для считывания/считывания и записи + ОЗУ (DVD-ROM/R/RW+R/RAM) либо другие оптические носители. Накопитель 144 на жестком диске, накопитель 146 на магнитном диске и накопитель 150 на оптическом диске подсоединены к шине 136 через один или несколько интерфейсов 154.

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

На жестком диске, магнитном диске 148, оптическом диске 152, ПЗУ 138 или ОЗУ 140 может храниться несколько программных модулей, в том числе, к примеру, операционная система 158, одна или несколько прикладных программ 160, другие программные модули и программные данные 164.

Описанные здесь улучшенные способы и системы можно реализовать в операционной системе 158, одной или нескольких прикладных программах 160, других программных модулях 162 и/или программных данных 164.

Пользователь может подавать команды и информацию в компьютер 130 через устройства ввода, такие как клавиатура 166 и указательное устройство 168 (такое как «мышь»). Другие устройства ввода (не показаны) могут включать микрофон, джойстик, игровую клавиатуру, спутниковую тарелку, последовательный порт, сканер, камеру и т.д. Эти и другие устройства ввода подсоединяют к блоку 132 обработки данных через пользовательский интерфейс 170 ввода данных, который соединен с шиной 136, но их также можно подсоединить через другие интерфейсные и шинные структуры, такие как параллельный порт, игровой порт или универсальную последовательную шину (USB).

К шине 136 через интерфейс, такой как видеоадаптер 174, также подсоединен монитор 172 либо устройство отображения другого типа. Помимо монитора 172 персональные компьютеры обычно включают другие периферийные устройства вывода (не показаны), такие как динамики и принтеры, которые можно подсоединить через интерфейс 175 периферийных устройств ввода.

Компьютер 130 может работать в сетевой среде, используя логические соединения с одним или несколькими удаленными компьютерами, такими как удаленный компьютер 182. Удаленный компьютер 182 может содержать многие либо все элементы и функции, описанные здесь применительно к компьютеру 130.

Логические соединения, показанные на фиг. 1, представляют собой локальную сеть (LAN) 177 и глобальную сеть (WAN) 179. Такие сетевые среды - обычное явление в офисах, корпоративных компьютерных сетях, интрасетях (Intranet) и сети Интернет.

При использовании в сетевой среде LAN компьютер 130 соединен с LAN 177 через сетевой интерфейс или адаптер 186. При использовании в сетевой среде WAN компьютер обычно содержит модем 178 либо другое средство для установления связи через сеть WAN 179. Модем 178, который может быть встроенным или внешним, можно подсоединить к системной шине 136 через пользовательский интерфейс 170 ввода данных либо другой соответствующий механизм.

На фиг. 1 изображен конкретный вариант реализации WAN через Интернет. Здесь компьютер 130 использует модем 178 для установления связи по меньшей мере с одним удаленным компьютером 182 через Интернет 180.

В сетевой среде программные модули, изображенные относящимися к компьютеру 130, или их части могут храниться в удаленном запоминающем устройстве. Так, например, как показано на фиг.1, удаленные прикладные программы 189 могут находиться в запоминающем устройстве удаленного компьютера 182. Очевидно, что сетевые соединения показаны и описаны здесь в качестве примеров, и можно использовать другие средства установления линии связи между компьютерами.

Сущность типовых способов делегирования S4U2Proxy и S4U2Self

Далее кратко описываются конкретные способы управления объемом делегирования полномочий по аутентификации в сетевой среде «клиент-сервер». В данном примере описывается система на основе стандарта Kerberos. Эти способы S4U2Proxy и S4U2Self и описанные далее способы авторизации могут быть либо могут не быть реализованы в одних и тех же системах, а также могут быть реализованы в других системах аутентификации на основе сертификатов.

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

На этой основе в патентной заявке США №09/886146 описываются способы и системы для ограничения или, иными словами, улучшенного управления процессом делегирования. Управление процессом делегирования можно осуществлять, используя способ «сервис для пользователя - модуль-посредник» (S4U2proxy), который позволяет серверу или сервису, такому как, например, входной сервер/сервис, запрашивать мандаты на сервис от имени клиента для использования с другими серверами/сервисами. Протокол s4u2proxy преимущественно обеспечивает управляемое ограниченное делегирование, при котором клиенту не требуется направлять TGT на интерфейсный сервер. Другим способом является протокол «сервис для пользователя - на себя» (s4u2self), который позволяет серверу запрашивать у себя мандат на сервис, но при этом в результирующем мандате на сервис обеспечены данные идентификации клиента. Это, например, позволяет клиенту, который был аутентифицирован по другим протоколам аутентификации, получить мандат на сервис, который можно использовать с протоколом s4u2proxy для обеспечения ограниченного делегирования. Имеются две типовые формы к протоколу s4u2self, а именно форма «без доказательства» и форма «доказательство». При использовании формы «без доказательства» серверу доверяется аутентификация клиента, например, с использованием другого механизма защиты/аутентификации, который является собственным механизмом данного сервера. При использовании формы «доказательство» KDC (или доверенная третья сторона) выполняет аутентификацию на основе информации (доказательства) о клиенте, полученной, когда клиент аутентифицировался на сервере.

Таким образом, клиент может получить доступ к серверам/сервисам в среде Kerberos

независимо от того, был ли клиент аутентифицирован согласно протоколу Kerberos или какому-нибудь другому протоколу аутентификации. Следовательно, оконечные и/или другие серверы/сервисы могут работать, по существу, только в среде Kerberos.

На фиг. 2 изображен протокол/процесс S4U2proxy в среде «клиент-сервер» 200. Как показано на этом чертеже, клиент 202 оперативно связан с доверенной третьей стороной 204, имеющей сервис аутентификации 206, например KDC, полномочия выдачи сертификата, контроллер домена и/или т.п. Сервис аутентификации 206 конфигурирован для доступа к информации, поддерживаемой в базе данных 208. Клиент 202 и доверенная третья сторона 204, кроме того, оперативно связаны с сервером, а именно с сервером А 210. Заметим, что используемые здесь термины «сервер» и «сервис» используется здесь взаимозаменяемо для представления одинаковых или подобных функций.

В данном примере сервер А210 представляет собой интерфейсный сервер для множества других серверов. Как изображено на фиг.2, сервер А 210 оперативно связан с сервером В 212 и сервером С 214. Как видно из фиг. 2, сервер В 212 может представлять тиражируемый сервис. Также сервер С 214 дополнительно оперативно связан с сервером D 216.

В ответ на регистрацию пользователя у клиента 202 к сервису аутентификации 206 посылается сообщение 220 с запросом на аутентификацию (AS_REQ), в ответ на которое формируется сообщение 222 об аутентификации (AS_REP). В сообщении AS_REP 222 имеется мандат TGT, связанный с пользователем/клиентом. Такая же или аналогичная процедура (не показана) производится затем для аутентификации сервера А 210.

Когда клиент 202 хочет получить доступ к серверу А 210, он посылает сообщение 224 запроса на сервис предоставления мандата (TGS_REQ) на сервис аутентификации 206, который посылает обратно сообщение 226 ответа о сервисе предоставления мандата (TGS_REP). Сообщение TGS_REP 226 включает мандат сервиса, связанный с клиентом 202 и сервером А 210. Затем для инициирования сеанса связи клиент 202 направляет на сервер А 210 мандат на сервис в сообщении 228 с запросом прикладного протокола (AP_REQ). Указанные процессы/процедуры хорошо известны, и поэтому подробно здесь не описываются.

В некоторых системах для поддержания делегирования клиенту необходимо предоставить серверу А 210 свой TGT, чтобы дать возможность серверу А 210 запросить дополнительные мандаты на сервисы от имени клиента 202. В этом нет необходимости при использовании протокола S4U2proxy. Вместо этого, когда серверу А 210 необходимо обратиться к другому серверу от имени клиента 202, например, к серверу С 214, тогда сервер А 210 и сервис по аутентификации 206 действуют в соответствии с протоколом S4U2proxy.

Сервер А 210 посылает сообщение TGS_REQ 230 на сервис аутентификации 206. Сообщение TGS_REQ 230 включает мандат TGT для сервера А 210 и мандат на сервис, полученный от клиента 202, и идентифицирует требуемый или целевой сервер/сервис, к которому клиент 202 хочет обратиться, например сервер C 214. В протоколе Kerberos имеется, например, определенное расширяемое поле данных, которое обычно называют полем «дополнительных мандатов». Это поле дополнительных мандатов можно использовать в протоколе S4U2proxy для переноса мандата на сервис, полученного от клиента 202, а поле опций KDC может включать флаг или другой индикатор, который дает указание принимающему KDC найти в поле дополнительных мандатов мандат, используемый для предоставления данных идентификации клиента. Специалистам в данной области техники очевидно, что для переноса необходимой информации для сервиса аутентификации 206 можно использовать эти либо другие поля и/или структуры данных.

При обработке TGS_REQ 230 сервис аутентификации 206 определяет, авторизовал ли клиент 202 делегирование, например, на основе значения «пересылаемого флага», установленного клиентом 202. Таким образом, делегирование по каждому клиенту приводится в исполнение при наличии пересылаемого флага в мандате сервиса клиента. Если клиент 202 не хочет принимать участие в делегировании, то тогда в мандате пересылаемый флаг не устанавливается. Сервис аутентификации 206 учитывает этот флаг в виде ограничения, инициированного клиентом. Сервис аутентификации 206 может получить доступ к дополнительной информации в базе данных 208, определяющей выбранные сервисы, которые разрешено делегировать (или не делегировать) серверу А 210 в отношении клиента 202.

Если сервис аутентификации 206 определяет, что серверу А 210 разрешено делегировать полномочия целевому серверу/сервису, то тогда на сервер А 210 посылается сообщение TGS_REP 232. Сообщение TGS_REP 232 включает мандат сервиса для целевого сервера/сервиса. Этот мандат сервиса появляется так, как будто клиент 202 запросил его непосредственно от сервиса аутентификации 206, например, используя TGT клиента. Однако на самом деле это не делается. Вместо этого сервис аутентификации 206 обратился к аналогичной/необходимой информации о клиенте в базе данных 208 после подтверждения того, что аутентифицированный клиент фактически включен в запрос на основе мандата сервиса, который аутентифицировал сервер А 210, полученного от клиента 202, и включен в сообщение TGS_REQ 230. Однако, поскольку в мандате клиента есть информация о клиенте, серверу необходимо лишь скопировать необходимые данные из этого мандата.

В некоторых вариантах реализации сообщение TGS_REP 232 идентифицирует целевой сервер/сервис и клиента 202 и дополнительно включает данные учетной записи об идентификации/пользователя/клиента для конкретной реализации, например в виде сертификата атрибута привилегий (PAC), идентификатора защиты, ID операционной системы UNIX, ID системы Passport, сертификата и т.д. Сертификат PAC может быть сформирован, например, сервисом аутентификации 206 либо просто скопирован из мандата сервиса клиента, который был включен в сообщение TGS_REQ 230. Использование идентификатора Passport ID дополнительно описывается в типовых схемах формирования контекста аутентификации, представленных ниже.

Сертификат PAC либо другие учетные данные пользователя/клиента также могут быть конфигурированы для включения информации, относящейся к объему делегирования. Так, например, на фиг. 4 представлена диаграмма, иллюстрирующая выбранные части сообщения Kerberos 400, имеющего заголовок 402 и PAC 404. Здесь сертификат PAC 404 включает информацию о делегировании 406. Как показано на фиг. 4, информация о делегировании 406 включает составную информацию идентификации 408 и информацию ограничения доступа 410.

Составная информация идентификации 408 может, например, включать записанную информацию о процессе делегирования, например, индикацию того, что сервер А 210 запросил мандат сервиса от лица пользователя/клиента 202. Здесь может быть предусмотрено множество таких записанных данных, которые можно использовать для связывания или идентификации иным образом архивных данных по множеству процессов делегирования. Указанная информация может быть полезной для контроля и/или управления доступом.

Информацию ограничения доступа 410 можно использовать, например, вместе с механизмом управления доступом для избирательного разрешения доступа к конкретным серверам/сервисам, при условии, если клиент 202 прямо либо косвенно ищет доступ к данному серверу/сервису через сервер А 210, но нельзя использовать, если поиск сервера/сервиса ведется косвенно через сервер B 212. Указанная особенность предоставляет дополнительные возможности управления процессом делегирования полномочий на аутентификацию.

В вышеуказанных примерах клиент 202 был аутентифицирован с помощью сервиса аутентификации 206. Однако понятно, что другие клиенты не могут быть аутентифицированы подобным образом. Пример такой ситуации показан на фиг. 3А. Здесь клиент 302 был аутентифицирован с использованием механизма 303 другого протокола аутентификации. Механизм 303 протокола аутентификации может, например, включать систему Passport, протокол защищенных разъемов (протокол SSL), протокол NTLM, протокол Digest либо другие подобные протоколы/процедуры аутентификации. В данном примере предполагает