Модуль федеративной идентификации и трансляции токена для использования с web-приложением

Изобретение относится к серверу и способ обобщенной идентификации и трансляции токена безопасности. Технический результат заключается в автоматизации управления объектом безопасности. В способе создают основной объект безопасности для пользователя посредством взаимодействия с Web-приложением или информационным сервисом интернета (IIS) через модуль обобщенной идентификации и трансляции токена безопасности, получают токены аутентификации и авторизации от службы токенов безопасности (STS), принимают токен безопасности от STS для нового пользователя, извлекают сертификат уровня защищенных сокетов (SSL) из Web-приложения, который посылают в STS, удостоверяют принятый токен безопасности от STS, вызывают другую службу и принимают профиль пользователя и информацию точного доступа (FGA), соответствующую удостоверенному принятому токену безопасности, формируют основной объект безопасности из принятых профиля пользователя и FGA информации, вставляют индивидуально сконфигурированный основной объект безопасности в Web-приложение как FGA набор данных, сохраняют индивидуально сконфигурированный основной объект безопасности в кэше данных, изменяют упомянутый модуль без внесения изменений в Web-приложение или IIS. 2 н. и 18 з.п. ф-лы, 6 ил.

 

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

Настоящая заявка притязает на приоритет заявки на патент США № 14/798,617, поданной 14 июля 2015 г., содержание которой включено сюда полностью путем ссылки.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

Исторически федеративная идентификация осуществлялась с использованием прокси-сервера Web-службы и не напрямую из Web-приложения. Прокси-сервер Web-службы использовал разнообразные механизмы для получения подробного профиля и точной информации доступа (FGA) применительно к пользователю Web-приложения. Разнообразные механизмы включали в себя заголовки с идентификацией пользователя и Web-службы или базы данных. Это требовало, чтобы разработчики Web-приложений были ознакомлены с и приспосабливали множество токенов безопасности, зависящих от конкретных поставщиков, что отвлекает разработчиков от главной цели бизнес-функций Web-приложения. На фиг. 1 показан пример системы предшествующего уровня техники, в которой прокси-сервер 2 аутентификации в граничной сети, обеспечиваемой провайдером услуг доставки контента, принимает запрос на доступ от пользователей браузеров 3 по линии 4 связи. Прокси-сервер 2 аутентификации затем посылает идентификатор пользователя или зависящий от конкретного поставщика токен в HTTP заголовке в каждый соответствующий сервер 5 приложений по линии 6 связи. Это требует, чтобы каждый разработчик приложения предоставлял каждому потребительскому Web-приложению правильный код и процедуры безопасного доступа. Web-приложения также требуют от них поддержания постоянной осведомленности об изменениях безопасного доступа к Web и обновления каждого Web-приложения для размещения таких изменений. Система на фиг. 1 также приводит в результате к тому, что токен HTTP заголовка становится слишком большим и трудным для работы с ним.

ЧЕРТЕЖИ

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

ФИГ. 1 - схематическое представление системы предшествующего уровня техники;

ФИГ. 2 - блок-схема системы, включающей в себя приводимый в качестве примера модуль;

ФИГ. 3 - логическая блок-схема последовательности операций в приводимом в качестве примера способе;

ФИГ. 4 - возможный дополнительный логический этап, который может быть добавлен в логическую блок-схему на фиг. 3;

ФИГ. 5 - другой возможный дополнительный логический этап, который может быть добавлен в логическую блок-схему на фиг. 3;

ФИГ. 6 - еще один возможный дополнительный логический этап, который может быть добавлен в логическую блок-схему на фиг. 3;

Соответствующие ссылочные позиции указывают соответствующие части в нескольких видах чертежей.

ПОДРОБНОЕ ОПИСАНИЕ

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

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

На фиг. 2 приведен пример модуля 10 федеративной идентификации и трансляции токена безопасности для функционального взаимодействия с сервером 12, содержащим Web-приложение 13 и/или информационный сервис интернета (IIS). Сервер 12 может представлять либо Web-приложение, либо IIS сервер, где модуль 10 вставлен в код Web-приложения или IIS. Одно из преимуществ приводимого в качестве примера модуля 10 заключается в том, что он может быть вставлен, удален, изменен, обновлен и т.п., не требуя каких-либо изменений в Web-приложении или IIS.

