close

Вход

Забыли?

вход по аккаунту

?

Патент РФ 2337399

код для вставки
РОССИЙСКАЯ ФЕДЕРАЦИЯ
(19)
RU
(11)
2 337 399
(13)
C2
(51) МПК
G06F 21/20
(2006.01)
ФЕДЕРАЛЬНАЯ СЛУЖБА
ПО ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТИ,
ПАТЕНТАМ И ТОВАРНЫМ ЗНАКАМ
(12)
ОПИСАНИЕ ИЗОБРЕТЕНИЯ К ПАТЕНТУ
(21), (22) За вка: 2003113549/09, 08.05.2003
(24) Дата начала отсчета срока действи патента:
08.05.2003
(30) Конвенционный приоритет:
10.05.2002 US 10/144,059
(43) Дата публикации за вки: 10.11.2004
(56) Список документов, цитированных в отчете о
поиске: JP 6119392, 28.04.1994. RU 2120190 С1,
10.10.1998. US 5469556 А, 21.11.1995. WO
99/54817 A1, 28.10.1999. WO 01/84841 A1,
08.11.2001. US 2002040451, 04.04.2002. US
2001014892 A, 16.08.2001.
(57) Реферат:
Изобретение относитс к средствам управлени компьютерным
доступом
с
возможностью
аутентификации
пользовател доверенным
внешним сервисом. Техническим результатом
вл етс обеспечение получени контролируемых
уровней доступа к выбранным объектам без
требовани дополнительной учетной записи
пользовател . Способ включает преобразование
уникального идентификатора в идентификатор
защиты SID, который подходит дл использовани с механизмом управлени доступом, защищающий
вычислительный ресурс, без необходимости дл пользовател дополнительно иметь стандартные
возможности дл управлени доступом дл указанных ресурсов. 8 н. и 49 з.п. ф-лы, 7 ил.
R U
2 3 3 7 3 9 9
(54) КОНТЕКСТ УСТОЙЧИВОЙ АВТОРИЗАЦИИ НА ОСНОВЕ ВНЕШНЕЙ АУТЕНТИФИКАЦИИ
Страница: 1
RU
C 2
C 2
Адрес дл переписки:
129010, Москва, ул. Б. Спасска , 25, стр.3,
ООО "Юридическа фирма Городисский и
Партнеры", пат.пов. Ю.Д.Кузнецову, рег.№ 595
2 3 3 7 3 9 9
(73) Патентообладатель(и):
МАЙКРОСОФТ КОРПОРЕЙШН (US)
(45) Опубликовано: 27.10.2008 Бюл. № 30
R U
(72) Автор(ы):
МАУЭРС Дэвид Р. (US),
ДУБРОВКИН Дэниэл (US),
ЛЕЙБЭН Рой (US),
ШМИДТ Дональд И. (US),
ВИСВАНАТАН Рэм (US),
БРЕЗАК Джон И. (US),
УОРД Ричард Б. (US)
C 2
C 2
2 3 3 7 3 9 9
2 3 3 7 3 9 9
R U
R U
Страница: 2
RUSSIAN FEDERATION
RU
(19)
(11)
2 337 399
(13)
C2
(51) Int. Cl.
G06F 21/20
(2006.01)
FEDERAL SERVICE
FOR INTELLECTUAL PROPERTY,
PATENTS AND TRADEMARKS
(12)
ABSTRACT OF INVENTION
(21), (22) Application: 2003113549/09, 08.05.2003
(24) Effective date for property rights: 08.05.2003
(30) Priority:
10.05.2002 US 10/144,059
(43) Application published: 10.11.2004
(45) Date of publication: 27.10.2008 Bull. 30
(73) Proprietor(s):
MAJKROSOFT KORPOREJShN (US)
2 3 3 7 3 9 9
R U
(57) Abstract:
FIELD: physics, computation equipment.
SUBSTANCE: method involves unique ID
conversion into security ID (SID) suitable for
application in access control unit and protecting
computation
resource,
without
necessity
of
additional standard user facilities for access
control of given resources.
EFFECT: obtaining controlled access levels to
selected objects without necessity of additional
user account.
57 cl, 7 dwg
Страница: 3
EN
C 2
C 2
(54) STABLE AUTHORISATION CONTEXT BASED ON EXTERNAL IDENTIFICATION
2 3 3 7 3 9 9
Mail address:
129010, Moskva, ul. B. Spasskaja, 25, str.3,
OOO "Juridicheskaja firma Gorodisskij i
Partnery", pat.pov. Ju.D.Kuznetsovu, reg.№ 595
R U
(72) Inventor(s):
MAUEhRS Dehvid R. (US),
DUBROVKIN Dehniehl (US),
LEJBEhN Roj (US),
ShMIDT Donal'd I. (US),
VISVANATAN Rehm (US),
BREZAK Dzhon I. (US),
UORD Richard B. (US)
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
Родственные патентные за вки
Насто ща патентна за вка св зана с патентной за вкой США №09/886146 на
«Способы и системы дл управлени объемом делегировани полномочий
аутентификации», поданной 20 июн 2001 года и котора включена в насто щее описание
посредством ссылки.
Область техники
Данное изобретение в целом относитс к управлению компьютерным доступом и, в
частности, касаетс способов и систем, обеспечивающих контекст локальной системной
авторизации дл пользовател на основе внешней аутентификации пользовател .
Уровень техники
Управление доступом вл етс первостепенным вопросом компьютерной защиты. Дл защиты целостности компьютерных систем и конфиденциальности важных данных были
реализованы различные схемы управлени доступом, которые не позвол ют
неавторизованным пользовател м и злонамеренным нарушител м получать доступ к
компьютерным ресурсам.
Дл того чтобы гарантировать всестороннюю компьютерную защиту, управление
доступом часто реализуют на разных уровн х. Например, на уровне одного компьютера
пользователю обычно необходимо пройти через процедуру регистрации, при которой
компьютер определ ет, уполномочен ли пользователь использовать данный компьютер. На
уровне компьютерной сети пользователю, как правило, необходимо пройти через процесс
аутентификации пользовател в цел х управлени доступом пользовател к различным
сетевым услугам. Даже после того, как сервер управлени сетевым доступом
аутентифицировал пользовател , пользователю возможно еще понадобитс получить
разрешение на доступ к услуге у конкретного сервера. Дл управлени сетевым доступом
на основе аутентификации пользовател были предложены и реализованы различные
схемы на основе разных протоколов, таких как протокол Kerberos 5.
Обычно регистраци пользовател в компьютере и аутентификаци пользовател дл управлени сетевым доступом представл ют собой две отдельные процедуры. Тем не
менее, чтобы минимизировать трудности пользовател при реализации различных схем
управлени доступом, регистрацию пользовател и аутентификацию пользовател дл сетевого доступа иногда выполн ют вместе. Например, в случае, когда аутентификаци пользовател реализуетс согласно протоколу Kerberos, когда пользователь
регистрируетс в компьютере, компьютер также может инициировать процесс
аутентификации Kerberos. В процессе аутентификации Kerberos компьютер устанавливает
св зь с центром распределени ключей Kerberos (KDC), чтобы сначала получить мандат на
получение разрешени (TGT) дл пользовател . Затем компьютер может использовать
TGT дл получени дл себ от KDC мандата на сеанс.
В процессе своей эволюции сети обросли множеством русов, состо щих из
компьютеров-серверов/сервисов, расположенных таким образом, чтобы обеспечить
обработку запросов клиентских компьютеров. Простым примером этого вл етс клиентский компьютер, запрашивающий Web-сайт Всемирной паутины через Интернет.
Здесь может иметьс входной (клиентский) web-сервер, который обрабатывает
форматирование и соответствующий деловой регламент запроса, и оконечный сервер
(сервер базы данных), который управл ет базой данных дл Web-сайта. Дл дополнительной защиты Web-сайт может быть конфигурирован таким образом, что
протокол аутентификации направл ет (или делегирует) полномочи ("верительные
данные"), такие как, например, TGT пользовател , и/или, возможно, другую информацию
от клиентского сервера на оконечный сервер. Така практика находит все большее
распространение на многих Web-сайтах и/или в других много русных сет х.
Делегирование и другие аналогичные способы полезны тогда, когда все
серверы/сервисы и клиент согласны использовать один и тот же процесс аутентификации.
Однако на сегодн шний день используетс не один процесс аутентификации. В совместно
рассматриваемой патентной за вке США №09/886146 предлагаетс усовершенствованный
Страница: 4
DE
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
процесс управлени делегированием.
Если пользователь аутентифицирован дл работы в сети/системе, то тогда дл предотвращени доступа этого пользовател к ресурсам, на доступ к которым у него нет
полномочий, обычно выполн ют одну или несколько дополнительных проверок
авторизации, необходимых дл управлени доступом. Как только пользователь будет
аутентифицирован и пройдет необходимые проверки дл управлени доступом, этот
пользователь объ вл етс «авторизованным». В некоторых системах управление доступом
основано, например, на списках управлени доступом (ACL) дл различных сервисов и
ресурсов (то есть объектов). Список ACL обычно включает записи управлени доступом
(ACE), в которых может быть включено нулевое или большее количество идентификаторов
защиты (SID). Идентификаторы SID могут быть св заны с одним пользователем или
группами пользователей, которым разрешен доступ к данному объекту. Если в списке ACL
нет идентификаторов SID, то тогда ни один пользователь не будет иметь доступ к
данному объекту. Если в списке ACL имеютс идентификаторы SID, то тогда
пользовател м, которые смогут сформировать по меньшей мере один совпадающий SID,
будет разрешен доступ к данному объекту.
Таким образом, когда аутентифицированный пользователь регистрируетс , дл этого
пользовател создаетс контекст аутентификации, например, путем формировани маркера (например, маркера доступа), который св зан с этим пользователем. Маркер
обычно содержит идентификаторы SID, которые св заны с этим пользователем. Например,
маркер пользовател может включать уникальный SID, присвоенный данному
пользователю, плюс групповой SID, присвоенный подразделению предпри ти пользовател . Когда пользователь пытаетс получить доступ к объекту, ACL объекта
сравнивают с маркером пользовател . Если маркер пользовател содержит по меньшей
мере один SID, который совпадает с SID в списке ACL объекта, то тогда
аутентифицированный пользователь получает право доступа к объекту до некоторой
степени. Например, пользователю может быть разрешено считывать или записывать файл,
созданный другими работниками его отдела (то есть другим членом группы).
Такие схемы авторизации обычно очень хорошо работают в системах, где обеспечен
высокий уровень контрол и управлени . Например, компьютерна сеть на уровне
предпри ти в корпорации обычно обеспечивает св зную среду, где пользователи и списки
ACL могут тщательно контролироватьс централизованной и/или распределенной
системой аутентификации и управлени доступом. С другой стороны, дл очень больших
сетей, например сети Интернет, и/или в ином случае, когда сети не вл ютс сильно
св занными, аутентификаци и управление доступом могут быть крайне затруднены
особенно тогда, когда требуетс обслуживать как можно больше пользователей, в том
числе пользователей, у которых нет учетных записей дл локального управлени доступом. Так как тенденци развити программных средств и ресурсов направлена в
сторону сетевых сервисов, в дальнейшем будет возрастать потребность в авторизации
активности пользователей, св занной с указанными сетевыми сервисами.
Следовательно, имеетс потребность в совершенствовании способов и систем
авторизации. Предпочтительным образом, эти способы и системы должны позвол ть
пользовател м, аутентифицированным доверенным внешним ресурсом, получать
некоторый контролируемый уровень доступа к определенным объектам без необходимости
пользователю дополнительно иметь уникальную учетную запись пользовател , св занную
с данным объектом. Кроме того, эти способы и системы не должны существенно ухудшать
возможности наращивани структур, способных обеспечить доступ к объектам дл очень
большого числа пользователей.
Сущность изобретени Предлагаютс улучшенные способы и системы, которые позвол ют пользовател м,
аутентифицированным доверенным внешним ресурсом, получить контролируемые уровни
доступа к выбранным объектам, не требу от пользовател дополнительной уникальной
локальной учетной записи пользовател . Эти способы и системы можно реализовать без
Страница: 5
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
существенного ограничени возможностей наращивани структур компьютерной системы
и/или сети, которые конфигурированы с возможностью обеспечени доступа к различным
ресурсам дл очень большого числа пользователей.
Вышеустановленные и другие требовани могут быть удовлетворены, например, путем
использовани способа обеспечени управлени доступом по меньшей мере к одному
вычислительному ресурсу. Способ включает прием уникального идентификатора, который
св зан с пользователем, которому необходим доступ к вычислительному ресурсу
(ресурсам). Предпочтительно, чтобы этот уникальный идентификатор был сформирован
другим вычислительным ресурсом, который рассматриваетс как доверительный
(надежный) и/или обслуживает, а часто и аутентифицирует пользовател некоторым
образом. Способ включает преобразование полученного уникального идентификатора в
идентификатор защиты (SID), который подходит дл использовани вместе с механизмом
управлени доступом, защищающим вычислительный ресурс (ресурсы). Способ, кроме
того, включает определение того, совпадает ли упом нутый SID по меньшей мере с одним
другим SID, который был ранее запомнен механизмом управлени доступом и св зан с
вычислительным ресурсом (ресурсами). В некоторых примерах реализации этот
уникальный идентификатор включает уникальный парный идентификатор (PUID), такой как,
например, идентификатор, используемый сервисами Passport, предоставл емыми Microsoft
Corp., а механизм управлени доступом использует список управлени доступом (ACL) дл установлени пользователей или групп пользователей, которым разрешен доступ к
вычислительному ресурсу (ресурсам).
Согласно некоторым другим вариантам реализации насто щего изобретени предлагаетс способ установлени разрешений, св занных с управлением доступом по
меньшей мере к одному вычислительному ресурсу. В этом случае способ включает прием
по меньшей мере одного адреса электронной почты (e-mail) по меньшей мере дл одного
пользовател , которому должен быть предоставлен по меньшей мере ограниченный доступ
к вычислительному ресурсу (ресурсам). Например, пользователь, авторизованный с
использованием механизма управлени доступом, может ввести адрес электронной почты
другого пользовател и задать компьютерный ресурс (ресурсы), к которому требуетс доступ, и/или привилегии, которые будет иметь этот другой пользователь при доступе к
компьютерном ресурсу (ресурсам). Способ, кроме того, включает предоставление адреса
электронной почты к доверенному сервису, способному передать обратно уникальный
идентификатор, св занный с пользователем, на основе адреса электронной почты. Способ
включает прием уникального идентификатора с последующей установкой по меньшей мере
одного разрешени дл управлени доступом на основе этого уникального
идентификатора. Это может включать, например, преобразование уникального
идентификатора в SID и св зывание этого SID по меньшей мере с одним списком дл управлени доступом ACL дл данного вычислительного ресурса (ресурсов).
Согласно другим аспектам насто щего изобретени предлагаетс способ дл преобразовани идентификатора PUID в соответствующий идентификатор SID. Этот
способ включает прием идентификатора PUID, разделение его по меньшей мере на одну
часть идентификатора субполномочий и по меньшей мере одну часть идентификаторачлена и компоновку части идентификатора субполномочий и части идентификатора-члена
дл формировани SID.
Также предлагаетс система дл управлени доступом по меньшей мере к одному
вычислительному ресурсу в соответствии с некоторыми вариантами реализации
насто щего изобретени . Система включает логические схемы и пам ть, которые могут
быть конфигурированы дл приема уникального идентификатора, св занного с
пользователем, которому должен быть предоставлен доступ к вычислительному ресурсу
(ресурсам); преобразовани уникального идентификатора в идентификатор защиты (SID); и
определени того, совпадает ли этот идентификатор SID по меньшей мере с одним другим
идентификатором SID, который хранитс в пам ти и св зан с вычислительным ресурсом
(ресурсами).
Страница: 6
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
В качестве примера предлагаютс некоторые системы дл установки разрешений на
управление доступом дл вычислительного ресурса (ресурсов). Одна система включает
сеть св зи, соедин ющую первое устройство по меньшей мере с одним другим
устройством. Первое устройство конфигурировано дл приема адреса электронной почты
по меньшей мере дл одного пользовател , которому должен быть предоставлен по
меньшей мере ограниченный доступ к вычислительному устройству (устройствам);
предоставлени адреса электронной почты другому устройству по сети; приема по сети от
этого другого устройства соответствующего уникального идентификатора, св занного с
адресом электронной почты; и установлени по меньшей мере одного разрешени дл управлени доступом, св занного с вычислительным ресурсом (ресурсами), на основе
уникального идентификатора. Другое устройство конфигурировано дл приема по сети
адреса электронной почты, преобразовани этого адреса электронной почты в уникальный
идентификатор и выдачи по сети уникального идентификатора на первое устройство.
Краткое описание чертежей
Различные способы и системы согласно насто щему изобретению более подробно
описаны в последующем описании, иллюстрируемом чертежами, на которых:
фиг.1 - блок-схема примера компьютерной системы, подход щей дл использовани с
конкретными вариантами реализации насто щего изобретени ;
фиг.2 - блок-схема, иллюстрирующа процесс «сервис дл пользовател - модульпосредник» (S4U2proxy), который реализуетс в среде «клиент - сервер» и подходит дл использовани с конкретными вариантами реализации насто щего изобретени ;
фиг.3А - блок-схема, иллюстрирующа процесс «сервис дл пользовател - на себ »
(S4U2self), который реализуетс в среде «клиент - сервер» и подходит дл использовани с конкретными вариантами реализации насто щего изобретени ;
фиг.3В - блок-схема, иллюстрирующа процесс «сервис дл пользовател - на себ »
(S4U2self), который реализуетс в среде «клиент - сервер» и подходит дл использовани с конкретными вариантами реализации насто щего изобретени ;
фиг.4 - схема, иллюстрирующа выбранные части приведенного в качестве примера
формата сообщени , подход щего дл использовани с конкретными вариантами
реализации насто щего изобретени ;
фиг.5 - блок-схема, иллюстрирующа систему и процесс дл обеспечени управлени локальным доступом дл пользователей, аутентифицированных доверенным ресурсом,
согласно некоторым приведенным в качестве примера вариантам реализации насто щего
изобретени ;
фиг.6 - блок-схема, иллюстрирующа использование системы и процесса, например, как
на фиг.5, позвол ющих пользователю без учетной записи дл управлени локальным
доступом получить доступ к конкретным ресурсам с адекватным уровнем надежности
авторизации согласно конкретным аспектам насто щего изобретени .
Подробное описание изобретени Обзор
Здесь в качестве примера описаны способы и системы, которые можно реализовать при
аутентификации пользователей/ресурсов и/или обеспечении контекста авторизации дл пользователей, пытающихс получить доступ к конкретным ресурсам.
В следующем разделе описываетс пример вычислительной среды. В последующих
разделах кратко описаны типовые технологии S4U2proxy и S4U2self, которые вл ютс предметом совместно рассматриваемой патентной за вки США №09/886146.
Далее описаны и проиллюстрированы на чертежах способы, обеспечивающие новую
схему авторизации, согласно конкретным аспектам насто щего изобретени . Предлагаютс улучшенные способы и системы, которые позвол ют, например, клиентским службам
(например, пользовател м), аутентифицированным доверенным внешним сервисом,
получить контролируемые уровни доступа к выбранным ресурсам локального сервера, не
требу , чтобы клиентский сервис также имел средства управлени локальным доступом.
Как описано ниже, представленные схемы авторизации можно использовать различными
Страница: 7
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
пут ми, чтобы улучшить защиту вычислительных ресурсов и возможность пользователей
получать доступ к сервисам, обеспечиваемым вычислительными ресурсами.
Типова вычислительна среда
Как показано на чертежах, изобретение реализуетс в подход щей вычислительной
среде, причем на чертежах одинаковые ссылочные позиции относ тс к одинаковым
элементам. Хот это не об зательно, изобретение будет описано в общем контексте
команд, выполн емых компьютером, таких как программные модули, выполн емые
персональным компьютером. Обычно программные модули включают подпрограммы,
программы, объекты, компоненты, структуры данных и т.д., которые выполн ют
определенные задачи или реализуют определенные абстрактные типы данных. Кроме того,
специалистам в данной области техники сно, что изобретение можно реализовать на
практике с помощью других конфигураций компьютерных систем, включа , переносные
устройства, многопроцессорные системы, бытовую электронную аппаратуру на базе
микропроцессоров или программируемую бытовую электронную аппаратуру, сетевые
персональные компьютеры, мини-компьютеры, универсальные компьютеры и т.п.
Изобретение можно также реализовать на практике в распределенных вычислительных
средах, где задачи выполн ютс удаленными устройствами обработки данных, которые
св заны через сеть св зи. В распределенной вычислительной среде программные модули
могут находитьс как в локальных, так и удаленных запоминающих устройствах.
На фиг.1 показан пример подход щей вычислительной среды 120, в которой можно
реализовать описанные далее способы и системы.
Типова вычислительна среда 120 вл етс лишь одним из примеров подход щей
вычислительной среды и не ограничивает объем использовани или функциональные
возможности описанных улучшенных способов и систем. Не следует интерпретировать
вычислительную среду 120 как зависимую каким-либо образом или ограниченную
требовани ми, относ щимис к любой компоненте или их комбинации, показанной в
вычислительной среде 120.
Предложенные здесь улучшенные способы и системы делаютс работоспособными
посредством множества других вычислительных сред или конфигураций общего либо
специального назначени . Примеры известных вычислительных систем, сред и/или
конфигураций, которые могут использоватьс дл реализации изобретени , включают, без
каких-либо ограничений, персональные компьютеры, компьютеры-серверы, «тонкие»
клиенты (маломощные сетевые клиенты-терминалы), «толстые» клиенты (рабочие места
на основе ПК), переносные устройства или портативные компьютеры, многопроцессорные
системы, системы на основе микропроцессоров, телевизионные приставки,
программируемую бытовую электронную аппаратуру, сетевые ПК, мини-компьютеры,
универсальные компьютеры, распределенные вычислительные среды, которые включают
любые из вышеперечисленных систем или устройств и т.п.
Как показано на фиг.1, вычислительна среда 120 включает в себ вычислительное
устройство общего назначени в виде компьютера 130. Компоненты компьютера 130 могут
включать один или несколько процессоров или блоков 132 обработки данных, системную
пам ть 134 и шину 136, котора св зывает различные системные компоненты, включа системную пам ть 134, с процессором 132.
Шина 136 представл ет собой шинную структуру одного или нескольких типов, включа шину пам ти или контроллер пам ти, периферийную шину, ускоренный графический порт и
процессор или локальную шину, использующую любую из множества различных шинных
архитектур. Как пример, но не ограничение, указанные архитектуры включают шину ISA
(архитектура шины промышленного стандарта), шину MCA (микроканальна архитектура),
шину EISA (расширенна архитектура ISA), локальную шину VESA (стандарт
высокоскоростной локальной видеошины), и шину PCI (межсоединение периферийных
компонентов), известную также как шина Mezzanine.
Компьютер 130 обычно содержит различные машинно-считываемые носители. Такими
носител ми могут быть любые имеющиес в наличии носители, доступные компьютеру 130,
Страница: 8
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
к которым относ тс как энергозависимые, так и энергонезависимые носители, съемные и
несъемные носители.
На фиг.1 системна пам ть 134 включает в себ машинно-считываемый носитель в виде
энергозависимой пам ти, такой как пам ть 140 с произвольным доступом (ОЗУ) и/или
энергонезависимой пам ти, такой как пам ть 138 только дл считывани (ПЗУ). Базова система 142 ввода/вывода (BIOS), содержаща базовые подпрограммы, которые помогают
пересылать информацию между элементами в компьютере 130, к примеру, во врем запуска, хранитс в ПЗУ 138. ОЗУ 140 обычно содержит модули данных и/или программные
модули, которые непосредственно доступны процессору 132 и/или которыми этот
процессор оперирует в данный момент.
Компьютер 130 может дополнительно включать другие съемные/несъемные,
энергозависимые/энергонезависимые компьютерные запоминающие носители. Например,
на фиг.1 показан дисковод 144 жестких дисков дл считывани и записи на несъемный,
энергонезависимый магнитный носитель (не показан; обычно называемый «жестким
диском»), накопитель 146 на магнитном диске дл считывани и записи на съемный
энергонезависимый магнитный диск 148 (например, «гибкий диск») и накопитель 150 на
оптическом диске дл считывани или записи на съемный энергонезависимый оптический
диск 152, такой как ПЗУ на компакт-диске дл считывани /считывани и записи (CDROM/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.
Страница: 9
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
Удаленный компьютер 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 (или доверенна треть сторона) выполн ет аутентификацию на основе информации
(доказательства) о клиенте, полученной, когда клиент аутентифицировалс на сервере.
Страница: 10
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
Таким образом, клиент может получить доступ к серверам/сервисам в среде 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. Таким образом, делегирование по каждому клиенту
приводитс в исполнение при наличии пересылаемого флага в мандате сервиса клиента.
Страница: 11
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
Если клиент 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 протокола аутентификации может, например, включать
Страница: 12
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
систему 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
Страница: 13
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
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
Страница: 14
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
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.
Страница: 15
RU 2 337 399 C2
5
10
15
20
25
При действии #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.
Заключение
Хот в предыдущем подробном описании были описаны и проиллюстрированы
сопроводительными чертежами некоторые предпочтительные варианты реализации
различных способов и систем согласно насто щему изобретению, очевидно, что
изобретение не ограничиваетс раскрытыми здесь иллюстративными вариантами, а
предусматривает возможность многочисленных перекомпоновок, модификаций и замен без
отклонени от сущности изобретени , как изложено и определено в формуле изобретени .
30
35
40
45
50
Формула изобретени 1. Способ управлени доступом к первому вычислительному ресурсу, не требу от
пользовател уникальной учетной записи пользовател , св занной с первым
вычислительным ресурсом, причем способ включает прием от пользовател через сеть
св зи парного уникального идентификатора (PUID), св занного с пользователем, которому
должен быть обеспечен доступ к первому вычислительному ресурсу, при этом упом нутый
идентификатор PUID св зан со вторым вычислительным ресурсом, который
аутентифицировал пользовател на основе адреса электронной почты, св занного с
пользователем;
преобразование идентификатора PUID в идентификатор защиты (SID) путем подачи
идентификатора PUID в интерфейс прикладного программировани (API) и приема в ответ
идентификатора SID API;
определение того, имеет ли пользователь соответствующее разрешение на доступ к
первому вычислительному устройству, путем сравнени идентификатора SID с по меньшей
мере одним другим идентификатором SID, обеспечиваемым механизмом управлени доступом, св занным с первым вычислительным ресурсом; и обеспечение управл емого
доступа к первому вычислительному ресурсу в соответствии с упом нутыми
разрешени ми.
2. Способ по п.1, в котором идентификатор PUID св зан с сервисом Passport.
3. Способ по п.1, в котором преобразование идентификатора PUID в идентификатор SID
дополнительно содержит: разделение идентификатора PUID по меньшей мере на одну
часть идентификатора, соответствующую идентификатору субполномочий, и по меньшей
мере одну часть, соответствующую идентификатору члена.
Страница: 16
CL
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
4. Способ по п.1, в котором прием идентификатора PUID дополнительно включает в себ прием идентификатора PUID в сообщении на основе протокола Kerberos.
5. Способ по п.4, в котором идентификатор PUID обеспечиваетс в сертификате РАС в
сообщении на основе протокола Kerberos.
6. Способ по п.4, в котором сообщение на основе протокола Kerberos св зано с
процессом S4U2self.
7. Способ по п.4, в котором сообщение на основе протокола Kerberos св зано с
процессом S4U2proxy.
8. Способ по п.1, в котором определение того, совпадает ли идентификатор SID с по
меньшей мере одним другим идентификатором SID, обеспечиваемым механизмом
управлени доступом, включает в себ сравнение идентификатора SID с по меньшей мере
одним другим идентификатором SID в списке управлени доступом (ACL), св занном с
первым вычислительным ресурсом.
9. Способ по п.1, в котором прием идентификатора PUID, св занного с пользователем,
которому должен быть обеспечен доступ к первому вычислительному ресурсу, включает в
себ обеспечение учетной записи по умолчанию дл пользовател , которому должен быть
обеспечен доступ к первому вычислительному ресурсу.
10. Способ управлени доступом к по меньшей мере одному вычислительному ресурсу,
содержащий
прием по меньшей мере одного адреса электронной почты дл по меньшей мере одного
пользовател , которому должен быть предоставлен по меньшей мере ограниченный доступ
к по меньшей мере одному вычислительному ресурсу;
предоставление упом нутого адреса электронной почты по меньшей мере одному
доверенному сервису, выполненному с возможностью выдачи уникального
идентификатора, св занного с пользователем, на основе упом нутого адреса электронной
почты;
прием уникального идентификатора, выданного доверенным сервисом;
и установку по меньшей мере одного разрешени дл управлени доступом
пользовател , которое св зано с упом нутым по меньшей мере одним вычислительным
ресурсом, на основе уникального идентификатора.
11. Способ по п.10, в котором установка по меньшей мере одного разрешени дл управлени доступом пользовател включает в себ преобразование уникального
идентификатора в идентификатор защиты (SID) и св зывание идентификатора SID с по
меньшей мере одним списком управлени доступом (ACL) дл упом нутого по меньшей
мере одного вычислительного ресурса.
12. Способ по п.10, в котором уникальный идентификатор включает в себ парный
уникальный идентификатор (PUID).
13. Способ по п.12, в котором идентификатор PUID св зан с сервисом Passport.
14. Способ по п.11, в котором уникальный идентификатор включает в себ идентификатор PUID, а преобразование уникального идентификатора в идентификатор SID
дополнительно содержит разделение идентификатора PUID на по меньшей мере одну
часть, соответствующую идентификатору субполномочий, и по меньшей мере одну часть,
соответствующую идентификатору члена.
15. Способ по п.11, в котором уникальный идентификатор включает в себ идентификатор PUID, а преобразование уникального идентификатора в идентификатор SID
включает в себ подачу идентификатора PUID в интерфейс прикладного
программировани (API) и последующий прием идентификатора SID от интерфейса API.
16. Способ по п.10, в котором прием уникального идентификатора включает в себ прием уникального идентификатора в сообщении на основе протокола Kerberos.
17. Способ по п.16, в котором уникальный идентификатор обеспечиваетс в
сертификате РАС в сообщении на основе протокола Kerberos.
18. Машиночитаемый носитель, содержащий исполн емые команды дл выполнени действий по управлению доступом к первому вычислительному ресурсу, включающих в
Страница: 17
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
себ получение парного уникального идентификатора (PUID), св занного с пользователем,
которому должен быть предоставлен управл емый доступ к первому вычислительному
ресурсу, при этом идентификатор PUID св зан со вторым вычислительным ресурсом,
который аутентифицировал пользовател на основе адреса электронной почты, св занного
с пользователем;
преобразование идентификатора (PUID) в идентификатор защиты (SID) путем подачи
идентификатора PUID в интерфейс прикладного программировани (API) и приема в ответ
идентификатора SID от интерфейса API;
определение того, имеет ли пользователь соответствующее разрешение на доступ к
первому вычислительному ресурсу, путем сравнени идентификатора SID с по меньшей
мере одним другим идентификатором SID, обеспечиваемым механизмом управлени доступом, св занным с первым вычислительным ресурсом; и
обеспечение управл емого доступа к первому вычислительному ресурсу в соответствии
с упом нутыми разрешени ми, не требу от пользовател уникальной учетной записи
пользовател , св занной с первым вычислительным ресурсом.
19. Машиночитаемый носитель по п.18, в котором идентификатор PUID св зан с
сервисом Passport.
20. Машиночитаемый носитель по п.18, в котором преобразование идентификатора
PUID в идентификатор SID дополнительно включает в себ разделение идентификатора
PUID на по меньшей мере одну часть, соответствующую идентификатору субполномочий, и
по меньшей мере одну часть, соответствующую идентификатору члена.
21. Машиночитаемый носитель по п.18, в котором получение идентификатора PUID
включает в себ получение идентификатора PUID в сообщении на основе протокола
Kerberos
22. Машиночитаемый носитель по 21, в котором идентификатор PUID обеспечиваетс в
сертификате РАС в сообщении на основе протокола Kerberos.
23. Машиночитаемый носитель по п.21, в котором сообщение на основе протокола
Kerberos св зано с процессом S4U2self.
24. Машиночитаемый носитель по п.21, в котором сообщение на основе протокола
Kerberos св зано с процессом S4U2proxy.
25. Машиночитаемый носитель по п.18, в котором определение того, имеет ли
пользователь соответствующие разрешени на доступ к первому вычислительному
ресурсу, включает в себ сравнение идентификатора SID с по меньшей мере одним другим
идентификатором SID в списке управлени доступом (ACL), св занном с первым
вычислительным ресурсом.
26. Машиночитаемый носитель по п.18, в котором получение идентификатора PUID,
св занного с пользователем, которому должен быть обеспечен управл емый доступ к
первому вычислительному ресурсу, включает в себ обеспечение учетной записи по
умолчанию дл пользовател , которому должен быть обеспечен доступ к первому
вычислительному ресурсу.
27. Машиночитаемый носитель, содержащий исполн емые компьютером команды дл выполнени действий по управлению доступом к вычислительному ресурсу, включающих в
себ получение по меньшей мере одного адреса электронной почты дл по меньшей мере
одного пользовател , которому должен быть предоставлен по меньшей мере ограниченный
доступ по меньшей мере к одному вычислительному ресурсу;
выдачу упом нутого адреса электронной почты по меньшей мере одному доверенному
сервису, выполненному с возможностью выдачи соответствующего уникального
идентификатора, св занного с пользователем на основе упом нутого адреса электронной
почты;
прием уникального идентификатора, выданного доверенным сервисом; и
установление по меньшей мере одного разрешени дл управлени доступом
пользовател , которое св зано с упом нутым по меньшей мере одним вычислительным
Страница: 18
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
ресурсом, на основе уникального идентификатора.
28. Машиночитаемый носитель по п.27, в котором установление по меньшей мере
одного разрешени дл управлени доступом пользовател на основе уникального
идентификатора включает в себ преобразование уникального идентификатора в
идентификатор защиты (SID) и приписывание идентификатора SID к по меньшей мере
одному списку управлени доступом (ACL) дл упом нутого вычислительного ресурса.
29. Машиночитаемый носитель по п.27, в котором уникальный идентификатор включает
в себ парный уникальный идентификатор (PUID).
30. Машиночитаемый носитель по п.29, в котором идентификатор PUID св зан с
сервисом Passport.
31. Машиночитаемый носитель по п.30, в котором уникальный идентификатор включает
в себ идентификатор PUID, а преобразование уникального идентификатора в
идентификатор SID включает в себ разделение идентификатора PUID на по меньшей
мере одну часть, соответствующую идентификатору субполномочий, и по меньшей мере
одну часть, соответствующую идентификатору члена.
32. Машиночитааемый носитель по п.30, в котором уникальный идентификатор включает
в себ идентификатор PUID, а преобразование уникального идентификатора в
идентификатор SID включает в себ подачу уникального идентификатора Passport в
интерфейс прикладного программировани (API) и последующий прием идентификатора
SID от интерфейса API.
33. Машиночитаемый носитель по п.27, в котором прием уникального идентификатора
включает в себ прием уникального идентификатора в сообщении на основе протокола
Kerberos.
34. Машиночитаемый носитель по п.33, в котором уникальный идентификатор
обеспечиваетс в сертификате РАС в сообщении на основе протокола Kerberos.
35. Реализуемый в компьютерном устройстве способ преобразовани уникального
парного идентификатора (PUID) в соответствующий идентификатор защиты (SID) при
обеспечении управл емого доступа, причем способ содержит
прием идентификатора PUID;
разделение идентификатора PUID на по меньшей мере одну часть, соответствующую
идентификатору субполномочий, и по меньшей мере одну часть, соответствующую
идентификатору члена; и
компоновку упом нутой по меньшей мере одной части, соответствующей
идентификатору субполномочий, и упом нутой по меньшей мере одной части,
соответствующей идентификатору члена, в идентификатор SID, предназначенный дл обеспечени пользователю управл емого доступа к другому вычислительному ресурсу.
36. Способ по п.35, в котором компоновка упом нутой по меньшей мере одной части,
соответствующей идентификатору субполномочий, и упом нутой по меньшей мере одной
части, соответствующей идентификатору члена, в идентификаторе SID дополнительно
включает в себ компоновку идентификатора SID таким образом, чтобы SID имел
идентификатор субполномочий, HIWORD (MemberlDHigh), LOWORD (MemberlDHigh) и
MemberlDLow.
37 Способ по п.35, дополнительно содержащий выдачу идентификатора SID.
38. Машиночитаемый носитель, содержащий исполн емые компьютером команды дл выполнени действий по преобразованию парного уникального идентификатора (PUID) в
соответствующий идентификатор защиты (SID) при обеспечении управл емого доступа,
включающих в себ прием уникального парного идентификатора (PUID) и преобразование
идентификатора PUID в соответствующий идентификатор защиты (SID) путем разделени идентификатора PUID на по меньшей мере одну часть, соответствующую идентификатора
субполномочий, и по меньшей мере одну часть, соответствующую идентификатору члена, и
компоновки упом нутой по меньшей мере одной части, соответствующей идентификатору
субполномочий, и упом нутой по меньшей мере одной части, соответствующей
идентификатору члена, в идентификаторе SID, предназначенный дл обеспечени Страница: 19
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
пользователю управл емого доступа к другому вычислительному ресурсу.
39. Машиночитаемый носитель по п.38, в котором компоновка упом нутой по меньшей
мере одной части, соответствующей идентификатору субполномочий, и упом нутой по
меньшей мере одной части, соответствующей идентификатору члена, в идентификатор SID
дополнительно включает в себ компоновку идентификатора SID таким образом, чтобы SID
имел идентификатор субполномочий, HIWORD (MemberlDHigh), LOWORD (MemberlDHigh) и
MemberlDLow.
40. Машиночитаемый носитель по п.38, дополнительно включающий выдачу
идентификатора SID.
41. Система дл управлени доступом по меньшей мере к одному вычислительному
ресурсу, причем система содержит
пам ть,
средство дл осуществлени св зи, функционально соединенное с пам тью и
сконфигурированное дл приема уникального идентификатора, св занного с
пользователем посредством адреса электронной почты пользовател , пользователю
должен быть обеспечен управл емый доступ к по меньшей мере одному вычислительному
ресурсу, при этом уникальный идентификатор св зан с другим вычислительным ресурсом,
который аутентифицировал пользовател на основе адреса электронной почты
пользовател , и
логические схемы, функционально сконфигурированые дл преобразовани уникального
идентификатора в идентификатор защиты (SID), причем логические схемы разрешают
пользователю осуществл ть доступ к упом нутому по меньшей мере одному
вычислительному ресурсу, если идентификатор SID совпадает с по меньшей мере одним
другим идентификатором SID, который хранитс в пам ти и св зан с упом нутым по
меньшей мере одним вычислительным ресурсом.
42. Система по п.41, в которой уникальный идентификатор включает в себ уникальный
парный идентификатор (PUID).
43. Система по п.42, в которой идентификатор PUID св зан с сервисом Passport.
44. Система по п.43, в которой логические схемы дополнительно сконфигурированы дл разделени уникального идентификатора Passport по меньшей мере на одну часть,
соответствующую идентификатору субполномочий, и по меньшей мере одну часть,
соответствующую идентификатору члена.
45. Система по п.41, в которой логические схемы конфигурируемы дл приема
уникального идентификатора в сообщении на основе протокола Kerberos.
46. Система по п.45, в которой уникальный идентификатор обеспечиваетс в
сертификате РАС в сообщении на основе протокола Kerberos.
47. Система по п.45, в которой сообщение на основе протокола Kerberos св зано с
процессом S4U2self.
48. Система п.п.46, в которой сообщение на основе протокола Kerberos св зано с
процессом S4U2proxy.
49. Система по п.41, в которой упом нутый по меньшей мере один другой
идентификатор SID, который хранитс в пам ти, вл етс частью списка управлени доступом (ACL), св занного с упом нутым по меньшей мере одним вычислительным
ресурсом.
50. Система по п.41, в которой логические схемы дополнительно конфигурируемы дл обеспечени пользовател , дл которого должно быть обеспечено управление доступом к
по меньшей мере одному вычислительному ресурсу, с возможностью иметь анонимную
учетную запись.
51. Система дл управлени доступом к по меньшей мере одному вычислительному
ресурсу, содержаща сеть св зи; первое устройство, функционально соединенное с сетью
св зи и конфигурированное дл получени по меньшей мере одного адреса электронной
почты по меньшей мере одного пользовател , которому должен быть предоставлен по
меньшей мере ограниченный доступ к по меньшей мере одному вычислительному ресурсу,
Страница: 20
RU 2 337 399 C2
5
10
15
20
25
подачи упом нутого адреса электронной почты по сети св зи в другое устройство,
сконфигурированное дл обеспечени по меньшей мере одного доверенного сервиса,
выполненного с возможностью приема упом нутого по меньшей мере одного адреса
электронной почты из сети св зи, преобразовани этого адреса электронной почты в
уникальный идентификатор и выдачи уникального идентификатора в сеть св зи, при этом
первое устройство дополнительно сконфигурировано дл последующего приема по сети
св зи уникального идентификатора, определени того, совпадает ли этот уникальный
идентификатор с по меньшей мере одним другим идентификатором, обеспечиваемым
механизмом управлени доступом, св занным с упом нутым вычислительным ресурсом, и
установки по меньшей мере одного разрешени на управление доступом, св занного с
упом нутым по меньшей мере одним вычислительным ресурсом, дл пользовател на
основе прин того уникального идентификатора.
52. Система по п.51, в которой первое устройство дополнительно сконфигурировано дл преобразовани уникального идентификатора в идентификатор защиты (SID) и св зывани идентификатор SID с по меньшей мере одним списком управлени доступом (ACL) дл упом нутого по меньшей мере одного вычислительного ресурса.
53. Система по п.52, в которой уникальный идентификатор включает в себ парный
уникальный идентификатор (PUID).
54. Система по п.53, в которой идентификатор PUID вл етс уникальным
идентификатором Passport.
55. Система по п.54, в которой первое устройство дополнительно сконфигурировано дл разделени уникального идентификатора Passport по меньшей мере на одну часть,
соответствующую идентификатору субполномочий, и по меньшей мере одну часть,
соответствующую идентификатору члена, во врем преобразовани в соответствующий
идентификатор SID.
56. Система по п.51, в которой первое устройство сконфигурировано дл приема
уникального идентификатора в сообщении на основе протокола Kerberos.
57. Система по п.56, в которой уникальный идентификатор обеспечиваетс в
сертификате РАС в сообщении на основе протокола Kerberos.
30
35
40
45
50
Страница: 21
RU 2 337 399 C2
Страница: 22
DR
RU 2 337 399 C2
Страница: 23
RU 2 337 399 C2
Страница: 24
RU 2 337 399 C2
Страница: 25
RU 2 337 399 C2
Страница: 26
у
приводитс в исполнение при наличии пересылаемого флага в мандате сервиса клиента.
Страница: 11
RU 2 337 399 C2
5
10
15
20
25
30
35
40
45
50
Если клиент 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 и дополнительно включает данные учетной записи об
идентификации/пользовател /клиента дл конкретной реализации, например,
Документ
Категория
Без категории
Просмотров
0
Размер файла
580 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа