Результат интеллектуальной деятельности: АУТЕНТИФИКАЦИЯ У ПОСТАВЩИКА ИДЕНТИФИКАЦИОННОЙ ИНФОРМАЦИИ

Настоящее изобретение относится к управлению процессами установления идентичности и доступа к услугам.

Посредничество при установлении идентичности представляет собой подход, применяемый для выполнения процесса единой регистрации, в рамках которого клиент не должен непосредственно предоставлять поставщику услуг аутентификационную информацию. На фиг.1 показана система, обозначенная номером 1 и состоящая из клиента 2, поставщика 4 услуг (SP) и поставщика 6 идентификационной информации (IDP). В системе 1 поставщик 4 услуг получает от поставщика 6 идентификационной информации подтверждение аутентификации, содержащее идентификатор пользователя, специфичный для поставщика услуг, и поставщик услуг (при условии, что подтверждение аутентификации относится к существующему пользователю поставщика 4 услуг) предоставляет персонализированную услугу клиенту 2.

На фиг.2 показана последовательность сообщений, обозначенная номером 10, которая может использоваться для предоставления аутентификационной информации пользователя поставщику 4 услуг. Последовательность 10 передачи сообщений реализована согласно протоколу языка разметки для систем обеспечения безопасности (SAML, Security Assertion Markup Language). Язык SAML представляет собой вариант стандарта XML (extensible Markup Language, расширяемый язык разметки) для обмена данными аутентификации и авторизации между защищенными доменами. Например, SAML используется для обмена данными о подтверждении между поставщиком идентификационной информации (формирователем подтверждений) и поставщиком услуг (потребителем подтверждений). SAML представляет собой спецификацию, разработанную организацией OASIS (Organization for the Advancement of Structured Information Standards, организация по продвижению стандартов для структурированной информации).

Выполнение последовательности 10 передачи сообщений начинается клиентом 2, который передает поставщику 4 услуг запрос 12 HTTP, с запросом доступа к защищенному ресурсу на стороне поставщика услуг. В ответ на запрос 12 поставщик 4 услуг передает клиенту сообщение 14 переадресации в формате HTTP с указанием клиенту получить полномочия у конкретного поставщика идентификационной информации. Затем браузер пользователя передает запрос 16 аутентификации по протоколу SAML поставщику 6 идентификационной информации, указанному в сообщении 14 переадресации.

В ответ на запрос 16 поставщик 6 идентификационной информации возвращает сообщение 18 переадресации в формате HTTP, содержащее информацию о запрошенном подтверждении SAML. Далее клиент 2 передает поставщику 4 услуг ответ 20 на запрос аутентификации в формате SAML, содержащий подтверждение в формате SAML, полученное от поставщика 6 идентификационной информации. После проверки поставщиком 4 услуг подтверждения, полученного в формате SAML, этот поставщик предоставляет пользователю доступ к запрошенному защищенному ресурсу и передает клиенту 2 ответ 22 по протоколу HTTP.

Последовательность 10 сообщений, описанная выше со ссылкой на фиг.2, представляет собой один из множества механизмов, которые могут использоваться для предоставления пользовательских полномочий поставщику 4 услуг. Специалист в этой области техники должен быть осведомлен о множестве других альтернатив, включая, например, механизмы, соответствующие протоколам общей архитектуры начальной загрузки (GBA, Generic Bootstrapping Architecture), OpenID и Windows® CardSpace.

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

На фиг.3 показана блок-схема системы, обозначенной номером 30, в рамках которой осуществляется попытка объединить преимущества доступа к услугам посредством персонального компьютера (высокая производительность, хорошее качество отображения и т.д.) и преимущества, которые в этом процессе обеспечивают устройства мобильной связи (надежная аутентификация). Система 30 содержит клиентское устройство 32 (такое как персональный компьютер), сеть 34 (например, Интернет), поставщика 36 услуг, пользовательское оборудование (UE, user equipment) 38, сеть 40 мобильной связи и модуль 42 аутентификации.

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

Клиентское устройство 32 для подключения к поставщику 36 услуг использует Интернет 34 (с помощью браузера клиентского устройства). Для доступа к услугам, предоставляемым поставщиком 36 услуг, клиентское устройство пользователя должно быть идентифицировано. Поставщик 36 услуг может получить идентификационную информацию от модуля 42 аутентификации.

