СОГЛАСОВАНИЕ ПОЛНОМОЧИЙ Российский патент 2010 года по МПК G06F21/20 H04L29/06 

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

Данная заявка соответствует заявке того же правообладателя, находящейся на рассмотрении, имеющей серийный номер 10/365,878, авторы David B. Cross и др., поданной 13.02.2003 г. и озаглавленной «Digital Identity Management».

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

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

Предшествующий уровень техники

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

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

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

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

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

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

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

В другой реализации предоставляется способ. Примерный способ включает в себя перечисление локальных полномочий и удаленных полномочий в ответ на прием уведомления о событии и синхронизацию локальных полномочий и удаленных полномочий.

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

Перечень чертежей

Фиг.1 - схематическая иллюстрация примерной компьютерной сети, которая может реализовать согласование полномочий;

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

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

Фиг.4a - иллюстрация примерного файла состояний;

Фиг.4b - иллюстрация примерного элемента состояния в файле состояний;

Фиг.5 - иллюстрация примерной матрицы арбитража, в котором (a) является менее строгой матрицей и (b) является более строгой матрицей;

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

Фиг.7 - схематическая иллюстрация примерного компьютерного устройства, которое может использоваться для реализации согласования полномочий.

Подробное описание

Коротко говоря, согласование полномочий может быть реализовано для синхронизации локальных полномочий (ключей шифрования, сертификатов, маркеров и т.д.) на любом числе (n) вычислительных устройств. В целях иллюстрации пользователь может заменять, модифицировать, добавлять и/или удалять полномочия в его или ее портативном или настольном компьютере. Когда пользователь осуществляет логический выход на портативном или настольном компьютере, служба управления синхронизирует локальные полномочия с удаленным кэш-буфером (кэшем). Удаленный кэш может быть реализован как удаленная служба каталогов, такая как, например, Active Directory (Активный Каталог), доступная для операционной среды Microsoft Windows®. Альтернативно, служба управления может выполнять синхронизацию в ответ на другие события. Например, синхронизация в реальном масштабе времени может произойти в ответ на добавление, удаление и/или изменение одного или более полномочий.

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

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

Примерная система

Фиг.1 является схематической иллюстрацией примерной сетевой вычислительной системы 100 в которой согласование полномочий может быть реализовано. Сетевая компьютерная система 100 может включать в себя одну или более коммуникационных сетей 110 типа локальной сети (LAN) и/или глобальной сети (WAN). Один или более хостов (главных компьютеров) 120 и один или более клиентов 130a-c могут быть соединены с возможностью связи по коммуникационной сети(ям) 110.

Хост 120 и клиенты 130a-c (в дальнейшем обобщенно называемые как клиенты 130) могут соединяться с сетью через коммуникационное соединение, такое как, например, соединение Ethernet. Хотя нет никаких теоретических ограничений на число устройств, которые могут быть включены в сеть, такую как сетевая вычислительная система 100, число устройств ограниченно, прежде всего, возможностью соединения, реализуемой в коммуникационной сети.

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

Полномочия 140a-c (в дальнейшем в общем называемые как полномочия 140) могут быть представлены в одном или более клиентов 130. Полномочия могут быть предоставлены, например, для симметричного и/или асимметричного шифрования/дешифрования данных для защищенной связи по сети 110, применения цифровой подписи для содержимого или аутентификации для системы, при этом названы только несколько примеров. Любое число полномочий 140 может храниться в локальном кэше 135a-c (в дальнейшем обобщенно называемом как локальный кэш 135). Локальный кэш 135 может включать в себя профиль пользователя или другое хранилище (например, для пользовательских параметров настройки и полномочий), хотя другие реализации также рассматриваются.

Отметим, что полномочия 140 могут включать в себя любое из широкого разнообразия различных типов полномочий, таких как, например, симметричные ключи шифрования, асимметричные пары ключей шифрования, сертификаты X.509, лицензии XrML (расширяемого языка разметки прав), маркеры и полномочия аутентификации/авторизации, при этом названо только несколько примерных полномочий. Конечно, полномочия 140 не ограничены этими примерами и могут включать другие типы полномочий, которые известны сейчас или будут разработаны позже.

