КОНТЕКСТ УСТОЙЧИВОЙ АВТОРИЗАЦИИ НА ОСНОВЕ ВНЕШНЕЙ АУТЕНТИФИКАЦИИ Российский патент 2008 года по МПК G06F21/20 

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

Настоящая патентная заявка связана с патентной заявкой США №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). Такое неограниченное делегирование поддерживается в настоящее время в некоторых вариантах реализации стандарта Kerberos, где имеются схемы направленного делегирования мандатов.

На этой основе в патентной заявке США №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 представляет собой интерфейсный сервер для множества других серверов. Как изображено на чертеже, сервер А 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 либо другие подобные протоколы/процедуры аутентификации. В данном примере предполагается, что клиент 302 выбирает доступ к целевому сервису, который обеспечен сервером С 214. Этот выбор может быть удовлетворен путем использования вышеописанного протокола S4U2proxy, но только после того, как сервер А 210 завершил/отследил до конца протокол/процедуру S4U2self.

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

При отсутствии доказательства для аутентификации, которое может быть оценено сервисом аутентификации 206, серверу А 210 придется обратиться к «доверенному» клиенту 302. Так например, если клиент 302 имеет сертификат аутентификации либо подобный механизм 304, который сервер А 210 способен проверить, то тогда клиент 302 может быть определен как «доверенный клиент». Следовательно, клиент 302 фактически аутентифицируется сервером А 210.

Далее сервер А 210 посылает сообщение TGS_REQ 306 на сервис аутентификации 206, запрашивая у себя мандат сервиса для клиента 302. В ответ на это сервис аутентификации 206 формирует сообщение TGS_REP 308, которое включает мандат запрашиваемого сервиса. Затем полученный мандат сервиса используют в последующем протоколе/процедуре S4U2proxy для запроса мандата сервиса у сервера С 214 для клиента 302. В некоторых вариантах реализации протокола Kerberos это потребует, например, установления в сообщении TGS_REP 308 пересылаемого флага, позволяющего переслать мандат сервиса. Доверенная третья сторона может также создать сертификат PAC для клиента 302, который может быть затем включен в итоговый мандат сервиса.

Если для клиента 302' имеется доказательство для аутентификации, то тогда сервер А 210 может включить указанное доказательство в сообщение TGS_REQ 312 в виде дополнительных данных для предварительной аутентификации. Это показано на фиг.3B в среде 300'. Здесь информация доказательства 310 подается клиентом 302' на сервер А 210. Информация доказательства 310 может включать, например, данные диалога «запрос/ответ» или другую информацию, формируемую другим «доверенным» объектом. После приема информации доказательства и последующей проверки, сервис аутентификации 206 сам предоставит запрошенный мандат сервиса серверу А 210. Заметим, что в некоторых вариантах реализации при использовании доказательства для сервера возможно получение ограниченного TGT для данного клиента.

В некоторых вариантах реализаций протокола Kerberos пересылаемый флаг в сообщении TGS_REP 314 устанавливается, чтобы позволить переслать мандат сервиса. Если в сообщении TGS_REQ 312 был предусмотрен сертификат PAC, то тогда его можно использовать в мандате сервиса; в противном случае, PAC может быть сформирован сервисом аутентификации 206 (здесь KDC) на основе информации доказательства 310. Например, в стандарте S4U2self данные идентификации клиента включают в данные предварительной аутентификации. Эти данные идентификации можно использовать при создании сертификата PAC для клиента и добавить в созданный мандат сервиса для сервера (для клиента).

Типовые способы формирования контекста авторизации

Далее описываются типовые способы и системы согласно конкретным вариантам реализации настоящего изобретения. Эти способы и системы могут быть реализованы с использованием или без использования протоколов S4U2proxy и/или S4U2self. Эти способы и системы можно реализовать с использованием или без использования стандарта Kerberos. Также эти способы и системы могут быть реализованы с использованием или без использования сервисной системы Passport (предоставляемой Microsoft Corp.Of Redmond WA). Специалистам в данной области техники понятно, что эти способы можно реализовать, используя многочисленные другие протоколы и/или сервисы. Тем не менее, в этих примерах предполагается, что указанные протоколы и сервисы доступны для поддержки способов формирования контекста авторизации, если это необходимо.

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

Как показано на фиг.5, сервер Х 502 оперативно связан с сервером Y 504, первым клиентом 506, связанным с пользователем #1 (U1), и вторым клиентом 508, связанным с пользователем #2 (U2). В этом примере между указанными устройствами имеется ряд доверительных отношений, которые представлены блоками 510, 512 и 514, изображенными пунктирными линиями. Так клиент 506 и сервер Х 502 конфигурированы для формирования доверительных отношений 510, когда U1 регистрируется у клиента 506 и сервера Х 502, например, для доступа к ресурсу, предлагаемому сервером Х 502, такому как объект 516. Указанная процедура регистрации может включать аутентификацию и управление доступом. Аналогично клиент 508 и сервер Y 504 конфигурируются для формирования доверительных отношений 512, когда U2 регистрируется у клиента 508 и сервера Y 504. Кроме того, в этом примере сервер Х 502 и сервер Y 504 способны формировать доверительные отношения 514 через доверенную третью сторону 204. Заметим, однако, что в этот момент между клиентом 508 и сервером Х 502 нет доверительных отношений. Ниже с использованием фиг.5 и фиг.6 описан процесс, иллюстрирующий некоторые аспекты настоящего изобретения, которые позволяют клиенту 508 иметь контекст авторизации с сервером Х 502, что позволяет U2 получить доступ к объекту 516. Стрелки к последующим числовым идентификаторам в маленьких кружках иллюстрируют действия в указанном процессе. В других вариантах реализации порядок следования этих действий может быть другим.

Действие #0 - это создание доверительных отношений 510, 512 и 514, описанных выше. Указанные доверительные отношения могут быть созданы избирательно, когда это необходимо для конкретных операций.

В данном примере предполагается, что U1 хочет разрешить U2 получить доступ к объекту 516. Хотя U1 авторизован посредством доверительных отношений 510 для доступа к объекту 516, U2 в то же время не авторизован для доступа к объекту 516. Кроме того, имеется дополнительная потребность избежать добавления U2 в качестве другого авторизованного пользователя в систему управления доступом сервера Х 502. Такая ситуация может возникнуть, например, когда U1 хочет разрешить U2 получить доступ к календарю онлайнового планирования U1, который размещается или иным образом обеспечивается через работодателя U1. Здесь работодатель не хочет добавлять в свою систему учетную запись нового авторизованного пользователя.

На фиг.6 представлена блок-схема 600, иллюстрирующая некоторые характерные признаки, связанные с графическим интерфейсом пользователя (GUI), предоставляемым пользователю U1 через клиента 506. В данном примере для U1 после регистрации на сервере Х 502 отображается Web-страница 602 или аналогичный экран. На Web-странице 602 объект 516 представляет календарь GUI 604, который отображает информацию о пользователе U1. Пользователь U1 имеет возможность открыть бланк ввода информации 606, который включает поле 608 ввода идентификатора и (как опцию) одну или несколько выбираемых настроек разрешения 610. Именно здесь пользователь U1 может инициировать процесс, который в итоге позволит U2 получить доступ к объекту 516.

Пользователь U1 вводит идентификатор для пользователя U2. В этом примере идентификатор включает уникальный адрес электронной почты WWW (всемирной паутины) для U2, а именно user2@hotmail.com. Введенный здесь идентификатор предназначен для зарегистрированного пользователя сервисов hotmail.com, предоставляемых Microsoft Corp. Так как предполагается, что зарегистрированный пользователь hotmail.com U2 также имеет соответствующую учетную запись Passport от Microsoft Corp., пользователь U1 может также определить одну или несколько настроек разрешения 610 для пользователя U2, относящихся к доступу, получаемому к объекту 516 (здесь, например, это приложение, относящееся к календарю онлайнового планирования). В данный момент пользователь U1 установил разрешение для U2 на считывание. Вернемся теперь к фиг.5, где процесс идентификации пользователя представлен в виде действия #1 между клиентом 506 и сервером Х 502.

Сервер Х 502 распознает, что пользователь U1 предоставил идентификатор hotmail.com для пользователя U2, а при действии #2 осуществляет связь с сервером Y 504, относительно которого в этом случае предполагается, что он представляет собой известный сервер Passport. Здесь сервер X 502 предоставляет идентификатор user2@hotmail.com серверу Y 504 и запрашивает, чтобы сервер Y 504 предоставил соответствующие универсальные уникальные данные идентификации пользователя Passport (PUID) (также часто называемые уникальным парным ID). При действии #3 сервер Y 504 выдает в ответ идентификатор PUID (524) для U2. Если доверительные отношения являются доверительными отношениями по протоколу Kerberos, то тогда идентификатор PUID может быть выдан, например, в сертификате PAC, как упоминалось ранее.

Теперь сервер Х 502 имеет идентификатор PUID для пользователя U2. При действии #4 сервер Х 502 преобразует PUID в соответствующий идентификатор SID 522, подходящий для использования с собственной системой аутентификации сервера Х 502. Как показано на фиг.5, объект 516 связан со списком ACL 518, имеющим по меньшей мере одну запись ACE 520, которая включает идентификатор SID 522.