Для предоставления аутентификационной информации модуль 42 аутентификации и/или поставщик 36 услуг должен быть уверен в том, что один и тот же пользователь работает как с UE 38, так и с клиентским устройством 32. Один из подходов заключается в посылке модулем 42 аутентификации одноразового пароля (ОТР, one-time password) в UE 38 по сети 40 мобильной связи (например, в виде SMS-сообщения). Пользователь вводит этот пароль в клиентском устройстве 32, для того чтобы продемонстрировать, что один и тот же пользователь применяет как UE (на котором пользователем принимается ОТР), так и клиентское устройство (с которого ОТР вводится пользователем). Однако такая схема неудобна для пользователя, поскольку требует выполнения ряда шагов. Кроме того, применение SMS не безопасно.

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

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

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

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

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

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

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

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

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

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

Таким образом, по меньшей мере некоторые варианты осуществления настоящего изобретения позволяют реализовать новую схему аутентификации, основанную на безопасной аутентификации устройства мобильной связи (или пользовательского оборудования, UE). Эта реализация может быть в какой-то мере менее надежной по сравнению с механизмом 3GPP-GBA, который, как правило, не используется, поскольку операторы обычно не могут предоставить или не обеспечивают серверы с функцией самонастройки (BSF, bootstrapping server function), а большинство устройств мобильной связи не поддерживают 3GPP-GBA. Однако настоящее изобретение может использоваться с устройствами мобильной связи широкого спектра без необходимости модификации или установки новых элементов (за исключением программного обеспечения управления идентификацией) в сети оператора. Более низкий уровень безопасности объясняется тем, что реализация настоящего решения зависит от совместно используемого секретного ключа R ("первая ссылка") или от соединения HTTPS/TLS между поставщиком идентификационной информации и клиентом, в то время как в рамках решения 3GPP-GBA совместно используемый секретный ключ (К) генерируется как в клиенте, так и в BSF и никогда не передается по сети. Тем не менее, несмотря на такое уменьшение уровня безопасности окончательное решение по меньшей мере настолько же безопасно, насколько широко используемые в настоящее время решения, основанные на SMS, для выполнения банковских транзакций (согласно которым совместно используемый секретный ключ (пароль) передается по SMS). Фактически настоящее решение более безопасно по сравнению с используемыми в настоящее время решениями, основанными на SMS, поскольку в последнем случае длина пароля обычно составляет менее 10 символов (примерно, 60-битовая энтропия для алфавитно-цифровых паролей длиной 10 символов), в то время как совместно используемый секретный ключ, применяемый в настоящем решении, может быть произвольной длины (128 битов в приведенных ниже примерах, но безусловно легко могут быть реализованы решения с использованием других размеров пароля).

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

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

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

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

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

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

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

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

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

Аутентификационная информация может переадресовываться от клиента поставщику услуг.

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

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

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

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

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

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

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

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

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

На фиг.2 показана последовательность сообщений, иллюстрирующая пример использования системы, изображенной на фиг.1.

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

На фиг.4 показана блок-схема системы для предоставления пользовательских полномочий в соответствии с аспектом осуществления настоящего изобретения.

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

На фиг.4 показана блок-схема системы, обозначенной с помощью цифровой ссылки 50, в соответствии с аспектом осуществления настоящего изобретения. Система 50 содержит клиентское устройство 52 (например, персональный компьютер или другое устройство, на котором установлен подходящий браузер), UE 53, поставщика 54 услуг, поставщика 56 идентификационной информации, действующего в пределах домена оператора 58 связи (например, оператора сети мобильной связи), и сервер 59 аутентификации, авторизации и учета (ААА, Authentication, Authorization and Accounting), также находящийся в домене оператора 58.

Клиентское устройство 52 находится в режиме двухсторонней связи с UE 53, поставщиком 54 услуг и поставщиком 56 идентификационной информации. Клиент запрашивает доступ к услуге, предоставляемой поставщиком 54 услуг. Поставщик 56 идентификационной информации используется для предоставления пользователю полномочий в клиентском устройстве 52. Пользователь клиентского устройства 52 также использует устройство UE 53, с помощью которого осуществляется доступ к сети, поддерживаемой оператором 58 связи, при этом UE 53 находится в режиме двухсторонней связи с поставщиком 56 идентификационной информации и сервером 59 ААА (а также с клиентом 52).