Полномочия 140 могут быть добавлены в локальный кэш 135, например, для шифрования/дешифрования различных типов данных. Кроме того, полномочия 140 могут быть изменены или заменены, например, для уменьшения вероятности того, что неавторизованные пользователи смогут дешифровать схему шифрования. Полномочия, которые больше не используются, могут быть удалены. Если одно или более полномочий 140 добавлены, изменены, заменены или удалены в любом из клиентов (например, 130a), это изменение может быть распространено на один или более других клиентов (например, 130b, 130c) так, чтобы пользователь имел доступным текущий и полный набор полномочий шифрования на любом количестве (n) различных клиентов, как описывается более подробно ниже.

В примерной реализации локальные полномочия 140 могут быть синхронизированы с удаленными полномочиями 150, представленными в удаленном кэше 125, например, на одном или более хостах 120 или в совместно используемом кэше на другом клиенте 130 в среде рабочей группы. Соответственно, пользователь имеет доступным текущий и полный набор полномочий, когда пользователь осуществляет логический вход на другие клиенты 130.

Удаленный кэш 125 может быть реализован как служба каталогов, такая как облегченный протокол доступа к каталогам (LDAP) или служба каталогов X.500. Служба каталогов может быть монолитной, или она может быть распределенной как реализация с множеством главных компонентов или реализация на основе отношения «главный-подчиненный». Удаленный кэш 125 может храниться в защищенном или зашифрованном состоянии так, чтобы удаленные полномочия 150 не были подвержены риску, украдены или использованы неавторизованными пользователями.

Примерной службой каталогов является Active Directory, доступная в операционной среде Microsoft WINDOWS®. Active Directory является службой каталогов, которая может быть развернута в распределенных вычислительных средах для обеспечения всесторонних служб каталогов. Active Directory служит точкой консолидации для изолирования, перемещения, центрального управления и сокращения числа каталогов, в которых нуждается предприятие. Active Directory также служит центральным доверенным органом (CA) для сетевой безопасности.

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

Фиг.2 является функциональной блок-схемой примерных модулей для реализации согласования полномочий, например, с использованием службы уведомления. Служба 200 уведомления может быть реализована в виде машиночитаемого программного кода (например, в виде программного обеспечения и/или встроенного программного обеспечения), хранящегося в машиночитаемом хранилище или памяти и исполняемого процессором (или устройствами обработки данных) на одном или более клиентах (например, клиентах 130a-c на фиг.1). Служба 200 уведомления принимает уведомление о различных системных событиях и активирует службу 250 управления для синхронизации локальных и удаленных полномочий для пользователя. Соответственно, синхронизация может быть автоматической и прозрачной для пользователя.

Что касается фиг.2, служба 200 уведомления может включать в себя обработчик 210 событий. Обработчик 210 событий принимает уведомление о событиях 220a-c (в дальнейшем, обобщенно называемых как события 220). События 220 могут включать в качестве примера начальный запуск, завершение, логический вход, логический выход, блокирование, разблокирование, при этом названы только несколько примерных событий. Другие события могут также включать, но не в ограничительном смысле, события сеанса (например, модификацию политики, запуск процесса, сетевое соединение) и события таймера (например, каждые 8 часов, раз в месяц). Дополнительно, событие может также быть инициировано вручную, например, пользователем, запрашивающим синхронизацию полномочий.

Обработчик 210 событий может генерировать одно или более заданий 230, основанных, по меньшей мере, частично на событиях 220. Задания 230 могут включать в себя вызовы других служб. Например, задание 230 может вызывать службу 240 авторегистрации. Авторегистрация является службой, которая может использоваться для заполнения профиля пользователя полномочиями и т.д., и может быть активирована, когда пользователь является новым для системы (например, гость) для обеспечения ограниченных функциональных возможностей и осуществления доступа к основным ресурсам, не ставя под угрозу сетевую безопасность. Авторегистрация автоматически «зарегистрирует» пользователя посредством запросов/обновления полномочий для пользователя, например, основываясь на системных политиках для вычислительной среды. Задание 230 может также вызвать службу 250 управления для синхронизации полномочий шифрования с удаленным кэшем (например, удаленным кэшем 125 на фиг.1), как будет обсуждаться более подробно ниже.

Задания 230 могут быть переданы диспетчеру 260. Диспетчер 260 заданий может удалять задания 230 из очереди и обрабатывать задания 230 последовательным способом. Диспетчер 260 заданий определяет, какой программный код (или модули) загрузить для обработки задания и когда загружать программный код. Диспетчер 260 заданий может также выгрузить программный код, который больше не используется.

