Предоставление цифровых удостоверений

Предоставление цифровых удостоверений

Иллюстрации

Показать все

Реферат

ПРЕДПОСЫЛКИ К СОЗДАНИЮ ИЗОБРЕТЕНИЯ

В последнее время произошли значительные изменения в развитии систем, которые позволяют человеку лучше контролировать распространение и использование персональной информации, в частности в цифровом виде. Например, Корпорация Майкрософт в Редмонде, штат Вашингтон, среди других, распространяет систему, которую называют Windows CardSpace, являющуюся одной из реализаций корпорацией Майкрософт более общей системы, под названием "выбор информационной карты" (Information Card Selector). В системе Windows CardSpace пользователь получает один или несколько цифровых удостоверений, называемых информационными картами. Когда пользователь пытается получить доступ к ресурсу (у "проверяющей стороны"), который требует выполнения набора запросов о пользователе, пользователь использует цифровое удостоверение (в дальнейшем называемое "DIR", сокращение от "digital identity representation") для коммуникации с провайдером идентификации, который может подтвердить эти запросы. В некоторых случаях провайдер идентификации может контролироваться пользователем и запускаться на пользовательской машине. В других случаях этот процесс может контролироваться третьим лицом. Провайдер идентификации возвращает маркер идентификации, который включает затребованную запросом информацию.

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

Один аспект относится к способу передачи DIR пользователю. Запрос, такой как HTTP запрос на создание DIR для пользователя, принимается через первый канал. Через второй канал посылается извещение о запросе на DIR, например, по электронной почте. Затем принимается одобрение на создание DIR, причем еще до создания DIR.

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

Еще один аспект относится к способу передачи DIR группе пользователей. Устанавливается политика, при которой доступ к DIR разрешен группе пользователей. Затем группа пользователей извещается о наличии доступного DIR. Затем принимается запрос от, по меньшей мере, первого пользователя группы пользователей на создание DIR. Наконец, DIR создается для, по меньшей мере, первого пользователя.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Далее дается ссылка на прилагаемые чертежи, в которых может не соблюдаться масштаб и в которых:

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

Фиг.2 иллюстрирует пример способа передачи и использования DIR;

Фиг.3 иллюстрирует другой пример способа передачи и использования DIR;

Фиг.4 иллюстрирует другой пример способа передачи DIR;

Фиг.5 иллюстрирует другой пример способа передачи DIR;

Фиг.6 иллюстрирует другой пример способа передачи DIR;

Фиг.7 иллюстрирует другой пример способа передачи DIR;

Фиг.8 иллюстрирует другой пример способа передачи DIR;

Фиг.9 иллюстрирует пример вычислительного устройства.

ДЕТАЛЬНОЕ ОПИСАНИЕ

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

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

Теперь обратимся к Фиг.1, на которой приведен пример системы 100 DIR, включая пользователя 110 и проверяющую сторону 120. Пользователь 110 владеет или контролирует пользовательскую машину 111. Пользовательская машина 111 включает компьютерную систему хотя бы временно контролируемую пользователем 110. Проверяющая сторона 120 может также включать компьютерную систему. Система 100 может также включать административную систему 160, систему 162 сбора данных, систему 164 генерации DIR, хранилище 168 данных идентификации и провайдера 115 идентификации, каждый из которых обсуждается далее ниже и может включать или быть частью компьютерной системы.

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

Также на Фиг.1 показан пример провайдера 115 идентификации. Провайдер 115 идентификации включает компьютерную систему, примеры реализаций, а также преобразователь 130 запросов и орган 140 обработки запросов. Преобразователь 130 запросов иногда называют "службой маркеров безопасности". В приведенном примере провайдер 115 идентификации может послать один или несколько запросов о пользователе 110. Запрос - это заявление или утверждение о пользователе, возможно включающий информацию о пользователе, такую, как, например, его имя, адрес, номер социальной защиты, возраст, кредитную историю, транзакционные требования и т.д. Как описано далее ниже, провайдер 115 идентификации может передавать запросы пользователю 119 и/или проверяющей стороне 120 в форме маркера идентификации с цифровой подписью. В примерах реализации провайдер 115 идентификации находится в доверительных отношениях с проверяющей стороной 120, и таким образом проверяющая сторона 120 доверяет запросам в подписанных маркерах идентификации, пришедших от провайдера 115 идентификации.