Сервер 12 показан отдельно от модуля 10, чтобы подчеркнуть независимую модульную структуру модуля 10. Однако модуль 10 может находиться в сервере 12 и функционально взаимодействовать с Web-приложением или IIS. В этом отношении сервер 12 может быть описан как первый сервер, включающий в себя машиноисполняемые команды, определяющие модуль 10 федеративной идентификации и трансляции токена безопасности, для управления и обеспечения создания основного объекта безопасности для пользователя 14, запрашивающего доступ к Web-приложению через устройство 16, содержащее браузер, как показано. Устройство 16, содержащее браузер, может включать в себя любое проводное или беспроводное устройство, которое имеет связь с сетью, включая, но не в ограничительном смысле, смартфоны, планшеты, лэптоп компьютеры или специализированные устройства, спроектированные для конкретных целей, такие, например, как банкоматы (ATM) или интерактивные терминалы.

Модуль 10 федеративной идентификации и трансляции токена безопасности может включать в себя перечисленные ниже компоненты или потоки. Модуль 10 может включать в себя поток доступа для непосредственного запроса и получения токенов аутентификации и авторизации по меньшей мере от одной службы токенов безопасности (STS) 18 по каналу 20 связи, основываясь на запросе на доступ от пользователя 14 Web-приложения 13. Модуль 10 может также включать в себя поток запроса нового пользователя на токен безопасности для запрашивания и приема токена безопасности от STS 18. Дополнительно модуль 10 может включать в себя поток сертификата уровня защищенных сокетов (SSL) для извлечения SSL сертификата из Web-приложения и посылки SSL сертификата в STS 18. Кроме того, модуль 10 может включать в себя поток удостоверения для удостоверения принятого токена безопасности от STS 18.

В примере запрос пользователя на доступ может быть проложен через привязку в инфраструктуре WebSEAL™ корпорации IBM, где cookie-файл (например, LTPAv2, и т.п.) токена безопасности добавляется в запрос и посылается обратно в Web-приложение 13, и может образовать часть потока доступа. Как известно, WebSEAL™ является частью решения единой регистрации (SSO ), в котором тактика детально продуманной безопасности применяется в интернет пространстве. Привязка может быть определена как соединение между двумя серверами, например, сервером, содержащим WebSEAL™, и сервером, содержащим Web-приложение 13. Соединение может быть интернет соединением, таким как TCP/IP соединение, или оно может также быть внутри одного сервера или группы серверов, если WebSEAL™ продукт и Web-приложение расположены в одном и том же сервере или группе серверов.

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

Если пользователь является новым, поток запроса нового пользователя на токен безопасности в модуле 10 запрашивает STS, чтобы обеспечить, например, токен на языке разметки деклараций безопасности (SAML). Модуль 10 может построить двоичный токен безопасности из cookie-файла токена, упомянутого выше. Модуль 10 может затем сделать запрос на токен безопасности (RST) из STS. Затем STS удостоверяет, что запрос пользователя имеет правильный SSL сертификат, чтобы сделать запрос. SSL сертификат является тем, который извлечен из Web-приложения 13 потоком SSL сертификата в модуле 10. Если SSL сертификат является правильным, то STS удостоверяет RST и LTPAv2 информацию токена. После этого, STS формирует SAML токен для пользователя, содержащий пользовательскую информацию, и посылает его в модуль 10, где поток удостоверения удостоверяет принятый SAML токен.

После того как модуль 10 удостоверит принятый токен безопасности (например, SAML токен), поток вызова профиля пользователя в модуле 10 может вызвать STS и принять профиль пользователя и информацию точного доступа (FGA), соответствующую удостоверенному принятому токену безопасности. Заметим также, что модуль 10 может дополнительно включать в себя REST API, чтобы использовать SAML токен для просмотра дополнительных свойств, относящихся к аутентифицированному пользователю, таких как те, которые представляются в протоколе независимой компьютерной архитектуры (ICA), например, которые можно найти в приложении Citrix®. Сочетание SAML токена из STS и дополнительной информации аутентификации и авторизации, извлеченной из REST API, обеспечивает более полную картину атрибутов пользователя.

В этом варианте осуществления поток формирования в модуле 10 служит для формирования индивидуально сконфигурированного основного объекта безопасности из принятого профиля пользователя и FGA информации. Например, STS отклик, принятый потоком вызова профиля пользователя, может быть проанализирован с целью создания индивидуально сконфигурированного основного объекта безопасности. Модуль 10 может быть модулем, который вставляется, например, в платформу Microsoft® NET Framework.

Если используется платформа NET Framework, модуль 10 может включать в себя поток вставления индивидуально сконфигурированного основного объекта безопасности в Web-приложение как FGA набора данных. В этом примере поток вставления в модуле 10 заменяет ASP NET HupContext субъект индивидуально сконфигурированным основным объектом безопасности.

Как было замечено выше, модуль 10 может также включать в себя кэш данных, который хранит индивидуально сконфигурированный основной объект безопасности в долговременном машиночитаемом носителе информации, при этом кэш данных располагается в первом сервере. Кэш данных может быть любого подходящего размера и может продолжать удерживать пользовательский индивидуально сконфигурированный основной объект безопасности в течение периода времени, соответствующего спецификации и требованиям Web-приложения. Кэш данных может располагаться в сервере 12, как показано позицией 22. Модуль 10 может также включать в себя поток поиска кэша пользователя для определения того, включает ли уже в себя кэш данных индивидуально сконфигурированный основной объект безопасности для пользователя, запрашивающего доступ к Web-приложению. Если кэш данных включает в себя пользовательский индивидуально сконфигурированный основной объект безопасности, он может быть извлечен из кэша данных и вставлен в Web-приложение. Пользовательский индивидуально сконфигурированный основной объект безопасности в кэше данных может быть также обновлен в это время.

Одним из главных преимуществ настоящего примера является то, что модуль 10 федеративной идентификации и трансляции токена безопасности может быть изменен без внесения изменений в Web-приложение или IIS. Например, модуль 10 эффективно использует модульную концепцию платформы NET Framework и позволяет модулю быть удаленным, обновленным, измененным и манипулируемым, не требуя каких-либо изменений в коде Web-приложения или IIS.

Модуль 10 может быть образован как один или более модулей динамически связываемой библиотеки (.dll). Такие .dll модули могут включать в себя объектную модель для обеспечения структуры, требуемой модулем 10 и Web-приложением, чтобы обеспечить возможность формирования и использования индивидуально сконфигурированного основного объекта. Другой .dll модуль включает в себя модуль 10, который сопрягается с платформой, такой как приводимая в качестве примера NET Framework, для трансляции токенов из Web-приложений и от множества STS провайдеров.

Модуль 10 может образовывать часть системы, где по меньшей мере одна STS включает в себя второй сервер (18 в этом примере), подсоединенный к первому серверу (12) через сеть, как показано на фиг. 2 в позициях 20 и 24. В некоторых примерах кэш данных может быть расположен во втором сервере.

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

Подобным образом. в некоторых примерах IIS может быть в первом сервере, как показано. В других примерах (не показаны) IIS может быть в другом сервере и подсоединяться к первому серверу по соединению, такому, например, как интернет или другое сетевое соединение.

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

Модуль 10 может обеспечивать дополнительное преимущество для разработчика Web-приложения или для других, обеспечивая поток тестирования разработчика для тестирования модуля федеративной идентификации и трансляции токена безопасности в первом сервере без использования STS. Поток тестирования разработчика может быть обеспечен как динамически связываемая библиотека и позволяет серверу, в котором расположен модуль 10, моделировать сетевую STS. Поток тестирования разработчика может использовать xml файл как тестовый файл для посылки тестового токена безопасности в поток удостоверения для формирования тестового основного объекта безопасности. Поток тестирования разработчика может упорядочивать тестовый основной объект, который посылается в ASP NET приложение, как это должно происходить в реальной ситуации. Поток тестирования разработчика в модуле 10 может быть модифицируемым для моделирования множества свойств основного объекта безопасности, таких как разные FGA наборы данных.

Описанный выше приводимый в качестве примера модуль 10 может устранить необходимость для разработчиков Web-приложений знать и вводить сложную структуру сети и механизмы безопасности в их приложения. Приводимый в качестве примера модуль 10 может позволить разработчикам Web-приложений сосредоточиться на формировании приложения, которое поддерживает их бизнес-план. Разработчики Web-приложений могут не обязательно быть экспертами в сетевых протоколах безопасного доступа, таких как SAML, Windows Identity Federation, WS-Federation и т.п. Модуль 10 позволяет компонентам, требуемым конфигурацией, таким как SSL сертификаты и STS конечные точки, регулироваться и управляться провайдером сетевой инфраструктуры, так как некоторая из этой информации не является легко доступной для разработчика Web-приложения и представляется более подходящей для управления со стороны персонала сетевой инфраструктуры.

Приводимый в качестве примера компьютерно-реализуемый способ 300 для обеспечения федеративной идентификации и трансляции токена безопасности будет теперь описан со ссылкой на фиг. 3-6. Способ включает в себя управление и обеспечение создания основного объекта безопасности для пользователя, запрашивающего доступ к Web-приложению, функциональным взаимодействием с Web-приложением и/или информационным сервисом интернета (IIS) через первый сервер, включающий в себя машиноисполняемые команды, определяющие модуль, такой, например, как модуль 10. Однако должно быть понятно, что способ, представленный на фиг. 3-6, не ограничивается модулем на фиг. 1, и, напротив, модуль или способы, описанные здесь, могут быть другими в других вариантах осуществления.

Модуль 10, представленный на фиг. 3, включает в себя запрашивание и получение токенов аутентификации и авторизации непосредственно от по меньшей мере одной службы токенов безопасности (STS), основываясь на запросе на доступ от пользователя Web-приложения, на этапе 302. На этапе 304 модуль 10 запрашивает и принимает токен безопасности от STS для нового пользователя. Модуль 10 дополнительно включает в себя извлечение сертификата уровня защищенных сокетов (SSL) от Web-приложения и посылку SSL сертификата в STS на этапе 306.

В примере, использующем платформу NET Framework, этапы 302-306 могут включать в себя извлечение Web-посредника (proxy), характерного для конкретного поставщика токена, из http заголовков из Web-приложения, создание токена безопасности для WS-Federation запроса, используя этот характерный для конкретного поставщика токен для формирования двоичного токена безопасности, упомянутого выше, с целью аутентификации запроса на этапе 304. Кроме того, канал SOAP Web-службы может быть защищен, используя взаимно аутентифицированный SSL сертификат.

Затем STS может послать сообщение об ошибке, если запрос на токен безопасности неправомерен, и это сообщение об ошибке может быть переправлено пользователю. Альтернативно, если STS определяет, что запрос на этапе 304 был правомерным, STS посылает SAML токен в модуль 10. Модуль на этапе 308 удостоверяет принятый от STS токен безопасности (в этом примере SAML токен). Модуль 10 на этапе 310 включает в себя вызов другой службы, такой как ICA в приведенном выше примере, и принимает профиль пользователя и информацию точного доступа (FGA), соответствующую удостоверенному принятому токену безопасности (в этом примере SAML токену). Поэтому в некоторых примерах STS может обеспечивать базовый SAML токен, содержащий только идентификацию пользователя и минимальную базовую информацию профиля. Модуль 10 затем использует базовый SAML токен, чтобы вызвать одну или более других служб для получения более подробных сведений о пользователе. Такой модульный подход позволяет токену HTTP заголовка оставаться относительно малым и легко транслируемым и обрабатываемым приложениями. Затем модуль может быть обновлен и изменен, как требуется, без внесения каких-либо изменений в код для Web-приложений.

