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

Формула изобретения

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

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

упомянутая первая организация переадресует упомянутого пользователя на упомянутую веб-страницу упомянутой второй организации;

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

упомянутая вторая организация сообщает упомянутой первой организации о том,

что упомянутый пользователь аутентифицирован, а

упомянутая первая организация предоставляет упомянутому пользователю

разрешение на доступ в Интернет по упомянутому запросу на доступ,

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

2. Способ по п. 1, в котором упомянутое имя пользователя выражено в формате имя@область.

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

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

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

6. Способ по п. 5, в котором упомянутый шлюз определяет адрес упомянутого аутентификационного сервера с помощью запроса, отправленного в DNS.

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

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

9. Способ по п. 4, в котором кодируют обмен информацией между упомянутым шлюзом и упомянутым аутентификационным сервером.

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

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

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

13. Компьютерная система, выполненная с возможностью реализации способа по п. 1.

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

Описание изобретения к патенту

Изобретение относится к способу предоставления пользователю доступа в Интернет согласно преамбуле по п.1.

В частности, изобретение направлено на расширение возможностей пользователя по доступу в Интернет.

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

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

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

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

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

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

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

Одно из последних решений известно из патента США 5,898,780, в котором раскрывается способ и устройство, позволяющие пользователю осуществлять доступ в Интернет из удаленного места через локального провайдера Интернет-услуг, у которого нет учетной записи данного пользователя. Пользователь входит в систему локального провайдера Интернет-услуг, используя учетные данные (имя пользователя и пароль) своей учетной записи у удаленного провайдера Интернет-услуг.

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

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

Университетом Тренто используется и было публично предложено решение, получившее название Юни-фай (Uni-fy), основанное на совершенно иных принципах, отличных от предлагаемых в патенте США 5,898,780.

Согласно данному решению предполагается, что клиентское устройство пользователя отправляет запрос DHCP на шлюз университета, который затем выделяет ему IP адрес.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данное решение обладает несколькими преимуществами.

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

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

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

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

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

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

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

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

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

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

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

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

На фиг.1 показано объединение организаций (E1, E2, Е3) подключенных к Интернет 1.

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

На примере по фиг.1, организации Е1 и E2 оснащены компьютерной системой, в частности узлом сети, который содержит шлюз GW, аутентификационный сервер AS и базу данных DB, в которой хранится информация необходимая для аутентификации пользователей организации.

Шлюз GW выполняет все функции бранмаузера и фильтрует весь неавторизованный график, тогда как аутентификационный сервер AS проверяет учетные данные пользователя в базе данных DB (базе данных MySQL или LDAP или в файле с паролями) или по стандартному протоколу, такому как, например, RADIUS.

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

Организация Е1 имеет коммутатор 4, соединенный со шлюзом GW, для предоставления пользователям проводного доступа.

Организация Е3 является провайдером Интернет-услуг, у которого нет собственной сети доступа, но есть пользователи.

У данной организации имеются аутентификационный сервер AS и база данных DB, так же как и у организаций Е1 и E2; аутентификационный сервер AS подключен к Интернет через маршрутизатор RT, который в отличие от шлюза GW организаций Е1 и E2 не может осуществлять функции переадресации пользователя, описанные ниже.

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

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

Подобная ситуация может возникнуть, например, в том случае, если пользователь организации Е1 (например, сотрудник компании А) находится в аэропорту или вблизи организации (например, компании Б) и хочет получить доступ в Интернет через инфраструктуру аэропорта или компании Б.

Во время проверки пользователем 2 наличия точки доступа организации Е2 он направляет запрос DHCP, после чего ему/ей присваивается IP адрес.

В этот момент пользователь 2 может направить запрос на доступ в Интернет.

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

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

Предпочтительно подобные учетные данные состоят из имени пользователя 2 и доменного имени организации Е1, которая должна аутентифицировать пользователя 2.

Имя пользователя и название домена могут вводиться в разные поля, либо они могут быть получены шлюзом автоматически, если пользователю 2 будет предложено указать название учетной записи в формате имя@область, где «именем» является имя пользователя 2, а областью - доменное имя организации E1.

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

IP адрес аутентификационного сервера организации Е1 определяется посредством следующей иерархии правил.

Прежде всего, шлюз GW организации Е2 ставит перед названием области заданное имя (например: authserv) и направляет в DNS запрос для получения IP адреса аутентификационного сервера AS пользователя (т.е. организации 1).

Например, для пользователя mario.rossi@organizationl.it шлюз GW будет искать DNS по IP адресу authserv.organizationl.it.

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

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

Согласно следующему правилу поиск IP адреса аутентификационного сервера AS организации Е1 производится в локальной базе данных организации Е2.

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

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

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

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

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

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

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

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

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

На фиг.2:

- клиент направляет запрос на доступ в сеть, например http://www.google.it (последовательность с1),

- шлюз перехватывает запрос и переадресует клиента на аутентификационный портал (последовательность с2),

- клиент отправляет свои учетные данные, например имя пользователя (последовательность с3),

- шлюз переадресует клиента на портал аутентификационного сервера (последовательность с4),

- пользователь вводит пароль (последовательность с5),

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

- пользователь получает разрешение (последовательность с7),

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

- клиент пересылает полученное сообщение на шлюз для открытия бранмаузера (последовательность с9),

- шлюз переадресует клиента на запрошенный сайт http://www.google.it (последовательность с 10),

- клиент получает доступ к запрошенному сайту http://www.google.it (последовательность с11).

Подобная архитектура обеспечивает абсолютную расширяемость.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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