64-разрядный идентификатор PUID в действительности состоит из 16-разрядного идентификатора полномочий домена Passport и 48-разрядного идентификатора-члена. Для образования идентификатора SID необходимо поддерживать полномочия домена в виде отдельного значения. Чтобы это сделать, идентификатор MemberIDHigh разделяется на две части, а затем эти части формируются в виде отдельных субполномочий, например, как показано ниже:

S-1-10-21-(HIWORD(MemberIDHigh))-(LOWORD(MemberIDHigh))-MemberIDLow-0

В этом примере «S-1-10-21» - это полномочия нового идентификатора, определенные файлом ntseapi.h. В этом типовом варианте реализации ntseapi.h - это файл заголовка, используемый для построения операционной системы Microsoft® Windows®, которая содержит описание для значения идентификатора SID, используемого для построения PUID-SID. Заметим, что этот заголовок обычно непосредственно не раскрывается разработчиками. Однако декларации в файле ntseapi.h открыто опубликованы в Платформе SDK в winnt.h.

Таким образом типовой идентификатор SID, который создается из идентификатора PUID либо другого подобного идентификатора, выдаваемого «доверенным» источником, по существу идентифицирует известные субполномочия и пользователя-члена в уникальной комбинации и формате, совместимом с собственной системой авторизации.

При действии #5 пользователь U2 регистрируется (или аутентифицируется) на сервере Y 504 и в процессе регистрации получает идентификатор PUID 524. При действии #6 пользователь U2 соединяется с сервером X 502, используя учетную запись пользователя, установленную по умолчанию (например, "неизвестен" или "аноним") и предоставляет информацию (например, в сертификате РАС), включающую идентификатор PUID 524, в запросе или другом подобном сообщении. При действии #7 сервер X 502 распознает, что идентификатор PUID был предоставлен этим пользователем, определенным по умолчанию (U2), и создает в ответ соответствующий идентификатор SID 532, который затем помещают в мандат 530, связанный с тем пользователем по умолчанию (U2), которому нужен доступ к объекту 516. В некоторых вариантах реализации идентификатор SID формируется путем подачи идентификатора PUID в интерфейс прикладного программирования (API), называемый LsaLogonUser. Этот интерфейс API выдает идентификатор SID.

При действии #8 сервер Х 502 определяет, имеет ли пользователь по умолчанию (U2) соответствующее разрешение (разрешения) на доступ к объектам 516, путем сравнения одного или нескольких идентификаторов SID в мандате 530 пользователя по умолчанию с идентификаторами в ACL 518. Здесь идентификатор SID 532 из мандата 530 совпадает с идентификатором SID 522 в записи ACE 520. После этого при действии #9 создается контекст аутентификации 526 для пользователя U2, который позволяет пользователю U2 получить доступ к объекту 516 в соответствии с применяемыми настройками разрешения. Таким образом, пользователь U2 может, например, просматривать (считывать) календарь планирования U1 и определить, могут ли пользователь U1 и пользователь U2 позавтракать вместе на следующей неделе. Пользователь U2 не зарегистрировался на сервере Х 502; в действительности пользователь U2 не может зарегистрироваться на сервере Х 502, поскольку в отличие от пользователя U1 пользователь U2 не имеет учетной записи. В этом случае аутентификация пользователя U2 по существу основана на доверительных отношениях 510, 512 и 514 и начальной аутентификации U2, с использованием клиента 508 и сервера Y 504. Управление доступом пользователя U2 к серверу X 502 предоставляется, по существу, на основе доверительной авторизации U1 (через клиента 506 и сервер Х 502 при действии #0) и доверительных отношениях с сервером Y 504 при предоставлении идентификатора PUID 524 в процессе выполнения действия #3.

Одно из преимуществ, связанное с использованием идентификатора PUID, состоит в том, что результирующий идентификатор SID получится уникальным (в глобальном смысле) и устойчивым на основе контролируемого присвоения идентификаторов PUID, выполняемого системой Passport.

Заключение

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

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

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

преобразование идентификатора PUID в идентификатор защиты (SID) путем подачи идентификатора PUID в интерфейс прикладного программирования (API) и приема в ответ идентификатора SID API;

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

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

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

прием уникального идентификатора, выданного доверенным сервисом;

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

преобразование идентификатора (PUID) в идентификатор защиты (SID) путем подачи идентификатора PUID в интерфейс прикладного программирования (API) и приема в ответ идентификатора SID от интерфейса API;

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

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

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

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

прием уникального идентификатора, выданного доверенным сервисом; и

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

прием идентификатора PUID;

разделение идентификатора PUID на по меньшей мере одну часть, соответствующую идентификатору субполномочий, и по меньшей мере одну часть, соответствующую идентификатору члена; и

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

37 Способ по п.35, дополнительно содержащий выдачу идентификатора SID.

память,

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

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