Введение

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

Identity Federation описывает примеры использования, стандарты и технологии, которые позволяют распространять идентификационную информацию между разными доменами безопасности. Предлагается несколько стандартов такого взаимодействия между предприятиями, но мы будем ориентироваться главным образом на стандарты SAML и WS-Security. С точки зрения технологии реализации, Security Assertion Markup Language (SAML) представляет собой XML-стандарт, разработанный техническим комитетом служб безопасности OASIS для обмена данными аутентификации и авторизации между разными сферами безопасности, так что его можно использовать для поддержки Identity Federation и распространения идентификационной информации внутри предприятия и между предприятиями. В настоящее время он проходит подтверждение в SAML в качестве транспортного средства, используемого для распространения идентификационной информации в рамках сервисно-ориентированной архитектуры.

В статье показано, что в ситуациях с использованием Identity Federation продукты WebSphere Application Server и Websphere DataPower могут выступать в качестве корпоративной магистрали сервисов (Enterprise Service Bus). Мы подробно объясним на примерах, как управлять подтверждениями SAML с использованием возможностей, предоставляемых этими двумя продуктами. Статья разделена на шесть частей:

1. Знакомство с основными понятиями, связанными с парадигмой федерации идентификационных данных и со структурой подтверждений SAML.
2. Описание примера, в котором два предприятия кооперируются друг с другом, для иллюстрации макровзаимодействия пользователя, приложения и предприятий.
3. Первый подход к поддержке аспектов распространения идентификационной информации с использованием основных возможностей обмена сообщениями WebSphere Application Server, появившихся в версии 6.
4. Второй подход к решению той же проблемы – с помощью WebSphere DataPower.
5. Демонстрация того, что происходит при реализации примера взаимодействия.
6. Соображения относительно преимуществ и недостатков каждого подхода, в частности, с учетом аспектов безопасности и эксплуатационных аспектов, имеющих большое значение при рассмотрении вопроса о внедрении в "реальных условиях".

Ключевые элементы

• Identity Federation.
• Security Assertion Markup Language (SAML).
• WS-Security.
• Базовые средства передачи сообщений WebSphere Application Server.
• WebSphere DataPower SOA Appliance.

Данная статья предполагает знакомство с технологией Web-сервисов и умение разрабатывать и внедрять приложения J2EE, а также знакомство с продуктами WebSphere Application Server и WebSphere DataPower.

В начало

Identity Federation и SAML

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

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

Identity Federation может обеспечиваться самыми разными способами с использованием официальных интернет-стандартов, таких как спецификация OASIS Security Assertion Markup Language (SAML), или решений с открытым исходным кодом, таких как Information Cards, OpenID и Higgins trust framework. OASIS SAML - это язык разметки для создания подтверждений безопасности (security assertions). Обычно они создаются подтверждающей стороной (Identity Provider, или IdP) в ответ на обращение запрашивающей стороны (Service Provider, или SP).

Эти подтверждения создаются органом, ответственным за соблюдение безопасности (таким как служба безопасности), который передает результаты другим участникам. SAML, разработанный Техническим комитетом по службам безопасности Организации по совершенствованию стандартов структурированной информации (OASIS), представляет собой основанную на XML структуру для передачи информации по аутентификации пользователей, правам и атрибутам. Как подсказывает само название, SAML позволяет организациям подтверждать личность, атрибуты и права субъекта (как правило, пользователя-человека) для других организаций, таких как компании-партнеры или другие корпоративные приложения. Такая информация передается в подтверждениях, которыми обмениваются подтверждающая сторона (от которой исходит подтверждение) и запрашивающая сторона (которая получает подтверждение для целей аутентификации или авторизации). Спецификация SAML организована по модульному принципу и опирается на некоторые конструктивные блоки, которые вкратце представлены на рисунук 1 (подробнее о SAML см. в разделе Ресурсы).

Подтверждения

Как уже упоминалось, подтверждения содержат сведения об участнике, которого подтверждающая сторона считает подлинным, причем правильная структура и содержание подтверждения определяются XML-схемой подтверждения SAML. Обычно подтверждения создаются подтверждающей стороной (Identity Provider, или IdP) в ответ на тот или иной запрос от запрашивающей стороны (Service Provider, или SP) и содержат сведения, которые поставщик услуг использует для принятия решений о предоставлении доступа. SAML предусматривает подтверждения трех типов:

