Маркеры безопасности, включающие в себя отображаемые утверждения

Маркеры безопасности, включающие в себя отображаемые утверждения

Иллюстрации

Показать все

Реферат

Уведомление об авторском праве

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

Уровень техники

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

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

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

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

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

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

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

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

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

Описание чертежей

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

Фиг.1 иллюстрирует примерную систему с цифровой идентификационной информацией;

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

Фиг.3 иллюстрирует часть системы на фиг.1;

Фиг. 4 иллюстрирует другую часть системы на фиг.1;

Фиг.5 иллюстрирует примерный маркер безопасности;

Фиг.6 иллюстрирует примерную вычислительную систему, запрограммированную, чтобы интерпретировать и отображать отображаемый маркер маркера безопасности;

Фиг.7 иллюстрирует другую часть системы на фиг.1;

Фиг.8 иллюстрирует примерный способ аутентификации участника;

Фиг.9 иллюстрирует примерный способ интерпретации и отображения отображаемого маркера маркера безопасности;

Фиг.10 иллюстрирует примерный пользовательский интерфейс для отображения отображаемого маркера маркера безопасности и

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

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

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

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

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

Также на фиг.1 показаны преобразователь 130 заявлений (утверждений) и полномочный центр 140 заявлений (утверждений) (иногда называемый службой маркеров безопасности или "STS"). В показанном примере преобразователь 130 заявлений и полномочный центр 140 утверждений являются одним или более объектами, которые могут предоставить одно или более заявлений (утверждений) или суждений об участнике. Заявление является утверждением, сделанным об участнике, относящимся к идентичности участника или информации об участнике, такой как, например, имя, адрес, номер социального страхования, возраст и т.д. Как дополнительно описано ниже, преобразователь 130 заявлений и полномочный центр 140 утверждений могут предоставлять заявления участнику 110 и/или проверяющей стороне 120 в форме подписанного маркера безопасности.

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

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

В примерных вариантах осуществления, раскрытых в данном документе, система 100 осуществлена как система InfoCard, предоставленная в интерфейсе прикладного программирования WINFX, разработанном корпорацией Microsoft из Редмонда, штат Вашингтон. Система InfoCard позволяет принципалам управлять многочисленными цифровыми идентичностями (идентификационными данными) из различных полномочных центров утверждений.

Система InfoCard использует платформу веб-служб, такую как Windows Communication Foundation в интерфейсе прикладного программирования WINFX. Кроме того, система InfoCard построена с использованием спецификаций безопасности веб-служб, распространяемых, по меньшей мере частично, корпорацией Microsoft из Редмонда, штат Вашингтон. Эти спецификации включают в себя модель WS-Security безопасности сообщений, политику WS-Security Policy конечной точки, протокол WS-MetadataExchange метаданных и модель WS-Trust доверия. Как правило, модель WS-Security описывает как присоединить маркеры безопасности к сообщениям. Модель WS-SecurityPolicy описывает требования политики конечной точки, такие как требуемые маркеры безопасности и поддерживаемые алгоритмы шифрования, осуществленные с помощью протокола метаданных WS-MetadataExchange. Модель WS-Trust описывает инфраструктуру моделей доверия, которая разрешает взаимодействовать различным веб-службам.

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

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

Система 200 включает в себя процессор 202, системное запоминающее устройство 204 и системную шину 206, которая соединяет различные системные компоненты, в том числе системное запоминающее устройство, с процессором 204. Системная шина 206 может быть любой из нескольких типов шинных структур, включающих в себя шину памяти, периферийную шину и локальную шину, использующую любую из многообразия шинных архитектур. Системное запоминающее устройство включает в себя постоянное запоминающее устройство (ROM) 208 и оперативное запоминающее устройство (RAM) 210. Базовая система 212 ввода-вывода (BIOS), содержащая в себе базовые процедуры, которые помогают передавать информацию между элементами в рамках вычислительной системы 200, сохранена в ROM 208.

Вычислительная система 200 дополнительно включает в себя накопитель 212 на жестких дисках для считывания и записи на жесткий диск, накопитель 214 на магнитных дисках для считывания и записи на сменный магнитный диск 216 и накопитель 218 на оптических дисках для считывания и записи на сменный оптический диск 219, например, CD-ROM или другие оптические носители. Накопитель 212 на жестких дисках, накопитель 214 на магнитных дисках и накопитель 218 на оптических дисках подключены к системной шине 206 посредством интерфейса 220 накопителя на жестких дисках, интерфейса 222 накопителя на магнитных дисках и интерфейса 224 накопителя на оптических дисках, соответственно. Накопители и ассоциативно связанные с ними машиночитаемые носители обеспечивают энергонезависимое хранение машиночитаемых команд, структур данных, программных модулей и других данных для вычислительной системы 200.