Служба 200 уведомления может также включать в себя логические средства для интеллектуального управления заданиями 230 для уменьшения ненужного потребления ресурсов. В примерной реализации диспетчер 260 заданий определяет, загружен ли уже программный код (или модули) для обработки задания 230. Кроме того, если очередь 270 заданий пуста (например, нет никаких незаконченных заданий 230), диспетчер 260 заданий высвобождает загруженный программный код (или модули).

В другой примерной реализации обработчик 210 событий может упорядочить задания 230, которые активируют службу 250 управления в очереди 270 перед заданиями 230, которые активируют службу 240 авторегистрации. Когда события 220 инициируют задания 230 для вызова и службы 240 авторегистрации, и службы 250 управления, задания 230, вызывающие службу 240 авторегистрации, могут быть удалены из очереди 270, если служба управления способна обеспечить полномочия для пользователя во время синхронизации.

В другой примерной реализации могут быть реализованы демпфирующие логические средства для уменьшения количества повторных вызовов службы 250 управления (например, когда событие 220 вызывает другие события). Например, диспетчер 260 может изучить очередь 270 заданий и отказаться от любых заданий 230, которые являются дубликатами или иным образом ненужными.

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

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

Служба 300 управления может быть реализована в машиночитаемом программном коде (например, программном обеспечении и/или встроенном программном обеспечении), хранящемся в машиночитаемом хранилище или памяти и исполняемом процессором (или устройствами обработки данных) на одном или более клиентах (например, клиентах 130a-c на фиг.1). Служба 300 управления может включать в себя модуль 320 синхронизации для оценки полномочий, разрешения конфликта(ов) и обновления полномочий в локальных и удаленных кэшах.

Модуль 320 синхронизации может быть в рабочем состоянии связан с менеджером (средством управления) 330 локального хранилища и менеджером 340 удаленного хранилища. Менеджер 330 локального хранилища может быть в рабочем состоянии связан с одним или более локальными кэшами 350 для локальных полномочий 355. Кроме того, менеджер 330 локального хранилища может обобщать процедуры для загрузки/сохранения локальных полномочий 355 шифрования локально. Менеджер 340 удаленного хранилища может быть в рабочем состоянии связан с удаленным кэшем 360 (например, службой каталогов), предоставленным через один или более серверных компьютеров или хостов 370. Менеджер 340 удаленного хранилища может также защищенно связаться с хостом 370 для доступа к одному или более удаленным полномочиям 365 через удаленную службу 360 каталогов, например, во время синхронизации.

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

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

Модуль 320 синхронизации может работать вместе с менеджером 330 локального хранилища и менеджером 340 удаленного хранилища для синхронизации локальных полномочий 355 шифрования и удаленных полномочий 365 шифрования. Для многих активаций может не быть никаких изменений ни в локальных, ни в удаленных полномочиях шифрования. Во время других обращений может потребоваться сделать изменения только в локальных полномочиях 355 или только в удаленных полномочиях 365. Однако также могут быть обстоятельства, когда может быть необходимо сделать это и для локальных полномочий 355, и для удаленных полномочий 365. Соответственно, модуль синхронизации может быть реализован для обработки каждого из этих сценариев.

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

Во время сравнения модуль 320 синхронизации может столкнуться с конфликтами, которые должны быть разрешены для того, чтобы синхронизировать локальные и удаленные полномочия 355, 365. Например, локальное полномочие (названное «старое полномочие» для целей иллюстрации) может измениться или быть удаленным из локального кэша 350, поскольку оно больше не нужно. Когда модуль 320 синхронизации сравнивает локальные и удаленные полномочия 355, 365, удаленные полномочия, однако, могут все еще включать старое полномочие. Модуль 320 синхронизации разрешает такой конфликт так, чтобы старое полномочие изменилось или было удалено из удаленного кэша 360 и не было перезаписано в локальный кэш 350.

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

В примерной реализации модуль 320 синхронизации поддерживает один или более файлов 395 состояний для разрешения конфликтов. Файл состояний является структурой данных, распространяемой на каждого пользователя (например, компьютерный файл, база данных, таблица памяти, файл журнала регистрации и т.д.), и может использоваться для хранения состояний локальных полномочий 350. Файл состояний может быть сохранен локально, например, в кэше 390, который в рабочем состоянии связан со службой 300 управления. В примерной реализации все поля могут быть сохранены в бинарной форме, с собственным порядком следования байтов, хотя другие реализации также подразумеваются.