• подтверждение аутентификации;
• подтверждение атрибутов;
• подтверждение решения об авторизации.

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

Подтверждение атрибутов заверяет, что к субъекту действительно относятся определенные атрибуты. Атрибут – это просто пара имя-значение. Стороны используют атрибуты для точной настройки решений по управлению доступом.

Подтверждение решения об авторизации информирует, что субъекту разрешается выполнять действие "A" по отношению к ресурсу "R" при наличии свидетельства "E".

Протоколы

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

• запрос проверки подлинности;
• запрос атрибутов;
• запрос решения по авторизации.

Привязки

Привязки (bindings) устанавливают соответствие между сообщением протокола SAML и стандартными форматами сообщений и/или протоколов связи. Например, привязка SAML SOAP определяет, каким образом сообщение SAML инкапсулировано в конверт SOAP, который сам привязан к сообщению HTTP.

Профили

Профили подробно описывают, как подтверждения SAML, протоколы и привязки объединены для определенного случая использования.

В начало

Пример

В примере кооперации приложений между двумя гипотетическими партнерами (компаниями JHKL и ACME) предлагаемый сценарий будет основываться на следующих предположениях:

• компания JHKL предоставляет некоторую услугу компании ACME;
• для реализации отношений приложение-приложение используется технология Web-сервисов;
• для передачи идентификационных данных между двумя предприятиями используется SAML.

Здесь мы предполагаем, что оба предприятия решили использовать одну и ту же модель, внедрив Enterprise Service Bus Gateway (далее просто ESB Gateway), настроенный на постоянную кооперацию приложений с внешними партнерами. Таким образом, приложению "А" (и другим внутренним приложениям) не нужно изменять свой обычный подход к таким аспектам безопасности, как передача идентификационных данных, так как Enterprise Service Bus Gateway будет обрабатывать все сообщения, адресованные приложению "В", адаптируя их для к правилам Identity Federation, установленным компанией JHKL.

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

Что происходит, когда некий Джон Доу пытается получить доступ к приложению "B"

Джон Доу (John Doe) – это сотрудник компании ACME, работающий с приложением "А" и другими такими же внутренними приложениями; он уже выполнил процесс аутентификации и, естественно, его полномочия имеют всего лишь местное значение и подтверждение. Когда Джон Доу инициирует запрос, для удовлетворения которого приложение "А" должно взаимодействовать с приложением "B", приложение "А" отправляет сообщения в ESB Gateway, который несет ответственность за применение всех необходимых правил преобразования между соответствующими протоколами безопасности. Здесь мы фактически предполагаем, что приложение "А" относится к частному домену, для которого компания ACME в качестве средства передачи идентификационных данных выбрала маркер WS-Security User-Name Token (далее просто WS-UNT), так что приложение "А" передает сообщения, содержащие локальные удостоверения личности пользователей, инкапсулированными в WS-UNT, и роль ESB Gateway сводится к преобразованию таких удостоверений в нечто, понятное компании JHKL. Для этого ESB Gateway

• проверяет и извлекает удостоверение пользователя из WS-UNT (например, "John Doe");
• удаляет WS-UNT;
• добавляет подтверждение аутентификации SAML (инкапсулированное в заголовок WS-Security), содержащее:
  • удостоверение личности пользователя (например, "John Doe");
  • атрибуты, определяющие роль учетной записи пользователя (например, "Guest" - гость);
  • цифровую подпись, которая гарантирует целостность сообщения, такую как удостоверение подлинности передающей стороны;
• отправляет сообщение приложению "B".

Важно отметить, что атрибут, устанавливающий роль пользователя (например, "Guest"), должен опираться на номенклатуру, созданную компаниями ACME и JHKL вместе при заключении своего партнерского соглашения.

Что происходит в JHKL

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

• проверить цифровую подпись, чтобы убедиться в подлинности и целостности сообщения;
• извлечь удостоверение личности автора запроса (например, "John Doe") и создать локальную временную учетную запись, в частности, для целей контроля (кто и что сделал);
• извлечь роль автора запроса из атрибута подтверждения (например, "Guest"), чтобы присвоить ему уровень допуска.