Хотя преобразователь запросов и орган 140 обработки запросов провайдера 115 идентификации показаны как отдельные сущности на Фиг.1, в альтернативных реализациях преобразователь 130 запросов и орган 140 обработки запросов может быть одной и той же сущностью или разными сущностями. Провайдер 115 идентификации в некоторых реализациях может принять форму сервиса маркера безопасности. Таким же образом провайдер идентификации 115 и система 164 генерации DIR может быть одной и той же сущностью или разными сущностями.

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

Каждая компьютерная система включает операционную систему, такую как (без ограничений) операционную систему WINDOWS (разработчик - корпорация Microsoft) и одну или несколько программ, хранящихся на машиночитаемых носителях. Каждая компьютерная система может также включать один или несколько коммуникационных устройств ввода или вывода, которые позволяют пользователю сообщаться с компьютерной системой, также как позволяют компьютерной системе сообщаться с другими устройствами. Коммуникации между компьютерными системами, используемыми пользователем 110 (например, пользовательской машиной 111), проверяющей стороной 120, системой 164 генерации DIR, административной системой 160, системой 162 сбора данных и провайдером 115 идентификации может быть реализована с использованием коммуникационных связей любого типа, включая, но без ограничений, Интернет, внутренние сети, сети Ethernet, связанные напрямую линии, спутники, инфракрасные сканеры, сотовую связь или любой другой тип проводных или беспроводных коммуникаций.

В некоторых примерах реализаций, описанных здесь, система 100 реализована хотя бы частично как система Information Card, предоставляемая средой.NET 3.0, разработанной корпорацией Microsoft (располагается в Редмонде, штат Вашингтон). Система Information Card позволяет пользователю управлять различными DIR от разных провайдеров идентификации.

Система Information Card использует одну платформу веб-сервисов, такую как Windows Communication Framework, входящую в состав среды.NET 3.0. Кроме того, система Information Card построена с использованием спецификаций безопасности веб-сервисов (Web Services Security Specification), распространяемой, хотя бы частично, корпорацией Microsoft из Редмонда, штат Вашингтон. Эти спецификации включают модель безопасности сообщений WS-Security, политику конечных точек WS-SecurityPolicy и метаданные для присоединения маркеров идентификации к сообщениям. Модель WS-SecurityPolicy описывает требования к политике конечных точек, такие, как требуемые маркеры идентификации и поддерживаемые алгоритмы шифрования. Такие требования к политике могут быть переданы и согласованы с использованием протокола метаданных, который определяется в WS-MetadataExchange. Модель WS-Trust описывает среду для моделей доверия, которая позволяет взаимодействовать различным веб-сервисам. Некоторые примеры реализаций, описанные здесь, ссылаются на описанные выше спецификации Web Services Security Specifications. В альтернативных реализациях одна или несколько других спецификаций могут быть использованы для облегчения процесса коммуникации между различными подсистемами в системе 100.

Обращаясь снова к Фиг.1, отметим, что пользователь 110 может послать запрос через пользовательскую машину 111 к проверяющей стороне 120 для доступа к товарам, услугам или другой информации. Например, в одной реализации пользовательская машина 111 посылает запрос к проверяющей стороне 120 на доступ к желаемой пользователем 110 информации от проверяющей стороны 120. Запрос, отправленный пользовательской машиной 111, может включать запрос на требования подлинности проверяющей стороны 120, использующей, например, механизмы, обеспечиваемые моделью WS-MetadataExchange.

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

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

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

В некоторых реализациях пользователь 110 может сделать запрос на то, чтобы проверяющая сторона 120 идентифицировала себя на пользовательской машине 111 таким образом, чтобы пользователь 110 мог решить, удовлетворяет ли он или нет политике безопасности принимающей стороны 120, как описано ниже. В одном примере проверяющая сторона 120 идентифицирует себя, используя сертификат X509. В других реализациях проверяющая сторона 120 может идентифицировать себя, используя другие механизмы, такие как, например, серверный сертификат протокола защищенных сокетов (Secure Sockets Layer, SSL).