На этапе 312 модуль 10 дополнительно включает в себя формирование индивидуально сконфигурированного основного объекта безопасности из принятого профиля пользователя и FGA информации. В этом примере формирование индивидуально сконфигурированного основного объекта включает в себя преобразование (называемое также трансляцией) свойств SAML токена и утверждений в индивидуально сконфигурированный пользовательский основной объект .NET (NET User Principal Object). На этапе 314 модуль 10 может дополнительно включать вставку индивидуально сконфигурированного основного объекта безопасности в Web-приложение в качестве FGA набора данных.

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

Может быть также полезно объединить в одно целое способ и модуль 10, используя платформу .NET Framework, с тем чтобы способ включал в себя изменение модуля 10 без внесения изменений в Web-приложение или IIS. Приводимый в качестве примера способ выполняет это, эффективно используя модульность типовой платформы .NET Framework, и заменяет ASP .NET HttpContext субъект индивидуально сконфигурированным основным объектом безопасности. Например, модуль 10 может быть изменен для получения FGA данных от программного интерфейса прикладных задач репрезентативной передачи состояния (REST API) вместо SAML токена, используемого в приведенном выше примере.

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

В некоторых примерах Web-приложение может быть в первом сервере, а IIS может быть также в первом сервере или в другом сервере, соединенном через сеть.

Приводимые в качестве примера способ и модуль 10 немедленно после приема запроса на доступ от пользователя могут дополнительно включать в себя, на этапе 310 на фиг. 3, определение того, включает ли в себя кэш данных индивидуально сконфигурированный основной объект безопасности для пользователя, запрашивающего доступ к Web-приложению. Если ответом на этапе 316 является ʺдаʺ, модуль 10 вставляет индивидуально сконфигурированный основной объект безопасности для пользователя из кэша данных в Web-приложение на этапе 318. Если ответом на этапе 316 является ʺнетʺ, способ возвращается к этапу 302. Этапы 316 и 318 могут выполняться до этапа 302, чтобы предотвратить ненужные вызовы STS и не являющееся необходимым формирование дублирующего индивидуально сконфигурированного основного объекта безопасности для пользователя.

Приводимый в качестве примера способ может и еще дополнительно включать в себя вызов по меньшей мере одной другой STS и получение дополнительной информации о пользователе, используя удостоверенный принятый токен безопасности как токен аутентификации применительно к по меньшей мере одной другой службе профиля пользователя, как показано этапом 320 на фиг. 5. Дополнительная информация, включающая в себя дополнительные утверждения, может быть использована внутри приводимой в качестве примера платформы .NET Framework для поддержки трансляции атрибутов единой регистрации, например, функциональной возможности webSEAL™ корпорации IBM.

Приводимый в качестве примера способ может также обеспечивать разработчиков Web-приложений подходом к полному автономному тестированию их приложений на локальной рабочей станции, не требуя использования STS. Приводимые в качестве примера способ и/или модуль 10 могут включать в себя тест, включающий в себя использование тестового файла для передачи тестового токена безопасности на этап удостоверения и формирования тестового основного объекта безопасности на этапе 322 на фиг. 5. Способ может дополнительно включать в себя модификацию тестового файла и моделирование множества свойств основного объекта безопасности на этапе 324.

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

Должно быть понятно, что функции и/или этапы, и/или операции, описанные здесь в некоторых вариантах осуществления, могут быть описаны в исполняемых компьютером командах, хранимых в машиночитаемом носителе информации (например, в физическом материальном носителе, и т.п.) и исполняемых одним или более процессорами. Машиночитаемый носитель информации является энергонезависимым машиночитаемым носителем для хранения данных. В качестве примера, но не ограничиваясь этим, такой машиночитаемый носитель может включать в себя RAM, ROM, EEPROM, CD-ROM или другое запоминающее устройство на оптических дисках, запоминающее устройство на магнитных дисках или другие магнитные запоминающие устройства, или любой другой носитель, который может быть использован, чтобы нести или запоминать желательный программный код в форме команд или структур данных, и который может быть доступен для компьютера. Сочетания вышеупомянутых должны быть также включены в объем машиночитаемых носителей.

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