Что касается последнего пункта, то JHKL также может создать локальную "служебную" учетную запись автора запроса на основе его роли (например, "Guest"), чтобы удовлетворить внутренние требования по распространению идентификационных данных, если приложение "В" требует процесса авторизации и/или получения доступа к другим защищенным ресурсам. Для решения внутренних задач распространения идентификационных данных JHKL, благодаря преимуществам парадигмы Identity Federation, не нужно внутренне отображать учетные записи ACME, а достаточно определить отношение m:n, где:

• m – число всех возможных ролей, установленных между JHKL и ACME;
• n – количество всех возможных уровней доступа, каждый из которых связан с локальной служебной учетной записью.

В начало

Подход к реализации ESB Gateway компании ACME

ACME решает реализовать ESB Gateway с использованием основных возможностей WebSphere Application Server, таких как функции обмена сообщениями, введенные в версии 6. Однако помимо продукта WebSphere Application Server, ACME пришлось разработать два программных компонента для поддержания своей архитектуры, а именно:

• специальное приложение (содержащее проект разработки ПО с открытым исходным кодом OpenSAML), которое выступает в качестве источника подтверждений SAML;
• обработчик JAX-RPC, который вызывает источник SAML с уровня ESB.

Как видно из приведенной выше схемы (рисунок 3), при попытках приложения "А" обратиться к сервису, предоставляемому JHKL, происходит следующее.

1. Приложение "А" отправляет запрос SOAP, содержащий маркер WS-UNT;
2. Прослушивающий процесс Http SOAP принимает сообщение и направляет его в компонент Inbound Service.
3. WS-UNT проверяется и удаляется из сообщения, но субъект безопасности (удостоверение личности пользователя) остается.
4. Inbound Service направляет сообщение в компонент Outbound Service.
5. Обработчик JAX-RPC добавляет в сообщение подтверждение аутентификации SAML (поверх удостоверения личности пользователя) и вызывает приложение SAML Provider.
6. Компонент Outbound Service направляет сообщение в приложение "B".

Реализация ESB Gateway предприятия "А"

ESB-шлюз для предприятия "А" опирается главным образом на Service Integration Bus (SIB) - функцию, введенную в WebSphere Application Server V6. Чтобы реализовать архитектуру, проиллюстрированную на рисунке 2, потребуются следующие шаги.

1. Установка обработчика JAX-RPC и приложения SAML Provider.
2. Организация хранилища объектов Service Data Object на базе WebSphere Application Server.
3. Настройка прослушивающего процесса SOAP/HTTP на сервере приложений, связанном с BUS.
4. Создание BUS, такого как исходящие и входящие сервисы.
5. Определение конфигурации Web Service WS-Security, привязка входящих сообщений и их подача на входной порт сервиса.
6. Определение списка обработчиков JAX-RPC и его присоединение к выходному порту сервиса.

Цель данного раздела состоит не в том, чтобы шаг за шагом объяснить процесс создания целевой архитектуры: всю подробную информацию по каждом шагу можно найти в разделе Ресурсы. Ниже приводится краткое описание всех ключевых элементов реализации ESB Gateway компании ACME с дополнительными деталями по соответствующим аспектам нашего конкретного примера (обработчик JAX-RPC, специальное приложение STS, настройка и привязка Web-сервиса WS-Security).

Репозиторий Service Data Objects

Service Data Objects (SDO) – это открытый стандарт, который позволяет приложениям обрабатывать данные из разных источников одним и тем же способом, как графы данных. Например, SIB использует репозиторий SDO для хранения и обслуживания определений WSDL; такая опосредованная модель программирования обеспечивает интерфейс SDO для всех сообщений и общий API для доступа к свойствам и метаданным.

Организовать WebSphere Application Server для SDO несложно, и с учетом нашей тестовой среды, в которой мы использовали автономный профиль WebSphere Application Server, достаточно выполнить следующие команды:

• открыть командную строку;
• перейти в каталог <WAS_HOME>/bin;
• выполнить команду: wsadmin -f installSdoRepository.jacl -createDb node1 server1".

Приведенные выше команды организуют хранилище SDO с помощью встроенной базы данных Derby; в конце процедуры в консоли администратора WebSphere появится новое приложение SDO Repository.

Service Integration BUS и прослушивающий процесс SOAP/HTTP

