Согласование полномочий

Согласование полномочий

Иллюстрации

Показать все

Реферат

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

Данная заявка соответствует заявке того же правообладателя, находящейся на рассмотрении, имеющей серийный номер 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. Если файл состояний не удалось обновить даже после нескольких повторений, согласование полномочий может быть заблокировано, потому что искаженный файл состояний может генерировать непредсказуемые результаты.

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