Фиг.4a иллюстрирует примерный файл 400 состояний (например, структуру данных). Файл 400 состояния может включать в себя версию 410 файла и флажок 420. Флажок 420 может использоваться, например, для указания того, защищено ли полномочие пользователем, или можно ли им осуществлять обмен в сети. Альтернативно, флажок 420 (или другой флажок) может использоваться для указания того, должна ли использоваться более или менее строгая матрица для разрешения конфликтов.

Файл 400 состояний может также включать в себя одно или более состояний 430-432 полномочий. Например, файл 400 состояний может включать в себя следующие состояния: время последнего вызова модуля синхронизации (T_S); время последнего изменения локального хранилища (T_L), время последнего изменения удаленного кэша (T_R). Файл состояний может также включать в себя элементы 440 состояний полномочий.

Фиг.4b иллюстрирует примерный элемент 450 состояния (например, структуру данных). Элемент 450 состояния может включать в себя список локальных состояний для каждого полномочия. Локальные состояния могут включать в себя идентификатор 460 полномочия, флажки 470, временную метку 480 и значение 490 хэш-функции.

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

В реализации, показанной на фиг.4, идентификатор 460 полномочия является «сжатым» путем к файлу полномочия шифрования. Идентификатор 460 полномочия может быть выражен как однобайтовая строка ASCII, хотя другие реализации также подразумеваются. Кроме того, любые подходящие флажки 470 могут быть определены и могут быть установлены (например, 1) или сброшены (например, 0). Например, флажок может указать, является ли полномочие шифрования согласуемым (может быть синхронизировано) или фиксированным (не должно быть синхронизировано).

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

Фиг.5a и 5b иллюстрируют примерные матрицы арбитража, где матрица 500 является менее строгой, а матрица 550 - более строгой. В матрицах 500, 550 полномочия, допускающие экспортирование, обозначены символом «E», а защищенные (или не допускающие для экспортирования) полномочия обозначены символом «P», где «/E» и «/P» обозначают противоположности. Временные метки обоих сертификатов используются для определения того, какой сертификат является самым последним. Самый последний сертификат используется для перезаписи локального и удаленного кэша. Другой сертификат удаляется.

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

Примерные операции

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

Фиг.6 является блок-схемой последовательности операций, иллюстрирующей примерные операции, которые могут быть осуществлены для согласования полномочий кодирования. В операции 610 клиент может принять уведомление о событии. Уведомления о событии могут включать в себя в качестве примера событие сеанса, событие логического входа, событие логического выхода, событие блокировки, событие разблокировки, событие таймера, событие приложения политики и/или событие обновления полномочий. В операции 620 локальные полномочия могут быть перечислены, а в операции 630 удаленные полномочия могут быть перечислены.

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

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

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

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

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

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

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

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

Вначале текущее время последнего изменения считывается из локального кэша и USN считывается из удаленного кэша. Затем T_L и T_R считываются из заголовка файла состояния. T_L сравнивается с временем последнего изменения, только что прочитанного из локального кэша, и T_R сравнивается с USN, прочитанным из удаленного кэша. Если они оба равны, делать ничего не требуется. В противном случае алгоритм может создать список C_L локальных изменений и список C_R удаленных изменений, оба из которых первоначально являются пустыми.

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

Если последний USN удаленного кэша отличен от T_R, все полномочия удаленного кэша считываются и те же самые операции, как только что были описаны, выполняются. Список C_R изменений может также быть обновлен.

C_L и C_R могут после этого быть оценены для определения того, были ли действия выполнены в отношении одного и того же полномочия в обоих списках. Если действия были выполнены в отношении одного и того же полномочия в обоих списках, эти действия могут быть оценены для определения того, есть ли какие-либо конфликты. Например, может быть конфликт, если C_L включает в себя элемент для полномочия А «изменить удаленный», в то время как C_R включает в себя элемент для того же самого полномочия как «изменить локальный». Конфликт может быть разрешен, основываясь на временах последних изменений локальных и удаленных полномочий. То есть элемент с более ранним временем изменения может быть удален из списка.

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

Файл состояний может после этого быть обновлен. Например, флажки DELETED, которые были установлены на чрезмерно долгое время, могут быть идентифицированы и удалены. Заголовок и элементы файла состояний могут также быть модифицированы, основываясь на результирующих элементах C_R и C_L. Если файл состояний не удалось обновить даже после нескольких повторений, согласование полномочий может быть заблокировано, потому что искаженный файл состояний может генерировать непредсказуемые результаты.

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

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

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