WebSphere Application Server V6 содержит абсолютно новый механизм сообщений по умолчанию, написанный на Java; подробную информацию об этой функции можно найти в разделе Ресурсы. Тем не менее, здесь мы можем определить Service Integration Bus (далее просто BUS) как логическое облако, которое обеспечивает механизмы для соединения потребителей с поставщиками. Эта логическое облако содержит следующие элементы:

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

Чтобы реализовать пример, изображенный на рисунке 3, мы воспользовались отдельным экземпляром WebSphere Application Server, для которого настроили BUS, содержащий:

• уникальный отдельный экземпляр WebSphere Application Server в качестве члена;
• механизм сообщений, размещенный в отдельном экземпляре WebSphere Application Server;
• пункт назначения "очередь" для входящего сервиса;
• пункт назначения "Web-сервис" для исходящего сервиса;
• связь с прослушивающим процессом SOAP/HTTP содержит в качестве члена отдельный экземпляр WebSphere Application Server.

Прослушивающий процесс SOAP/HTTP позволяет вызывать сервис BUS, поэтому в примере он служит целевой конечной точкой для приложения "А", когда оно запускается для обращения к приложению "В".

Точный URI, образуемый ESB Gateway, имеет следующую структуру: [префикс прослушивающего процесса SOAP HTTP]/soaphttpengine/[имя BUS]/[имя входящего сервиса]/[имя порта входящего сервиса]

Настройка и привязка WS-Security

ESB Gateway должен применять политику безопасности, чтобы принимать только те входящие сообщения SOAP, которые содержат локально действительные удостоверения личности. Чтобы выполнить это требование, можно определить привязки и настройки WS-Security, относящиеся ко входному порту сервиса Bus. Информацию о том, как это сделать, можно найти в разделе Ресурсы, а в таблицах 1 и 2 указаны основные параметры, которые используются для настройки привязок и конфигурации WS-Security для WS-UNT.

В консоли администратора WebSphere конфигурацию и привязку WS-Security нужно настраивать в меню Service Integration, как показано на рисунке 4.

Затем конфигурацию и привязку WS-Security нужно прикрепить к порту Inbound Service, как показано на рисунке 5.

Обработчик JAX-RPC

В нашем сценарии обработчик JAX-RPC работает с входящим трафиком (от приложения "А"), применяя преобразование сообщений, позволяющее вставлять во входящие сообщения SAML Authentication Assertion.

Обработчик получает подписанное подтверждение SAML Assertion и вызывает специальное приложение SAML Provider (листинг 1).

public boolean handleRequest(MessageContext context)
{
   try
   {
      log(Level.INFO,"handleRequest","Start to handle a SOAP Request");
      SOAPMessageContext soapMsgCtx=(SOAPMessageContext)context;
      SOAPMessage soapMessage=soapMsgCtx.getMessage();

      ByteArrayOutputStream xml=new ByteArrayOutputStream();
      soapMessage.writeTo(xml);
      String message=xml.toString();
      log(Level.FINEST,"handleRequest","Message to handle: "+message);

      String subject=WSSubject.getCallerPrincipal();
      if (subject==null)
      {
         log(Level.INFO,"handleRequest","Missing subject");
         return false;
      }
      log(Level.INFO,"handleRequest","Identity found: "+subject);

      Context ctx=new InitialContext();
      STSEngineHome home=(STSEngineHome)ctx.lookup(STS_EJB);
      STSEngine stsEngine=home.create();

      String newMessage=stsEngine.doMessageTransformation(message, subject);

      log(Level.FINEST,"handleRequest","Message produced: "+newMessage);
      soapMsgCtx.setMessage(getSOAPMessage(newMessage));

      return true;
   } catch (Exception e)
   {
      log(Level.INFO,"init","blocking error: "+e.getMessage());
      e.printStackTrace();
      return false;
   }
}

В листинге 1 выделены места, в которых обработчик:

• в результате создания субъекта после применения политики WS-Security получает удостоверение личности пользователя с уровня WebSphere;
• запускает приложение SAML Provider (через RMI-IIOP), предоставляя как сообщение, так и удостоверение личности для получения нового сообщения, содержащего подписанное подтверждение аутентификации SAML.

Приложение SAML Provider

Приложение SAML Provider обеспечивает следующую функцию:

Оно запрашивает сообщение и удостоверение личности, а затем возвращает новое сообщение, содержащее подтверждение SAML Authentication Assertion. SAML Provider – это корпоративное приложение, содержащее один модуль Enterprise Java Bean, так что функция преобразования реализуется модулем Session Enterprise Java Bean (исходный код, приведенный в листинге 2, демонстрирует удаленный интерфейс), который опирается на проект OpenSAML для выдачи подписанных подтверждений SAML.

package com.ibm.customsts.ejbs;

/**
 * Remote interface for Enterprise Bean: STSEngine
 */
public interface STSEngine extends javax.ejb.EJBObject {

public String doMessageTransformation(String message,String subject)
throws Exception;
}

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

• управление цифровыми сертификатами для цифровой подписи;
• возможность назначить роль данной учетной записи.

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

Если перейти от примера к реальной производственной среде, то реализация Security Token Service (далее – STS) могла бы стать подходящим способом поддержки Identity Federation с достижением большей гибкости и эффективности (рисунок 6).

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

Хотя WebSphere Application Server может прямо обращаться к Security Token Service, на рисунке 6 показано, как развивается пример сценария после введения компонента STS. В этом новом сценарии ESB управляет преобразованием протокола безопасности, в то время как STS отвечает за передачу и создание подтверждений SAML с использованием своей интеграции с компонентами управления идентификацией и доступом.

В начало

Шлюз ESB Gateway компании JHKL

Как показано на рисунке 7, на этот раз JHKL решает реализовать шлюз ESB Gateway с применением WebSphere DataPower SOA Appliance.

В данном случае WebSphere DataPower:

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

Что касается точек 2 и 3, то в предположении, что WebSphere DataPower должен решать эти вопросы самостоятельно (без обращения к внешним компонентам), мы выбрали следующие методы.

1. Использование простого файла XSL для отображения ролей SAML на локально действительные идентификационные данные сервисов.
2. Создание маркера LTPA на транспортном уровне для распространения идентификационных данных сервисов.

В предыдущем разделе мы предположили, что ACME использует WS-ЕНТ для включения распространения идентификационных данных в пределах своего частного домена, и такой выбор является одним из наиболее распространенных и совместимых методов. JHKL, напротив, использует маркер LTPA, т. е. собственный протокол распространения. Выбор JHKL основывается на предпосылке, что, учитывая общую инфраструктуру Service Oriented Architecture, не всегда требуется полное взаимодействие.

Действительно, если предположить, что приложение "B" всегда LTPA-совместимо, оно будет вызываться все большим числом потребителей, и ему понадобится доступ к другим защищенным ресурсам (например, Enterprise Java Beans) внутри ячеек WebSphere, то маркер LTPA может быть разумным выбором по характеристикам управляемости и производительности. В самом деле, сквозное распространение идентификационных данных, которое опирается на генерирование маркеров безопасности для каждого участка пути, может оказаться достаточно дорогостоящим, а маркер LTPA представляет собой безопасный способ распространения идентификационных данных, так как он зашифрован, подписан и к тому же поддерживает возможность определения срока действия.

Реализация ESB Gateway компании JHKL

Для реализации шлюза ESB компании JHKL объект WS-Proxy сконфигурирован внутри DataPower и наш поток запросов, как показано на рисунке 8, по существу, состоит из двух действий:

1. Действие проверки.
2. Действие AAA.

Если действие проверки заключается в простой проверке подписи подтверждения SAML, то действие AAA выполняет более сложную работу.

Конфигурация AAA

На первом шаге AAA извлекает удостоверение личности пользователя – в нашем примере это важная задача. Фактически предмет подтверждения содержит удостоверение личности вызывающего абонента (например, "John Doe"), которое с точки зрения JHKL может быть полезно в основном для целей аудита. Для целей же аутентификации/авторизации и целей распространения идентификационных данных нужно извлечь роль пользователя (например, "Guest"), в нашем случае эта информация значима для JHKL, потому что она должна отображаться на учетную запись локального сервиса. По этой причине, как показано на рисунке 9, мы используем выражение XPATH для извлечения роли пользователя из атрибута подтверждения SAML.

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