Пользовательская машина 111 может включать один или несколько DIR для пользователя 110. Эти DIR (иногда их называют "информационными картами, Information Cards" в системе Windows Cardspace, предоставляемой средой.NET 3.0, разработанной корпорацией Майкрософт из Редмонда, штат Вашингтон) являются артефактами, которые представляют отношения, основанные на обмене маркерами между пользователем 110 и конкретным провайдером идентификации, таким как провайдер идентификации 115. Каждый DIR может соответствовать конкретному провайдеру идентификации, и пользователь 110 может иметь несколько DIR от одного или различных провайдеров идентификации. Использование DIR в системах идентификации описано в деталях в патентной заявке США серийный № 11/361281, который включен в данную работу посредством ссылки, как если бы он являлся частью данной работы.

DIR могут включать среди прочей информации политику выдачи маркеров идентификации провайдером идентификации, включая тип маркеров, которые могут быть выданы, типы запросов, для которых он имеет полномочия и/или мандат для использования с целью идентификации при запросе маркеров идентификации. DIR могут быть представлены в виде XML документов, которые выдаются провайдерами 115 идентификации или системами 164 генерации DIR и сохраняются пользователем 110 в устройстве хранения, таком, как пользовательская машина 111.

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

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

В общем случае орган 140 обработки запросов провайдера 115 идентификации может обеспечивать один или несколько запросов, требуемых политикой безопасности проверяющей стороны 120. Преобразователь 130 запросов провайдера 150 идентификации программируется на преобразование запросов и генерацию одного или нескольких подписанных маркеров 150 идентификации, которые включают запрос (запросы), относящиеся к пользователю 110.

Как отмечалось выше, пользователь 110 может запрашивать маркер идентификации в определенном формате в своем запросе к провайдеру 115 идентификации, на основе требований проверяющей стороны 120. Преобразователь запросов 130 может быть запрограммирован на генерацию маркеров идентификации в одном или нескольких форматах, включая (но не ограничивая данным списком) X509, Kerberos, SAML (версии 1.0 и 2.0), простой расширяемый протокол идентификации (Simple eXtensible Identity Protocol, SXIP) и т.д.

Например, в одной реализации орган 140 обработки запросов программируется на генерацию запросов в первом формате A, а политика безопасности проверяющей стороны 120 требует маркер идентификации во втором формате B. Преобразователь 130 может преобразовывать запросы, поступающие от органа 140 обработки запросов из формата A в формат B перед отправкой провайдера идентификации пользователю 110. Кроме того, преобразователь запросов 130 может быть запрограммирован на улучшение семантики конкретного запроса. В примерах реализаций семантика конкретного запроса преобразована для минимизирования объема информации в конкретном запросе и/или маркере идентификации для уменьшения или минимизирования объема персональной информации, передаваемой в данном запросе.

В примерах реализации преобразователь 130 запросов посылает маркер 150 идентификации пользователю 110, используя механизмы ответа, описанные в модели WS-Trust. В одной реализации преобразователь 130 запросов включает сервис маркеров безопасности (иногда их называют "STS", сокращение от "security token service"). В примере реализации пользователь 110 посылает маркер 150 идентификации проверяющей стороне 120 путем привязывания маркера 150 идентификации к прикладному сообщению, используя механизмы безопасного связывания, описанные в модели WS-Security. В других реализациях маркер 150 идентификации может быть послан непосредственно от провайдера идентификации к проверяющей стороне 120.

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

Теперь обсудим более подробно передачу DIR. Пользователь может получить DIR различными способами. Например, в реализации, проиллюстрированной на Фиг.1, система генерации DIR 164 обычно используется для сообщения с пользователем 110, создания новых DIR и извещения пользователя 110 о доступности DIR. Система 164 генерации DIR может в некоторых реализациях включать в себя веб-сайт в интернете. В других реализациях система 164 генерации DIR может включать в себя веб-сервис. В некоторых реализациях система 164 генерации DIR может также включать в себя информационный интернет-сервер (Internet Information Server, IIS) (166).

Хранилище 168 данных идентификации представляет собой систему хранения цифровой информации, доступ к которой в некоторых реализациях могут иметь провайдер 115 идентификации, система 164 генерации DIR и система 160 администрирования. Хранилище 168 данных идентификации может включать в себя сервер базы данных, компьютерную память или любое другое устройство (устройства) хранения данных. Хранилище 168 данных идентификации может содержать несколько устройств или систем в распределенной модели данных. Хранилище 168 данных может также включать или содержать службу директорий, такую, как Active Directiry 169, распространяемую корпорацией Майкрософт из Редмонда, штат Вашингтон.