Поставщик 56 идентификационной информации находится в режиме двухсторонней связи с сервером 59 ААА и использует этот сервер для идентификации пользователя UE 53.

На фиг.5 показана последовательность сообщений, обозначенная с помощью цифровой ссылки 60, иллюстрирующая пример использования системы 50 в соответствии с аспектом осуществления настоящего изобретения.

Передача последовательности 60 сообщений начинается клиентом 52, которое передает поставщику 54 услуг запрос 61 (обычно запрос HTTP), с помощью которого запрашивается доступ к защищенному ресурсу на стороне поставщика услуг. В ответ на запрос 61 поставщик услуг генерирует сообщение 62 переадресации (например, сообщение переадресации HTTP), с помощью которого клиент 52 информируется о необходимости получения полномочий у конкретного поставщика идентификационной информации (то есть у поставщика 56 идентификационной информации). В ответ на сообщение 62 переадресации клиент 52 передает сообщение 63 поставщику 56 идентификационной информации для поиска подробной информации об аутентификации, требуемой для доступа к услуге, предоставляемой поставщиком 54 услуг. Сообщение 63 может, например, представлять собой сообщение HTTP или HTTPS.

После приема сообщения 63 поставщик 56 идентификационной информации определяет, что клиентское устройство 52 не аутентифицировано в поставщике идентификационной информации и отвечает на сообщение 63 передачей сообщения 64, с запросом клиентскому устройству самостоятельно пройти аутентификацию в соответствии с требованиями поставщика 56 идентификационной информации. Сообщение 64 содержит ссылку R, описываемую ниже.

Сообщение 64 может передаваться в виде специального ответа HTTP, который распознается в клиенте 52 с помощью расширения браузера. Расширение также может размещаться в ответе HTTP (например, в виде HTML-страницы, содержащей Java-апплет или подключаемый модуль Active-X).

Ответ 64 на запрос аутентификации может передаваться в формате неавторизованного ответа 401 HTTP (HTTP 401 Unauthorized response), в котором поле области (realm) заголовка WWW-Authenticate содержит специфические строки, такие как:

НТТР/1.1 401 Unauthorized

…

WWW-Authenticate: Digest

realm=subscriber@op.com/idp/authn

nonce="2f912500331194eca44daefeba0df871"…

где 128-битовое шестнадцатеричное временное значение (nonce) является ссылкой R, которая обсуждается ниже. Специальное значение realm инициирует выполнение клиентом 52 оставшейся последовательности 60 сообщений.

После приема сообщения 64 клиент 52 передает в UE 53 сообщение 66, в котором UE инструктируют установить связь с поставщиком 56 идентификационной информации для уведомления поставщика идентификационной информации о том, что пользователь клиента 52 использует также устройство UE 53, пользователь которого уже известен серверу 59 ААА. Сообщение 66 содержит ссылку R, которая была предоставлена поставщиком 56 идентификационной информации. Таким образом, UE 53 получает ссылку R.

В ответ на получение сообщения 66 устройство UE 53 передает поставщику 56 идентификационной информации сообщение 68. Сообщение 68 содержит ссылку R, которая была включена в сообщения 64 и 66, описанные выше. Ссылка R используется поставщиком 56 идентификационной информации для сопоставления запроса 68, полученного от UE 53, с запросом 63 аутентификации, принятым ранее от клиента 52.

Сообщение 66, переданное от клиента 52 в UE 53, может содержать следующий адрес URL:

https://p.com/idp/authn/2f912500331194eca44daefeba0df871,

в котором ссылка R (в данном примере 2f912500331194eca44daefeba0df871) является частью URL.

С помощью сообщения 68 устройство UE 53 может осуществлять связь с поставщиком идентификационной информации по указанному выше URL и, таким образом, уведомлять поставщика идентификационной информации о том, что UE 53 проинформировано о ссылке R и, следовательно, должно быть связано с пользователем клиентского устройства 52. Схема HTTPS используется в URL для обеспечения более высокого уровня безопасности, однако если разработчик доверяет способу кодирования в радиоинтерфейсе между UE и сетью оператора, то может использоваться протокол HTTP.

На этом этапе поставщик 56 идентификационной информации может определить по ссылке R, что с клиентом 52 и UE 53 работает один и тот же пользователь. Далее на шаге 70 поставщик идентификационной информации извлекает идентификатор пользователя UE 53 из сервера 59 ААА. Этот идентификатор пользователя обычно является внутренним идентификатором (например, IMSI, MSISDN). Поставщик 56 идентификационной информации может выполнять поиск идентификатора пользователя на основе исходного IP-адреса или получать его в виде подтвержденного идентификатора в заголовке HTTP.

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