На рисунке 10 показан файл AAA Info, применяемый для отображения ролей на удостоверения локального сервиса. Специально для целей тестирования файл AAA Info содержит только те отношения, в которых роль "Guest" отображена на удостоверение "iod=service1,o=defaultWIMFileBasedRealm", но этот файл показывает также, что отображение относится к ограниченному числу позиций (все возможные роли) и ограниченному числу локальных удостоверений (по одному для каждого уровня авторизации). Мы использовали файл AAA Info, но DataPower позволяет обеспечить большую гибкость и возможность управлять этим отображением другими способами, например посредством запросов LDAP (листинг 3).

<?xml version="1.0" encoding="utf-8"?>
<AAAInfo xmlns="http://www.DataPower.com/AAAInfo">
  <FormatVersion>1</FormatVersion>
  <Summary>Map abstract role to local service identity.</Summary>
  <MapCredentials>
    <InputCredential>Guest</InputCredential>
    <OutputCredential>uid=service1,o=defaultWIMFileBasedRealm</OutputCredential>
  </MapCredentials>
</AAAInfo>

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

Последний шаг (рисунок 12) реализует преобразование сообщения – мы удаляем заголовок WS-Security и создаем маркер LTPA (на транспортном уровне), основанный на отображенном удостоверении (роль "Гость").

В начало

Тестирование примера

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

В листинге 4 показано сообщение-запрос от приложения "A", где можно видеть WS-UNT (с удостоверением на имя John Doe) внутри заголовка SOAP.

<soapenv:Envelope 
xmlns:log="http://logic.echoservice.la41318.it/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
 <wsse:Security soapenv:mustUnderstand="1" 
   xmlns:wsse="http://.../oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <wsse:UsernameToken wsu:Id="UsernameToken-624174388" 
      xmlns:wsu="http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd">
	
         <wsse:Username>john.doe</wsse:Username>
         <wsse:Password Type="http://...wss-username-token-profile-1.0#PasswordText">
            passw0rd
         </wsse:Password>
	
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <log:getDate/>
   </soapenv:Body>
</soapenv:Envelope>

В сообщении, сгенерированном шлюзом ESB компании ACME (листинг 5), обратите внимание на три дочерние конструкции подтверждения SAML:

• issuer указывает на ACME как на владельца подтверждения;
• subject указывает на Джона Доу как на вызывающее лицо;
• attribute statement указывает, что Джон Доу получил роль "гостя".

<soapenv:Envelope  xmlns:log=".../" xmlns:soapenv="..." xmlns:env="..." xmlns:dp="...">
   <soapenv:Header>
      <wsse:Security xmlns:wsse="..." soapenv:mustUnderstand="1">
         <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
         ID="1" IssueInstant="2010-01-19T15:34:33.331Z" Version="2.0">
	
            <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
               ACME Inc.
            </saml:Issuer>
	
            <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
               /..../
            </ds:Signature>
	
            <saml:Subject>
              <saml:NameID>john.doe</saml:NameID>
                 <saml:SubjectConfirmation>
                    <saml:SubjectConfirmationData 
                         Address="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"/>
                 </saml:SubjectConfirmation>
           </saml:Subject>
	
           <saml:Conditions 
                 NotBefore="2010-01-18T15:34:33.331Z" 
                 NotOnOrAfter="2010-01-20T15:34:33.331Z"/>
	
           <saml:AttributeStatement>
             <saml:Attribute Name="Role" NameFormat="Role">
                <saml:AttributeValue xmlns:xsi="..." xmlns:xs="..." 
                        xsi:type="xs:string">
                   Guest
                </saml:AttributeValue>
             </saml:Attribute>
           </saml:AttributeStatement>
	
           <saml:AuthnStatement AuthnInstant="2010-01-19T15:34:33.331Z">
             <saml:AuthnContext>
               <saml:AuthnContextClassRef>
                     urn:oasis:names:tc:SAML:2.0:ac:classes:Password
               </saml:AuthnContextClassRef>
             </saml:AuthnContext>
            </saml:AuthnStatement>
         </saml:Assertion>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <log:getDate/>
   </soapenv:Body>
</soapenv:Envelope>

Мы предположили, что шлюз ESB компании JHKL передаст удостоверение приложению "B" с использованием маркера LTPA на транспортном уровне. По этой причине, как показывает листинг 6, сообщение-запрос, сгенерированное DataPower, не содержит никакой информации WS-Security.

<soapenv:Envelope xmlns:soapenv="..." xmlns:env="..." xmlns:dp="...">
   <soapenv:Header>
   </soapenv:Header>
   <soapenv:Body>
      <log:getDate/>
   </soapenv:Body>