Хотя примерное окружение, описанное в данном документе, может использовать жесткий диск 212, сменный магнитный диск 216 и сменный оптический диск 219, в примерной системе 200 могут быть использованы другие типы машиночитаемых носителей, допускающих сохранение данных. Примеры этих других типов машиночитаемых носителей, которые могут быть использованы в примерном операционном окружении, включают в себя магнитные дискеты, карты флэш-памяти, цифровые видеодиски, картриджи Бернулли, оперативные запоминающие устройства (RAM) и постоянные запоминающие устройства (ROM).

Ряд программных модулей может быть сохранен на жестком диске 212, магнитном диске 216, оптическом диске 219, в ROM 208 или RAM 210, в том числе операционная система 226, например операционная система WINDOWS от Microsoft Corporation, одна или несколько прикладных программ 228, другие программные модули 230 и программные данные 232.

Пользователь может вводить команды и информацию в вычислительную систему 200 посредством устройств ввода, таких как, например, клавиатура 234, мышь 236 или другое указательное устройство. Примеры других устройств ввода включают в себя панель инструментов, меню, сенсорный экран, микрофон, джойстик, игровой планшет, перо, спутниковую антенну и сканер. Эти и другие устройства ввода часто подключены к процессору 202 через интерфейс 240 последовательного порта, который соединен с системной шиной 206. Тем не менее, эти устройства ввода могут быть подключены посредством других интерфейсов, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB). ЖК-дисплей 242 или другой тип дисплейного устройства также подключен к системной шине 206 посредством интерфейса, такого как видеоадаптер 244. Помимо дисплея 242 вычислительные системы в типичном варианте могут включать в себя другие периферийные устройства вывода (не показаны), такие как динамики и принтеры.

Вычислительная система 200 может работать в сетевом окружении, использующем логические соединения с одним или более удаленными компьютерами, такими как удаленный компьютер 246. Удаленным компьютером 246 может быть персональный компьютер, сервер, маршрутизатор, сетевой ПК, одноранговое устройство или другой общий узел сети, и в типичном варианте включает в себя многие или все элементы, описанные выше относительно вычислительной системы 200. Логические соединения включают в себя локальную вычислительную сеть (LAN) 248 и глобальную вычислительную сеть (WAN) 250. Такие сетевые окружения являются обычными в офисах, корпоративных вычислительных сетях, сетях интранет (локальных сетях, использующих технологии Интернет) и Интернет.

Когда используется в сетевом окружении LAN, вычислительная система 200 подключена к локальной сети 248 посредством сетевого интерфейса или адаптера 252. Когда использована в сетевом окружении WAN, вычислительная система 200 в типичном варианте включает в себя модем 254 или другое средство для установления связи по глобальной вычислительной сети 250, такой как Интернет. Модем 254, который может быть внутренним или внешним, подключен к системной шине 206 посредством интерфейса 240 последовательного порта. В сетевом окружении программные модули, показанные относительно вычислительной системы 200, или их части могут быть сохранены в удаленном запоминающем устройстве хранения. Следует принимать во внимание, что показанные сетевые соединения являются примерными, и другие средства установления линии связи между компьютерами могут быть использованы.

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

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

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

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

<sp:IssuedToken …>

<sp:RequestSecurityTokenTemplate> <wst:TokenType>

urn:oasis:names:tc:SAML:1.0:assertion </wst:TokenType>

<wst:Claims wst:

Dialect="http://schemas.microsoft.com/ws/2005/05 http://.../ws/2005/05/identity/claims/givenname7 http://schemas.microsoft.com/ws/2005/05/identithttp://http://http://.../ws/2005/05/identity/claims/surname/identity">

<ic: Claim

URI= ">

</wst:Claims> </sp:RequestSecurityTokenTemplate>

</sp:IssuedToken>

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

- Имя - Тип: xs:string - предпочитаемое имя или имя субъекта;

- Фамилия - Тип: xs:string - прозвище или фамилия субъекта;

- Адрес электронной почты - Тип: xs:string - предпочитаемый адрес для поля "Кому:" электронного письма, которое должно быть отправлено субъекту, как правило, в форме <пользователь>@<домен>;

- Адрес улицы - Тип: xs:string - компонент адреса улицы адресной информации субъекта;

- Наименование района - или город - Тип: xs:string - компонент района адресной информации субъекта;

- Штат или область - Тип: xs:string - аббревиатура для названия штата или области адресной информации субъекта;

- Почтовый код - Тип: xs:string - компонент почтового кода или почтового индекса адресной информации субъекта;

- Страна - Тип: xs:string - страна субъекта;

- Основной номер или номер домашнего телефона - Тип: xs:string - основной номер или номер домашнего телефона субъекта;

- Дополнительный номер или номер рабочего телефона - Тип: xs:string - дополнительный номер или номер рабочего телефона субъекта;