В ответ на запрос 68 поставщик 56 идентификационной информации передает ответ 72 в UE 53 (источник запроса 68), и UE 53 возвращает ответ клиенту 52 (ответ 74). Затем клиент 52 передает следующий запрос (запрос 76 доступа) поставщику идентификационной информации.

Теперь поставщик идентификационной информации знает идентификационную информацию клиента 52, и, таким образом, он может ответить клиенту 52 на запрос 76 доступа путем передачи подтверждения 78 аутентификации. Подтверждение передается от клиента 52 поставщику 54 услуг в виде сообщения 80. После приема сообщения 80 поставщик 54 услуг проверяет подтверждение, а затем предоставляет запрошенную услугу пользователю 52 (сообщение 82).

Последовательность сообщений 72, 74 и 76, как описывается ниже, может быть реализована в различных формах.

В одном из вариантов осуществления настоящего изобретения ответ 72, переданный от поставщика 56 идентификационной информации в UE 53, содержит секретное значение S (которое фактически является другим временным значением):

НТТР/1.1 200 OK

…

Content-Type: text/plain

Content-Length: 32

465b5ce8b199b49faa5f0a2ee238a6bc,

где 128-битовое шестнадцатеричное временное значение (465b5ce8bl99b49faa5f0a2ee238a6bc) является секретным значением S.

Клиент 52 снова обращается к поставщику идентификационной информации с помощью сообщения 76, содержащего запрос доступа к поставщику услуг, таким же образом, как и при передаче запроса 63.

В сообщении 76 при повторном обращении к поставщику идентификационной информации этот запрос должен быть связан с первым запросом клиента (сообщение 63). Это может быть выполнено, например, путем включения в запрос ссылки R.

GET/idpHTTP/1.1

Host: op.com

…

Authorization: Digest username=""

realm="subscriber@op.com/idp/authn"

nonce="2f912500331194eca44daefeba0df871" responses"…"

…,

где значение nonce снова выступает в роли ссылки R, значение username (имя пользователя) намеренно оставлено пустым, а значение response (ответ) рассчитывается на основе этого пустого значения username и секретного значения S, рассматриваемого в качестве пароля, посредством алгоритма HTTP Digest для расчета ответа согласно RFC 2617 (см., например, www.ietf.org/rfc/rfc2617.txt). Поставщик идентификационной информации затем может проверить аутентичность этого запроса путем сравнения значения response с совместно используемым секретным значением S (производя те же вычисления, что и клиент 52).

В альтернативном варианте осуществления настоящего изобретения, если, например, соединение между клиентом 52 и поставщиком 56 идентификационной информации является защищенным, например, в соответствии с HTTPS, то последовательность сообщений 72, 74 и 76 может быть упрощена следующим образом.

На шаге 70 поставщик 56 идентификационной информации при приеме запроса 68 от UE уверен, что пользователь, установивший исходное соединение (сообщение 63), является тем же пользователем, что и владелец UE 53, поскольку ссылка R (временное значение) в данном случае играет роль совместно используемого секретного ключа. Поэтому поставщик идентификационной информации не должен возвращать другой совместно используемый секретный ключ (обсуждавшееся выше временное значение S); достаточно передать ответ с информацией HTTP 200 OK, не содержащий полезной нагрузки.

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

Независимо от реализации шагов 72, 74 и 76 запрос 76 передается поставщику 56 идентификационной информации, и поставщик идентификационной информации отвечает на этот запрос в соответствии с протоколом SAML. В сообщении 78 клиенту 52 возвращается подтверждение аутентификации для запрошенной услуги. Затем клиент 52 переадресовывает подтверждение поставщику услуг в виде сообщения 80, и поставщик услуг предоставляет запрошенную услугу (сообщение 82) таким образом, как это описано выше.

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