</soapenv:Envelope>

Вместо этого, как изображено на рисунке 13, DataPower передает в приложение "B" информацию о сообщении-запросе, в которую действие постобработки добавило LTPA cookie (см. рисунок 12).

Наконец, листинг 7 показывает ответное сообщение от "Application B".

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

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <ns2:getDateResponse xmlns:ns2="http://logic.echoservice.la41318.it/">
         <return>[Tue Jan 19 16:34:33 CET 2010]</return>
      </ns2:getDateResponse>
   </soapenv:Body>
</soapenv:Envelope>

В начало

Заключение

В данной статье рассматривается вопрос о необходимости поддержки взаимодействия Identity Federation между предприятиями (или в пределах одного предприятия). На примере приложения кооперации предлагаются два возможных решения. Эти решения основаны на том, что в качестве модели реализации будет использоваться шлюз Enterprise Service Bus Gateway, поскольку это структурный элемент, предназначенный для гладкого решения подобных сценариев сотрудничества без серьезного вмешательства в существующую ИТ-инфраструктуру и обычное поведение внутренних приложений.

На основе этого предположения были предложены два возможных решения реализации ESB Gateway: в первом используются основные функции Websphere Application Server, а во втором – встроенные функции Datapower. Из этой статьи должно быть ясно, с какими трудностями можно столкнуться при реализации описанных сценариев и как их преодолеть с помощью различных стратегий реализации.

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

В начало

Загрузка

Информация о методах загрузки

Ресурсы

• Оригинал статьи (EN).
  
  
• Официальное сообщество SAML: информация о продукте. (EN)
  
  
• Главная страница OpenSAML : информация о продукте.(EN)
  
  
• Передача сообщений через посредников: практическое введение: подробная информация о новых возможностях, добавленных в WebSphere Application Server V6. (EN)
  
  
• WebSphere Application Server Infocenters: документация по продукту. (EN)
  
  
• Построение Enterprise Service Bus с помощью WebSphere Application Server V6: набор статей о том, как использовать возможности WebSphere Application Server для решения задач интеграции. В частности, в частях 5 и 7 подробно описан процесс построения архитектуры, предлагаемой в этой статье. (EN)
  
  
• Стандарт WS-Trust: введение и спецификации WS-Trust от OASIS. (EN)
  
  

Об авторах

Андреа Карминьяни (Andrea Carmignani) работает старшим ИТ-архитектором в IBM с 2007 года. Он выполняет обязанности ИТ-архитектора и ИТ-консультанта, уделяя основное внимание вопросам безопасности, связанным с архитектурой предприятия, облачными вычислениями, виртуализацией и инфраструктурами SOA, а также классическим вопросам безопасности, таким как конфиденциальность, аудит и управление идентификационной информацией. Обычно он отвечает за определение комплексных решений в плане архитектуры, продуктов и организационных процессов, охватывая все аспекты обеспечения безопасности и конфиденциальности. Ему приходится иметь дело с несколькими отраслями промышленности, такими как связь, государственное управление и финансы, работая как с национальными, так и с европейскими клиентами. Ранее он работал в отделении ИТ-безопасности и борьбы с мошенничеством крупной итальянской телекоммуникационной компании.

Анджело Литтера (Angelo Littera) – старший ИТ-архитектор отделения IBM Global Technology Services в Италии. Пришел в IBM в 1996 году в качестве ИТ-специалиста и работал над многими проектами для клиентов из разных отраслей, выступая в качестве специалиста по системам для малого и среднего бизнеса на платформах Unix (AIX/Linux), но в основном на базе технологий Java и продуктов WebSphere. Как ИТ-архитектор, отвечает за определение инфраструктуры архитектурных решений с упором на сервис-ориентированную архитектуру, технологию Web-сервисов и технологии Java Enterprise. В последние годы участвовал в ряде проектов по разработке решений для интеграции сервисов в сфере государственного управления Италии. Активно публикует документы в системе IBM Intellectual Capital Management.

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Identity Federation и SAML
• Пример
• Подход к реализации ESB Gateway компании ACME
• Шлюз ESB Gateway компании JHKL
• Тестирование примера
• Заключение
• Загрузка
• Ресурсы
• Об авторах
• Комментарии