Как будет понятно из представленной выше спецификации, описанные выше варианты осуществления изобретения могут быть реализованы, используя технику компьютерного программирования или компьютерной инженерии, включающей в себя компьютерное программное обеспечение, программно-аппаратное обеспечение, аппаратное обеспечение или же любое их сочетание или подсовокупность, при этом технический эффект может быть достигнут выполнением по меньшей мере одной или более операций, описанных здесь (например, в формуле изобретения, и т.п.), например,: (a) управление и обеспечение создания основного объекта безопасности для пользователя, запрашивающего доступ к Web-приложению, функциональным взаимодействием с Web-приложением или службой информационного сервера интернета (IIS) через первый сервер, включающий в себя машиноисполняемые команды, определяющие модуль; (b) запрос и получение модулем токенов аутентификации и авторизации непосредственно от по меньшей мере одной службы токенов безопасности (STS), основываясь на запросе на доступ от пользователя Web-приложения; (c) запрашивание и прием модулем токена безопасности от STS для нового пользователя; (d) извлечение модулем сертификата уровня защищенных сокетов (SSL) от Web-приложения и посылка SSL сертификата в STS; (e) удостоверение модулем принятого токена безопасности от STS; (f) вызов модулем другой службы и прием профиля пользователя и информации точного доступа (FGA), соответствующей удостоверенному принятому токену безопасности; (g) формирование модулем индивидуально сконфигурированного основного объекта безопасности из принятого профиля пользователя и FGA информации; (h) вставление модулем индивидуально сконфигурированного основного объекта безопасности в Web-приложение как FGA набора данных; (i) запоминание индивидуально сконфигурированного основного объекта безопасности в кэше данных, включающем в себя долговременный машиночитаемый носитель информации, причем кэш данных располагается в первом сервере; и (j) изменение модуля, не производя изменений Web-приложения или IIS

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

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

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

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

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

один или более процессоров; и

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

при этом модуль обобщенной идентификации и трансляции токена безопасности включает в себя:

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

поток запроса нового пользователя на токен безопасности для запрашивания и приема токена безопасности от STS;

поток сертификата уровня защищенных сокетов (SSL) для извлечения SSL сертификата из Web-приложения и посылки SSL сертификата в STS;

поток удостоверения для удостоверения принятого токена безопасности от STS;

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

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

поток вставления для вставления индивидуально сконфигурированного основного объекта безопасности в Web-приложение в качестве FGA набора данных;

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

при этом модуль обобщенной идентификации и трансляции токена безопасности выполнен с возможностью быть изменяемым без внесения изменений в Web-приложение или IIS.

2. Первый сервер по п. 1, при этом упомянутая по меньшей мере одна STS включает в себя второй сервер, подсоединенный к первому серверу через сеть.

3. Первый сервер по п. 2, при этом кэш данных расположен во втором сервере.

4. Первый сервер по п. 1, при этом Web-приложение находится в первом сервере.

5. Первый сервер по п. 1, при этом IIS находится в первом сервере.

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

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

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

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

10. Первый сервер по п. 9, при этом тестовый файл является модифицируемым для моделирования множества свойств основного объекта безопасности.

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

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

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

запрашивают и принимают, посредством упомянутого модуля, токен безопасности от STS для нового пользователя;

извлекают, посредством упомянутого модуля, сертификат уровня защищенных сокетов (SSL) из Web-приложения и посылают SSL сертификат в STS;

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

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

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

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

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

изменяют упомянутый модуль без внесения изменений в Web-приложение или IIS.

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

13. Способ по п. 12, в котором кэш данных расположен во втором сервере.

14. Способ по п. 11, в котором Web-приложение находится в первом сервере.

15. Способ по п. 11, в котором IIS находится в первом сервере.

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

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

18. Способ по п. 11, дополнительно содержащий этап, на котором тестируют модуль в первом сервере без использования STS.

19. Способ по п. 18, дополнительно содержащий этап, на котором используют тестовый файл для посылки токена безопасности на этап удостоверения и формируют тестовый основной объект безопасности.

20. Способ по п. 19, дополнительно содержащий этап, на котором модифицируют тестовый файл и моделируют множество свойств основного объекта безопасности.