Система 160 администрирования может включать в себя компьютерную систему, включая пользовательский интерфейс, который позволит администратору сообщаться с хранилищем 168 данных идентификации и системой 164 генерации DIR. Она также позволяет администратору определить типы DIR, которые создает система 164 генерации DIR и позволяет администратору контролировать, имеет ли конкретный пользователь право получать конкретные DIR. Использование системы 160 администрирования обсуждается ниже.

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

Фиг.2 иллюстрирует метод 200, который может быть реализован через систему 100. На этапе 210 администратор конфигурирует хранилище идентификационных данных. Например, администратор может, в некоторых реализациях, использовать систему 160 администрирования для установки таблиц в хранилище 168 идентификационных данных, которые будут использоваться для администрирования, генерирования и управления DIR. В примере реализации администратор может определить типы запросов, которые будут поддерживаться в DIR, созданных системой 164 генерации DIR и идентифицировать маркеры, сгенерированные провайдером 115 идентификации. Администратор может также использовать систему 160 администрирования для конфигурирования хранилища 168 данных идентификации для хранения информации о политике, такой, как типы маркеров, поддерживаемых провайдером 115 идентификации, информация об именах и общие метаданные. Другая информация в хранилище 168 идентификационных данных, которая может быть внедрена в DIR, включает фотографию пользователя 110 и информацию о соединениях, относящуюся к провайдерам идентификации, таким, как провайдер 115 идентификации.

Способ 200 далее переходит к этапу 220, когда пользователь 110 запрашивает DIR. DIR может быть запрошено различными способами. Например, пользователь 110 может использовать пользовательскую машину 111 для доступа к системе 164 генерации DIR через интернет браузер для запроса DIR. В некоторых реализациях пользователь 110 запрашивает конкретное DIR. В других реализациях, обсуждаемых ниже, пользователь запрашивает список DIR, имеющихся в наличии для пользователя 110 и выбирает из этого списка.

Затем способ 200 переходит к этапу 230, на котором система 164 генерации DIR проверяет хранилище 168 идентификационных данных, генерирует DIR и передает этот DIR пользователю 110. В одной реализации система 164 генерации DIR сначала проверяет хранилище 168 идентификационных данных для определения, имеет ли данный пользователь право запрашивать DIR. Это может быть выполнено различными способами, включая проверку DLL внутри хранилища 168 идентификационных данных, выполнение проверки доступа компонентом Active Directory, и т.д. Система 164 генерации DIR может также иметь доступ к идентификационным системным метаданным, хранимым в хранилище 168 идентификационных данных для определения, какие типы идентификационных запросов доступны для включения в новое DIR.

Когда система 164 генерации DIR создает новое DIR, DIR может принять форму XML документа и может включать, среди прочей информации: картинку для отображения на пользовательской машине; список запросов, включенный в DIR, список имеющихся в наличии типов маркеров для DIR; уникальное удостоверение DIR; подсказку ввода персональных данных (далее обсуждается ниже); идентификацию провайдера идентификации; и ссылку на конечную точку для провайдера 115 идентификации. Новое DIR может быть получено пользователем также различными способами, включая извещение по электронной почте о новом DIR, сообщение в формате HTTP или другими способами. При использовании здесь термин "электронная почта" включает текстовые сообщения, мгновенные сообщения или подобные формы электронной коммуникации.

При получении нового DIR пользователь 110 сохраняет 240 DIR, например в памяти, связанной с пользовательской машиной 111. Пользователь 250 затем запрашивает доступ к проверяющей стороне, такой как проверяющая сторона 120. Проверяющая сторона отказывает в доступе (например, путем перенаправления на страницу идентификации) и дает 260 свою политику безопасности обратно пользователю 110. Пользователь 110 затем выбирает 270 DIR, удовлетворяющее политике безопасности проверяющей стороны 120. Это может быть выполнено, например, через пользовательский интерфейс на пользовательской машине 111, которая показывает пользователю все имеющиеся в наличии DIR. В некоторых реализациях DIR, которые удовлетворяют требованиям политики безопасности проверяющей стороны, могут подсвечиваться для пользователя 110, в то время как другие карты будут без подсветки для облегчения процесса выбора для пользователя 110.