В любой примерной реализации «Write State» (состояние операции записи) возвращается для того, чтобы указать состояние завершения операции записи. Значения могут быть: NONE, PARTIAL и DONE, указывающие, что полномочие является (1) не измененным, (2) частично измененным или (3) успешно измененным соответственно. Если операция сохранения приводит к состоянию операции записи PARTIAL, элемент файла состояний помечается как UNWRITEABLE. Если операция удаления приводит к состоянию NONE или PARTIAL операции записи, то элемент файла состояний помечается как UNWRITEABLE. Для любой спорадической неудачи записи или удаления операции записи или удаления могут быть повторены и элемент файла состояний может быть помечен, когда все попытки для полномочия потерпели неудачу.

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

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

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

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

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

Примерное компьютерное устройство

Фиг.7 является схематической иллюстрацией примерного вычислительного устройства 700, которое может использоваться для реализации согласования полномочий. Вычислительное устройство 700 включает в себя один или более процессоров или устройств 732 обработки данных, системную память 734 и шину 736, которая соединяет различные системные компоненты, включая системную память 734, с процессорами 732. Шина 736 представляет одну или более из нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину, ускоренный графический порт и процессорную или локальную шину, использующие любое из разнообразия шинных архитектур. Системная память 734 включает в себя постоянное запоминающее устройство 738 (ROM) и оперативное запоминающее устройство 740 (RAM). Базовая система 742 ввода-вывода (BIOS), содержащая основные процедуры, которые помогают передавать информацию между элементами компьютерного устройства 700, например, во время запуска, хранится в ROM 738.

Вычислительное устройство 700 дополнительно содержит в себе накопитель 744 на жестких магнитных дисках для чтения и записи на жесткий диск (не показанный здесь) и может включать в себя магнитный дисковод 746 для чтения и записи на сменный магнитный диск 748 и оптический дисковод 750 для чтения и записи на сменный оптический диск 752 типа CD-ROM или других оптических носителей. Накопитель 744 на жестких магнитных дисках, магнитный дисковод 746 и оптический дисковод 750 подсоединены к шине 736 соответствующими интерфейсами 754a, 754b и 754c. Дисководы и накопители и их соответствующие машиночитаемые носители обеспечивают энергонезависимое хранение машиночитаемых команд, структур данных, программных модулей и других данных для вычислительного устройства 700. Хотя примерная среда, описанная здесь использует жесткий диск, сменный магнитный диск 748 и сменный оптический диск 752, другие типы машиночитаемых носителей типа магнитных кассет, плат флэш-памяти, цифровых видеодисков, оперативных запоминающих устройств (RAM), постоянных запоминающих устройств (ROM) и т.п. могут также использоваться в примерной среде.

Множество программных модулей может храниться на жестком диске 744, магнитном диске 748, оптическом диске 752, в ROM 738 или RAM 740, включая операционную систему 758, одну или более прикладных программ 760, других программных модулей 762 и данных 764 программ. Пользователь может вводить команды и информацию в вычислительное устройство 700 через устройства ввода данных типа клавиатуры 766 и координатно-указательного устройства 768. Другие устройства ввода данных (не показанные здесь) могут включать микрофон, джойстик, игровую клавиатуру, спутниковую антенну, сканер или подобные им. Эти и другие устройства ввода данных связаны с процессором 732 через интерфейс 756, который присоединен к шине 736. Монитор 772 или другой тип устройства отображения также связан с шиной 736 через интерфейс типа видеоадаптера 774.

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

Вычислительное устройство 700 может работать в сетевой среде, используя логические соединения с одним или более удаленными компьютерами типа удаленного компьютера 776. Удаленный компьютер 776 может быть персональным компьютером, сервером, маршрутизатором, сетевым PC, одноранговым устройством или другим общим сетевым узлом и обычно включает в себя многие или все из элементов, описанные выше по отношению к вычислительному устройству 700. Логические соединения, изображенные на фиг.7, включают в себя локальную сеть (LAN) 780 и глобальную сеть (WAN) 782.

При использовании в сетевой среде LAN вычислительное устройство 700 подсоединяется к локальной сети 780 через сетевой интерфейс или адаптер 784. При использовании в сетевой среде WAN вычислительное устройство 700 обычно включает в себя модем 786 или другие средства для установления связи по глобальной сети 782, такой как сеть Интернет. Модем 786, который может быть внутренним или внешним, подсоединен к шине 736 через интерфейс 756 последовательного порта. В сетевой среде программные модули, изображенные по отношению к вычислительному устройству 700, или их части могут храниться в удаленном запоминающем устройстве. Следует понимать, что показанные сетевые соединения являются примерными и могут использоваться другие средства установления связи между компьютерами.

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

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