В приведенном выше примере указывается, что сообщение 68, содержащее ссылку R, передается от UE 53 поставщику 56 идентификационной информации. Это не существенно для всех вариантов осуществления настоящего изобретения. Например, сообщение 68 может передаваться в другое устройство, которому доверяет поставщик идентификационной информации. Это другое устройство может сравнивать ссылку, переданную от поставщика 56 идентификационной информации в клиент 52 (в сообщении 64), и информировать поставщика идентификационной информации о результатах сравнения ссылок. Для предоставления пользовательских полномочий клиенту 52 поставщик 56 идентификационной информации должен иметь достоверную информацию о том, что один и тот же пользователь работает с клиентом и UE; для этого сравниваются описанные выше ссылки, однако для осуществления настоящего изобретения не важно, выполняет ли это сравнение непосредственно поставщик идентификационной информации.

Следует также отметить, что использование протокола SAML, согласно которому была описана последовательность 60 сообщений, не является существенным требованием для реализации настоящего изобретения. Например, после извлечения на шаге 70 идентификатора пользователя поставщик идентификационной информации может просто вернуть клиенту 52 информацию о пользовательских полномочиях, требуемую поставщику 56 услуг, не ожидая дополнительного запроса (таким образом, шаги 72, 74 и 76 последовательности передачи сообщений могут не выполняться). Кроме того, после нахождения на шаге 70 идентификатора пользователя поставщик идентификационной информации может просто вернуть непосредственно поставщику услуг информацию о пользовательских полномочиях, требуемую поставщику 56 услуг (таким образом, шаги 72, 74 и 76 последовательности 60 передачи сообщений могут не выполняться, сообщение 78 может передаваться поставщику услуг вместо (или дополнительно) клиента, и может не выполняться шаг 80 последовательности передачи сообщений).

Как описано выше, клиент 52 передает сообщение 66 с требованием к UE 53 обратиться к поставщику 56 идентификационной информации. Сообщение 66 может передаваться от клиента 52 в UE 53 одним из указанных ниже способов. Ниже рассматривается ряд вариантов, хотя специалисту в этой области техники должны быть очевидны альтернативные варианты, которые можно использовать.

В одном из вариантов осуществления настоящего изобретения сообщение 64 содержит веб-адрес поставщика 56 идентификационной информации. Адрес содержит также ссылку R, например, в виде параметра URL. В сообщении 66 этот адрес передается в UE стандартными средствами Bluetooth (OBEX). В сообщении 68 устройство UE пересылает адрес с использованием сотового доступа (например, GPRS, 3G и т.д.).

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

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

В другом альтернативном варианте доступ к UE осуществляется не через Bluetooth, а с помощью других средств установления соединений на короткие расстояния, например, с помощью инфракрасного соединения.

Таким образом, соединение между клиентом 52 и UE 53 может устанавливаться различными способами, множество из которых являются безопасными, например, на основе соединения Bluetooth, кабельного соединения, шифрования и аутентификации данных в случае WLAN и т.д.

В еще одном альтернативном варианте принятый запрос аутентификации (сообщение 64) содержит телефонный номер (например, так называемый номер услуги, такой как *1234567890#). В самом номере закодирована ссылка R, то есть номер является уникальным для запроса. При передаче сообщения 66 выполняются следующие шаги.

- Клиент 52 по каналу USB (или с помощью некоторого другого соединения) инструктирует UE 53 выполнить вызов по этому номеру.

- UE 53 выполняет вызов.

- Осуществляется обращение к поставщику 56 идентификационной

информации с помощью сетевой функции, обрабатывающей

вызов.

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

- Клиент 52 по каналу USB (или с помощью Bluetooth либо некоторого другого соединения) инструктирует UE 53 выполнить вызов по этому телефонному номеру.

- UE 53 выполняет вызов.

- Клиент 52 инструктирует UE 53 передать цифры номера R в виде последовательности DTMF (двухтональной многочастотной последовательности) (или в каком-либо ином виде).

- UE 53 передает последовательность DTMF.

- Осуществляется обращение к поставщику 56 идентификационной информации с помощью сетевой функции, обрабатывающей вызов.

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

Следует отметить, что в вариантах осуществления настоящего изобретения могут объединяться две или более схемы, описанные выше (например, веб-ссылка, соединение через USB, вызов через Bluetooth и т.д.).

Связь между клиентом 52 и UE 53 может выполняться различным образом. Например, связь между клиентом 52 и UE 53 может быть основана на совместно используемых файлах, при условии, что UE также может быть доступен клиенту в виде хранилища данных через USB-соединение (или некоторое другое соединение); или UE может также представлять собой телефон в виде платы, который физически может быть подключен к клиенту.

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