Пользователь 110 затем посылает 280 запрос для маркера идентификации к провайдеру идентификации, такой как провайдер 115 идентификации. Этот запрос на маркер идентификации может быть сгенерирован автоматически пользовательской машиной 111 при выборе пользователем 110 DIR, сохраненного на пользовательской машине 111. Провайдер идентификации 115 проверяет 285 хранилище 168 идентификационных данных для получения требуемой информации для наполнения запрошенного маркера идентификации. Эта информация могла бы включать, например, данные о запросах. Например, если выбранное DIR включает в себя запрос о возрасте, провайдер 115 идентификации может проверить хранилище 168 идентификационных данных для определения возраста пользователя. Провайдер 115 идентификации после этого становится способным создавать 285 запрошенный маркер идентификации и посылать 290 его пользователю. Затем пользователь посылает 295 маркер идентификации принимающей стороне и получает доступ, как это обсуждалось ранее.

При предоставлении доступа провайдером 115 идентификации тому же самому хранилищу 168 идентификационных данных, используемых системой 164 генерации DIR, администратор может гарантировать, что сгенерированные DIR останутся синхронизированными с актуальными данными, имеющимися для заполнения запросов в запрошенном маркере идентификации. Например, администратор конфигурирует хранилище 168 идентификационных данных таким образом, что данные по запросу о возрасте не сохраняются там, и тогда система 164 генерации DIR не будет создавать DIR, что включено в виде опции в запросе на возраст. Иначе могут появиться проблемы синхронизации. Например, предположим, что администратор создает новое DIR заново (без учета имеющихся идентификационных данных) и запрос на возраст включен и посылается как часть DIR назад пользователю. Когда пользователь пытается получить маркер идентификации через запрос о возрасте, этой информации нет в наличии и маркер будет отвергнут проверяющей стороной как неполный. Система 100, напротив, позволяет автоматическую синхронизацию сгенерированных DIR и имеющихся в наличии выделенных данных для заполнения соответствующих маркеров идентификации. Администратор через систему 160 администрации получает права для внесения изменений в хранилище идентификационных данных, которые автоматически отражаются как на передаваемых DIR, так и на соответствующих выдаваемых маркеров идентификации.

В некоторых реализациях, когда администратор вносит определенные изменения в хранилище 168 идентификационных данных, которые влияют на соответствие уже выпущенных DIR, любые пользователи, у которых имеются принятые измененные DIR, извещаются об этом и получают разрешения на получение новых DIR. Например, предположим, что правила хранения личных данных требуют, чтобы администратор удалил домашние адреса любых пользователей, сохраненные в хранилище 168 идентификационных данных. Любой пользователь 110, который получил DIR, в которое включен запрос на его/ее домашний адрес, теперь обладает неподходящим DIR (потому что в хранилище 168 идентификационных данных больше нет никаких данных, которые удовлетворяли бы этому запросу). В одной реализации, все такие пользователи извещаются, например, через электронную почту системой 164 генерации DIR, о том, что DIR (или несколько DIR) теперь не подходят, а также получают приглашение получить новый DIR, который не включает более не поддерживаемый запрос на домашний адрес. В этом случае единственное изменение, вносимое администратором в хранилище 168 данных (a) предотвращает новые DIR от выдачи с запросом на домашний адрес и (b) оповещает пользователей, что существующие DIR, которые включают данный запрос, недействительны и могут быть заменены.

Обращаясь теперь к Фиг.3, увидим теперь, что пример способа 300 описан в связи с системой 100, показанной на Фиг.1. В данном примере пользователь 110 идентифицируется на пользовательской машине 111. Пользовательская машина 111, например, может быть связана с интранетом, который включает службу директорий, такую как сервер 169 Active Directory. Идентификация пользователя 110 на пользовательской машине 111 может включать использование информации о подписи, получаемой любым известным способом, включая имя/пароль, смарткарту и т.д. Пользователь 110 затем инициирует 320 запрос на DIR, путем, например, указывания браузеру на пользовательской машине 111 веб-сайта, который содержит систему 164 генерации DIR. Пользователь 110 затем идентифицируется 330 в системе 164 генерации DIR. В некоторых реализациях пользовательская машина 111, система 164 генерации DIR, хранилище 168 идентификационных данных, провайдер 115 идентификации и система 160 администрирования могут быть частью одной и той же внутренней сети. В некоторых реализациях возможна лишь одна подпись. Например, если на пользовательской машине запускается операционная система WINDOWS, поставляемая корпорацией Майкрософт из Редмонда, штат Вашингтон, и в ней включена опция интегрированной идентификации (Windows Integrated Authentication), то идентификация в системе 164 генерации DIR может быть автоматической и беспроблемной для пользователя 110. Информация, используемая для входа в пользовательскую машину 111, передается на систему 164 генерации DIR вместе с запросом на доступ. В других реализациях администратор может сконфигурировать систему 164 генерации DIR, чтобы затребовать отдельную идентификацию пользователя 110. Администратор может сконфигурировать систему 164 генерации DIR, чтобы требовать любой из множества идентификационных механизмов, включая имя/пароль, смарткарту и т.д. В некоторых реализациях пользователь 110 может быть идентифицирован сервером IIS 166, который может легко быть сконфигурирован администратором для принятия любого из различных идентификационных методов.