Изобретение относится к системе обеспечения возможности согласования полномочий среди множества различных вычислительных устройств. Техническим результатом является ускорение процесса логического входа в вычислительную среду. Система включат обработчик событий для приема уведомления о событии, такого как, например, логический вход на клиенте. Обработчик событий может активировать службу управления в ответ на прием уведомления о событии. Служба управления может включать в себя модуль синхронизации для синхронизации полномочий пользователя с удаленной службой каталогов, такой как, например, Active Directory, так чтобы полномочия пользователя были доступны из любого числа различных вычислительных устройств. Причем конфликт синхронизации разрешается исключением упомянутых одних или более из локальных либо удаленных полномочий, которые были изменены в более раннее время. 3 н. и 35 з.п. ф-лы, 10 ил.

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

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

3. Способ по п.1, в котором синхронизация локальных полномочий и удаленных полномочий основана на сравнении значений хэш-функции.

4. Способ по п.1, в котором при синхронизации выполняют обработку ошибок.

5. Способ по п.1, в котором при синхронизации записывают по меньшей мере одно из локальных полномочий в удаленный кэш-буфер полномочий.

6. Способ по п.1, в котором при синхронизации записывают по меньшей мере одно из удаленных полномочий в локальный кэш-буфер полномочий.

7. Способ по п.1, в котором при синхронизации исключают по меньшей мере одно из локальных полномочий из локального кэш-буфера полномочий.

8. Способ по п.1, в котором при синхронизации исключают по меньшей мере одно из удаленных полномочий из удаленного кэш-буфера полномочий.

9. Способ по п.1, в котором при синхронизации изменяют по меньшей мере одно из локальных полномочий в локальном кэш-буфере полномочий, основываясь на по меньшей мере одном из удаленных полномочий.

10. Способ по п.1, в котором при синхронизации изменяют по меньшей мере одно из удаленных полномочий в удаленном кэш-буфере полномочий, основываясь на по меньшей мере одном из локальных полномочий.

11. Способ по п.1, дополнительно содержащий этап, на котором обновляют список локальных полномочий.

12. Способ по п.1, дополнительно содержащий этап, на котором обновляют список удаленных полномочий.

13. Способ по п.1, дополнительно содержащий этап, на котором определяют состояние удаленных полномочий динамически.

14. Способ по п.1, дополнительно содержащий этап, на котором поддерживают файл состояний для удаленных полномочий.

15. Способ по п.1, дополнительно содержащий этап, на котором поддерживают файл состояний для локальных полномочий.

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

17. Машиночитаемый носитель по п.16, в котором в компьютерном процессе синхронизация локальных полномочий и удаленных полномочий основывается на по меньшей мере одной временной метке, ассоциированной с локальными полномочиями, и по меньшей мере одной временной метке, ассоциированной с удаленными полномочиями.

18. Машиночитаемый носитель по п.16, в котором в компьютерном процессе синхронизация локальных полномочий и удаленных полномочий основывается на сравнении значений хэш-функции.

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

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

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

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

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

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

25. Машиночитаемый носитель по п.16, в котором компьютерный процесс дополнительно содержит обновление списка локальных полномочий.

26. Машиночитаемый носитель по п.16, в котором компьютерный процесс дополнительно содержит обновление списка удаленных полномочий.

27. Машиночитаемый носитель по п.16, в котором компьютерный процесс дополнительно содержит поддержку состояния удаленных полномочий.

28. Машиночитаемый носитель по п.16, в котором компьютерный процесс дополнительно содержит определение состояния удаленных полномочий динамически.

29. Машиночитаемый носитель по п.16, в котором компьютерный процесс дополнительно содержит поддержку состояния локальных полномочий.

30. Машиночитаемый носитель по п.16, в котором компьютерный процесс дополнительно содержит обработку ошибок.

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

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

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

34. Система по п.31, в которой локальные полномочия хранятся в локальном кэш-буфере, обеспеченном на любом количестве (n) клиентов.

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

36. Система по п.31, в которой локальные полномочия хранятся в удаленном кэш-буфере, обеспеченном на любом количестве (n) хостов.

37. Система по п.31, в которой удаленные полномочия поддерживаются удаленной службой каталогов.

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