- Номер мобильного телефона - Тип: xs:string - номер мобильного телефона субъекта;

- Дата рождения - Тип: xs:date - дата рождения субъекта в форме, разрешенной типом данных xs:data;

- Пол - Тип: xs:token - пол субъекта, который может иметь любое из этих строгих строковых значений - "мужской", "женский" или "не указан"; и

- Личный персональный идентификатор - Тип: xs:base64binary - указывает личный идентификатор, который идентифицирует субъект для проверяющей стороны.

Политика может также использоваться для задания типа маркера безопасности, требуемого проверяющей стороной 120, или может использоваться тип по умолчанию, как определено посредством WS-Trust. Например, вышеупомянутая политика точно определяет некий тип маркера безопасности, который требуется проверяющей стороной 120 (т.е. "wstTokenType").

В дополнение к указанию требуемых утверждений и типа маркера политика безопасности может определять конкретный полномочный центр утверждений, требуемый проверяющей стороной ("sp:Issuer"), как показано ниже.

<sp:IssuedToken sp:Usage= "xs:anyURI" sp:IncludeToken= "xs:anyURI" …> <sp:Issuer>

<wsa:EndpointReference>…</wsa:EndpointReference>

</sp:Issuer> <sp:RequestSecurityTokenTemplate>

</sp:RequestSecurityTokenTemplate> <wsp:Policy>

</wsp:Policy>

</sp: IssuedToken>

Политика может пропустить этот элемент, оставляя определение соответствующего полномочного центра утверждений принципалу.

Другие элементы могут быть заданы (определены) в политике безопасности, так же как и, например, "свежесть" требуемого маркера безопасности.

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

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

Пример запроса маркера безопасности предоставлен ниже.

<wst:RequestSecurityToken> <wst:TokenType>

urn:oasis:names:tc:SAML: 1.0:assertion </wst:TokenType>

<wst:Claims wst:

Dialect= "y">

<ic:Claim

URI= ".../ws/2005/05/identity/claims/givenname7>

</wst:Claims> </wst:RequestSecurityToken>

В примерных вариантах осуществления полномочный центр 140 утверждений может иметь свою собственную политику безопасности, как определено в WS-SecurityPolicy, и требовать аутентификации принципала 110 перед тем, как полномочный центр 140 утверждений передает маркер безопасности принципалу 110.

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

Маркер 150 безопасности может затем быть передан принципалу 110. В примерных вариантах осуществления преобразователь 130 утверждений передает маркер 150 безопасности принципалу 110 с помощью механизмов ответа, описанных в WS-Trust.

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

Преобразователь 130 утверждений также формирует маркер 154 отображения. Как правило, маркер 154 отображения включает в себя, по меньшей мере, краткое изложение утверждений, которые включены в вычислительный маркер 152 маркера 150 безопасности. Например, в некоторых вариантах осуществления маркер 154 отображения включает в себя список всех утверждений, включенных в вычислительный маркер 152. Маркер 154 отображения может быть сформирован в формате, который может быть просмотрен принципалом 110 с помощью, например, вычислительной системы 300, как описано ниже. В некоторых примерах маркер 154 отображения сформирован в простом текстовом формате или формате на языке гипертекстовой разметки ("HTML"). Один пример варианта осуществления отображаемого маркера, включенного как часть ответа на маркер безопасности, показан ниже.

<ic:RequestedDisplayToken>

<ic:DisplayToken xml: lang=" en-us">

<ic:DisplayClaim URI=".../ws/2005/05/identity/claims/givenname">

<ic:DisplayTag>GivenName</ic:DisplayTag> <ic:DisplayValue>John</ic:DisplayValue> </ic:DisplayClaim> <ic:DisplayClaim URI="">

<ic:DisplayTag>LastName</ic:DisplayTag> <ic:DisplayValue>Doe</ic:DisplayValue> </ic:DisplayClaim> <ic:DisplayToken> </ic:RequestedDisplayToken>

Последующее описание является общим описанием элементов, показанных выше в отображаемом маркере:

- /ic:RequestedDisplayToken/ic:DisplayToken - возвращенный отображаемый маркер;

- /ic:RequstedDisplayToken/ic:DisplayToken/@xml:lang - этот атрибут указывает идентификатор языка, использующий языковые коды, определенные в RFC 3066, в которых локализовано содержимое отображаемого маркера;

- /ic:RequstedDisplayToken/ic:DisplayToken/ic:DisplayClaim - этот элемент указывает отдельное утверждение, возвращенное в маркере безопасности;

- /ic:RequstedDisplayToken/ic:DisplayToken/ic:

DisplayClaim/@URI - этот атрибут предоставляет уникальный идентификатор (URI) отдельного утверждения, возвращенного в маркере безопасности;

- /ic:RequestedDisplayToken/ic:DisplayToken/ic:

DisplayClaim/ic:DisplayTag - этот необязательный элемент предоставляет общее или понятное наименование утверждения, возвращенного в маркере безопасности;

- /ic:RequestedDisplayToken/ic:DisplayToken/ic:

DisplayClaim/ic:Description - этот необязательный элемент предоставляет описание семантики утверждения, возвращенного в маркере безопасности;

- /ic:RequestedDisplayToken/ic:DisplayToken/ic:

DisplayClaim/ic:Display Value - этот необязательный элемент предоставляет одно или более отображаемых значений утверждения, возвращенного в маркере безопасности; и

- /ic:RequestedDisplayToken/ic:DisplayToken/ic:

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

В некоторых вариантах осуществления маркер 150 безопасности, включающий в себя вычислительный маркер 152, выпускается в соответствии со стандартом языка разметки, предусматривающим защиту данных ("SAML"), опубликованным Организацией продвижения стандартов структурированной информации ("OASIS"). Например, маркер 150 безопасности может быть выпущен в соответствии со стандартами SAML 1.1 или SAML 2.0. Другие стандарты также могут использоваться, такие как, например, и без ограничения, сертификат X.509 и удостоверение Kerberos.

Кроме того, маркер 150 безопасности может быть криптографически подписан или подтвержден преобразователем 130 утверждений с помощью известного алгоритма. В одном варианте осуществления, например, и без ограничения, используется 2048-битный ассиметричный RSA-ключ. В других вариантах осуществления могут использоваться другие алгоритмы шифрования, такие как, например, base64-закодированный симметричный ключ шифрования. В одном варианте осуществления по умолчанию используется симметричный ключ. Таким образом, в показанном примере сторона, такая как проверяющая сторона 120, может криптографически подтвердить, что маркер 150 безопасности создан в преобразователе 140 утверждений.

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

Обращаясь теперь к фиг.6, примерная вычислительная система 300 принципала 110 может включать в себя интерпретатор 312 и устройство 314 отображения. Например, в иллюстрированном варианте осуществления интерпретатор 312 может быть одной или более прикладными программами (например, программами 228, описанными выше), выполняемыми вычислительной системой 300. Кроме того, устройство 314 отображения может быть устройством вывода, таким как принтер или монитор (см., например, монитор 242), которое может выводить информацию принципалу 110.

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

Обращаясь теперь к фиг. 7, принципал 110 может передать маркер 150 безопасности проверяющей стороне 120, чтобы удовлетворить всю или часть политики безопасности проверяющей стороны 120. В одном примере принципал 110 может передать маркер 150 безопасности проверяющей стороне 120, привязывая маркер 150 безопасности к сообщению приложения с помощью механизмов безопасной привязки, описанных в WS-Security.

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

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

На этапе 410 способа 400 принципал запрашивает информацию у проверяющей стороны. Например, в иллюстрированном варианте осуществления Служащий A использует прикладную программу на компьютере Служащего A, чтобы запросить туристическую поездку на веб-сайте Туристического агентства A. Далее, на этапе 420 компьютер Служащего A принимает политику безопасности с веб-сайта Туристического агентства A. Эта политика требует, чтобы Служащий A представил маркер безопасности с утверждением, устанавливающим, что Служащий A является служащим Компании A, прежде чем Служащий A может получить доступ к льготным туристическим поездкам на веб-сайте Туристического агентства A.

На этапе 430 компьютер Служащего A передает политику полномочному центру утверждений, который в настоящем примере является службой маркеров безопасности или STS, управляемой Компанией A. STS Компании A может выпустить маркер безопасности с утверждением, устанавливающим, что Служащий A является служащим Компании A. Например, утверждение может быть просто "Служащий Компании A=Истина". Далее, на этапе 440 компьютер Служащего A принимает подписанный маркер безопасности от STS Компании A. Маркер безопасности включает в себя вычислительный маркер и отображаемый маркер с вычислительным маркером, включающим в себя утверждение, устанавливающее, что Служащий A является служащим Компании A.

Управление затем передается на этап 450, и компьютер Служащего A представляет краткое изложение утверждений отображаемого маркера Служащему A для просмотра. Далее, на этапе 460 Служащий A может решить, передавать или нет маркер безопасности веб-сайту Туристического агентства A, на основе информации в отображаемом маркере, представленном Служащему A.

Например, если существует только утверждение в маркере безопасности от Компании A о том, что Служащий A является служащим Компании A (например, "Служащий Компании A = Истина"), отображаемый маркер перечислит (в виде списка) это утверждение для Служащего A для просмотра. Если Служащему A удобно открыть эту информацию Туристическому агентству A, Служащий A может передать маркер безопасности веб-сайту Туристического агентства A на этапе 465. Управление затем переходит к этапу 470, и Служащий A получает доступ к запрошенным льготным туристическим поездкам на веб-сайте Туристического агентства A.

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