Как только пользователь 110 идентифицирован, система 164 генерации DIR получает доступ 350 к хранилищу 168 идентификационных данных. В этом примере система 164 генерации DIR принимает форму веб-сервиса, чтобы позволить переговоры между системой генерации DIR и пользователем 110. В данном примере переговоры определяют тип DIR, который будет возвращен пользователю 110. В этом случае система 164 генерации DIR получает 350 имеющиеся в наличии дескрипторы DIR. В примерах реализаций администратор использует систему 160 администрирования для создания дескрипторов DIR. Например, корпоративный системный администратор может создавать дескрипторы, которые представляют различные DIR для сотрудников различных уровней. Частично занятый сотрудник, например, может иметь набор запросов, отличающийся от набора у полностью занятого сотрудника. Исполнительный директор может иметь набор запросов, отличающийся от набора остальных сотрудников. Даже картинки, которые ассоциируются с каждым дескриптором DIR, могут различаться - например, для отдела продаж картинка в DIR может быть оранжевой, в то время как для отдела бухгалтерии картинка может быть зеленой. Кроме того, возможно персонализировать картинку на карте, которая содержит картинку пользователя 110 (полученную из хранилища 168 данных идентификации). Это улучшает связь, которую пользователь 110 формирует между его/ее DIR и провайдером 115 идентификации. Это также обеспечивает лучшую способность "отпечатков пальцев".

В некоторых реализациях система 160 администрирования включает пользовательский интерфейс, который анализирует все имеющиеся в наличии типы информации, имеющиеся в хранилище 168 идентификационных, данных и представляет администратору легкую возможность создания дескрипторов. Например, администратору может быть дан список с: (a) классами пользователей (например, не полностью занятый сотрудник, полностью занятый сотрудник, сотрудник исполнительной команды, сотрудник отдела продаж и т.д.), (b) типами запросов (имя, адрес, телефонный номер, возраст и т.д.); (c) уровень доступа; (d) положение в компании (действующий сотрудник, уволенный сотрудник); и т.д. Администратор затем может решить создавать некоторые отличительные дескрипторы, доступные для некоторых или всех классов пользователей. Например, все пользователи могут иметь право получить базовый DIR, который включает имя пользователя, его телефонный номер и положение в компании. Однако, только исполнительная команда может иметь право получить DIR, которое также включает высокоуровневый уровень доступа. Эти дескрипторы могут быть созданы администратором и сохранены в хранилище идентификационных данных вместе с политикой, описывающей, каким пользователям разрешено получать DIR, соответствующие конкретным дескрипторам. Возможные команды, которые могут быть полезными для администратора при менеджменте дескрипторов, включают в себя: "ПОЛУЧИТЬ ДЕСКРИПТОР, ПОЛУЧИТЬ ВСЕ ДЕСКРИПТОРЫ, ДОБАВИТЬ ДЕСКРИПТОРЫ, ИЗМЕНИТЬ ДЕСКРИПТОРЫ, УДАЛИТЬ ДЕСКРИПТОРЫ, СКОПИРОВАТЬ ДЕСКРИПТОР B и т.д.".

Запрос пользователя 110 на доступные дескрипторы может быть выполнен на пользовательской машине 111 через веб-сервис, такой, как "ПОЛУЧИТЬ ДЕСКРИПТОРЫ". Это приведет к тому, что система генерации DIR проверит пользователя в соответствии с политикой, установленной администратором, чтобы определить какие из дескрипторов (если