Web-сервисы Java: WS-Trust и WS-SecureConversation

Узнайте, как WS-SecureConversation улучшает производительность системы безопасности Web-сервисов

WS-Security позволяет обеспечить в обмене SOAP-сообщениями безопасность корпоративного уровня, правда, ценой заметного снижения производительности. Технология WS-Trust, основанная на WS-Security, предоставляет способ обмена токенами безопасности, а технология WS-SecureConversation, основанная на WS-Security и WS-Trust, позволяет улучшить производительность обмена сообщениями. Деннис Сосноски продолжает цикл статей Web-сервисы Java рассказом о WS-Trust и WS-SecureConversation.

Денис Сосноски, консультант, Sosnoski Software Solutions, Inc.

Денис Сосноски (Dennis Sosnoski) - основатель и ведущий специалист консалтинговой компании по технологиям Java - Sosnoski Software Solutions, Inc., специализирующейся в обучении и консультировании по проблемам XML и Web-сервисов. Он имеет более чем 30-летний опыт работы в профессиональном проектировании ПО, специализируясь на серверных XML и Java-технологиях. Денис является основным разработчиком интегрированной системы с открытым программным кодом JiBX XML Data Binding, построенной на базе технологии классов Java и связанной системы Web-сервисов JibxSoap, также как и системы Web-сервисов Apache Axis2. Он также был одним их экспертов при разработке спецификаций JAX-WS 2.0.



26.01.2012

WS-Security предоставляет широкий набор средств безопасности Web-сервисов, основанных на установившихся в отрасли стандартах криптографии, а также шифрования и подписывания XML-данных. Предоставляемая WS-Security функциональность важна для многих приложений, однако за нее приходится платить существенным снижением производительности. В предыдущих статьях этой серии мы изучили, как типичные конфигурации WS-Security влияют на производительность основных Java™ стеков Web-сервисов: Apache Axis2, Metro и Apache CXF.

Большая часть издержек производительности при использовании WS-Security связана с широким применением асимметричного шифрования. Как обсуждалось в статье Axis2 WS-Security signing and encryption, асимметричное шифрование полезно тем, что оно работает с парами ключей. Каждый ключ в паре может использоваться для шифрования сообщений, которые можно расшифровать другим ключом пары. Владелец пары ключей может сделать один из ключей доступным публично, чтобы кто угодно мог с его помощью шифровать исходящие сообщения и расшифровывать входящие сообщения от владельца (проверяя таким образом его подлинность). Недостатком асимметричного шифрования является намного больший размер ключей и большие издержки на обработку по сравнению с более простым симметричным шифрованием, основанном на одном секретном ключе, известном только сторонам, участвующим в обмене.

Об этом цикле статей

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

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

WS-Trust

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

Ядром WS-Trust является набор сообщений, используемых для выпуска, обновления, аннулирования и проверки токенов безопасности. Обмен этими сообщениями осуществляется при обращении к SOAP Web-сервису определенного типа, который называется Security Token Service (STS). Также эти сообщения можно передавать и другими способами (например, в заголовках безопасности запроса к другому сервису).

Основы STS

STS – это Web-сервис, реализующий простой интерфейс, определяемый спецификацией WS-Trust. Этот интерфейс позволяет клиентам использовать токены безопасности для отправки запросов на выполнение нескольких типов операций. Так как STS является Web-сервисом, WS-Security можно использовать непосредственно в запросах и ответах, а также посредством политик WS-SecurityPolicy указывать тип удостоверяющей информации, которую должны предоставить клиенты, а также любые другие средства безопасности, которые следует применять при обработке сообщений.

Самой простой операцией является выпуск нового токена. В листинге 1 показан отредактированный пример запроса к STS на выпуск нового токена, из которого мы убрали для краткости различные заголовки, оставив только тело запроса (далее мы увидим и пример сообщения с заголовками). Запрос, показанный в листинге 1, запрашивает токен безопасности называемый SCT (Security Context Token – токен контекста безопасности), используемый для работы WS-SecureConversation:

Листинг 1. Запрашиваем у STS токен безопасности
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    ...
  </soap:Header>
  <soap:Body xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-7059772">
    <wst:RequestSecurityToken
        xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <wst:RequestType>http://.../ws-sx/ws-trust/200512/Issue</wst:RequestType>
      <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
        <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
          <wsa:Address>http://localhost:8800/cxf-seismicsc-signencr/</wsa:Address>
        </wsa:EndpointReference>
      </wsp:AppliesTo>
      <wst:Lifetime xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd">
        <wsu:Created>2010-05-12T10:33:22.774Z</wsu:Created>
        <wsu:Expires>2010-05-12T10:38:22.774Z</wsu:Expires>
      </wst:Lifetime>
      <wst:TokenType
      >http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/sct</wst:TokenType>
      <wst:KeySize>128</wst:KeySize>
      <wst:Entropy>
        <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce"
        >kIYFB/u430k3PlOPfUtJ5A==</wst:BinarySecret>
      </wst:Entropy>
      <wst:ComputedKeyAlgorithm
      >http://.../ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKeyAlgorithm>
    </wst:RequestSecurityToken>
  </soap:Body>
</soap:Envelope>

В теле запроса из листинга 1 показан простой элемент <wst:RequestSecurityToken>, используемый в большинстве запросов к STS. В обязательном элементе-потомке <wst:RequestType> определяется тип запроса; в данном случае это Issue (выпуск нового токена). Остальные элементы-потомки являются необязательными параметрами запроса Issue, в которых может указываться:

  • Конечная точка сервиса, для работы с которой будет использоваться запрашиваемый токен (элемент <wsp:AppliesTo>).
  • Интервал времени, в течение которого токен считается действительным (элемент <wst:Lifetime>).
  • Тип токена (элемент <wst:TokenType>).
  • Запрашиваемый размер ключа в битах (элемент <wst:KeySize>).
  • Предоставляемые клиентом случайные данные, которые следует использовать для генерации секретного ключа (элемент <wst:Entropy>).
  • Алгоритм, который следует использовать для генерации секретного ключа (элемент <wst:ComputedKeyAlgorithm>).

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

Листинг 2. Ответ с токеном безопасности от сервиса STS
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    ...
  </soap:Header>
  <soap:Body xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-4824957">
    <wst:RequestSecurityTokenResponseCollection
        xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <wst:RequestSecurityTokenResponse>
        <wst:RequestedSecurityToken>
          <wsc:SecurityContextToken
              xmlns:wsc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
              xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
              wsu:Id="sctId-A167EB2B526E0894DA12736604029099">
            <wsc:Identifier>A167EB2B526E0894DA12736604029098</wsc:Identifier>
          </wsc:SecurityContextToken>
        </wst:RequestedSecurityToken>
        <wst:RequestedAttachedReference>
          <wsse:SecurityTokenReference
            xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <wsse:Reference xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd"
                URI="#sctId-A167EB2B526E0894DA12736604029099"
                ValueType=".../ws-sx/ws-secureconversation/200512/sct"/>
          </wsse:SecurityTokenReference>
        </wst:RequestedAttachedReference>
        <wst:RequestedUnattachedReference>
          <wsse:SecurityTokenReference
            xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <wsse:Reference xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd"
            URI="A167EB2B526E0894DA12736604029098"
            ValueType=".../ws-sx/ws-secureconversation/200512/sct"/>
          </wsse:SecurityTokenReference>
        </wst:RequestedUnattachedReference>
        <wst:Lifetime xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd">
          <wsu:Created>2010-05-12T10:33:22.909Z</wsu:Created>
          <wsu:Expires>2010-05-12T10:38:22.909Z</wsu:Expires>
        </wst:Lifetime>
        <wst:RequestedProofToken>
          <wst:ComputedKey
          >http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKey>
        </wst:RequestedProofToken>
        <wst:Entropy>
          <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce"
          >DpkK6qcELTO8dlPdDHMi2A==</wst:BinarySecret>
        </wst:Entropy>
      </wst:RequestSecurityTokenResponse>
    </wst:RequestSecurityTokenResponseCollection>
  </soap:Body>
</soap:Envelope>

В ответе из листинга 2 показан элемент <wst:RequestSecurityTokenResponseCollection>, выступающий оберткой для единственного элемента <wst:RequestSecurityTokenResponse>, который, в свою очередь, является оберткой для информации токена. Отправитель запроса желает получить в ответе токен SCT (это видно по значению типа токена

<wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType>

в запросе из листинга 1), поэтому в ответе содержится:

  • Сам токен SCT (обернутый в элемент <wst:RequestedSecurityToken>)
  • Определенные ссылочные структуры (<wst:RequestedAttachedReference> и <wst:RequestedUnattachedReference>)
  • Временной интервал, в течение которого токен считается действительным (элемент <wst:Lifetime>)
  • Токен доказательства (элемент <wst:RequestedProofToken>)
  • Предоставляемые сервером случайные данные, которые следует использовать для генерации секретного ключа (элемент <wst:Entropy>)

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

Другие параметры

Помимо запросов типа Issue к сервису STS также можно делать запросы Validate, Renew и Cancel. При отправке этих запросов необходимо предоставить или сослаться на ранее выпущенный токен. Эти запросы позволяют клиенту проверять токен, а также запрашивать продление или завершение срока действия токена.

В ответах от сервиса STS в случае возвращения одного токена вместо показанного в листинге 2 элемента-обертки <wst:RequestSecurityTokenCollection> может непосредственно использоваться элемент <wst:RequestSecurityTokenResponse>. В ответах от сервиса STS может использоваться элемент <wst:RequestSecurityTokenCollection>, оборачивающий в себя любое количество элементов <wst:RequestSecurityToken>.

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


WS-SecureConversation

Стандарт WS-SecureConversation основан на WS-Trust; он использует сервис STS для управления SCT. SCT представляет собой контекст, совместно используемый сторонами, участвующими в обмене сообщениями, который хранит информацию, позволяющую сторонам использовать для обеспечения безопасности симметричное шифрование.

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

STS и сервис

Теоретически WS-SecureConversation можно использовать для обмена сообщениями между множеством участников, однако наиболее типичным его использованием является взаимодействие клиента и одного сервера. При использовании этой конфигурации STS, предоставляющий клиенту токен SCT, находится там же, где и сервер, и доступ к нему осуществляется через ту же конечную точку. Это означает, что выполняемый на сервере код Web-сервисов должен уметь отличать сообщения, адресованные STS от сообщений, адресованных самому сервису. Для этих целей служит атрибут запроса, называемый действием.

На рисунке 1 иллюстрируется конфигурация с совмещенным STS и сервисом для обмена сообщениями:

Рисунок 1. Совмещенные сервис и STS, основанный на WS-SecureConversation
WS-SecureConversation STS co-located with service

Когда клиент хочет начать обмен сообщениями с сервером, он сначала связывается с STS и устанавливает контекст. В этом сообщении, обозначенном на рисунке 1 цифрой 1, указывается действие http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT. В ответе (сообщение 2) клиенту передается токен контекста SCT. Далее этот контекст используется в сообщении 3, в котором указывается какое-нибудь действие, связанное с самим приложением сервиса. В течение указанного временного интервала SCT действителен во всех последующих сообщениях от клиента сервису. В сообщениях 3 и 4, а также всех последующих сообщениях, пересылаемых между клиентом и сервисом, используется симметричное шифрование на основе общего секретного значения. Приложение сервиса получает непосредственный доступ к общему секретному значению из контекста, хранящегося в STS, с помощью предоставляемой клиентом ссылки на контекст.

Конфигурация WS-Policy

В WS-SecureConversation используются конфигурации WS-Policy и WS-SecurityPolicy, похожие на базовые конфигурации для обработки сообщений с помощью WS-Security, рассмотренные в предыдущих статьях этой серии. Существенное отличие заключается в том, что при использовании WS-SecureConversation эти конфигурации должны охватывать как обмен сообщениями между клиентом и STS, так и обмен сообщениями между клиентом и непосредственно сервисом. Это осуществляется в описании политики, - обмен сообщениями с STS описывается вложенной политикой, а политика, указанная в основном теле, применяется для обмена сообщениями между клиентом и сервисом.

В листинге 3 показана политика, используемая в примерах для этой статьи:

Листинг 3. Пример политики WS-SecureConversation
<wsp:Policy wsu:Id="SecConv"
    xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
  <wsp:ExactlyOne>
    <wsp:All>
      <wsap:UsingAddressing xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl"/>
      <sp:SymmetricBinding>
        <wsp:Policy>
          <sp:ProtectionToken>
            <wsp:Policy>
              <sp:SecureConversationToken sp:IncludeToken=".../AlwaysToRecipient">
                <wsp:Policy>
                  <sp:RequireDerivedKeys/>
                  <sp:BootstrapPolicy>
                    <wsp:Policy>
                      <sp:AsymmetricBinding>
                        <wsp:Policy>
                          <sp:InitiatorToken>
                            <wsp:Policy>
                              <sp:X509Token sp:IncludeToken=".../AlwaysToRecipient">
                                <wsp:Policy>
                                  <sp:RequireThumbprintReference/>
                                </wsp:Policy>
                              </sp:X509Token>
                            </wsp:Policy>
                          </sp:InitiatorToken>
                          <sp:RecipientToken>
                            <wsp:Policy>
                              <sp:X509Token sp:IncludeToken=".../IncludeToken/Never">
                                <wsp:Policy>
                                  <sp:RequireThumbprintReference/>
                                </wsp:Policy>
                              </sp:X509Token>
                            </wsp:Policy>
                          </sp:RecipientToken>
                          <sp:AlgorithmSuite>
                            <wsp:Policy>
                              <sp:TripleDesRsa15/>
                            </wsp:Policy>
                          </sp:AlgorithmSuite>
                          <sp:IncludeTimestamp/>
                          <sp:OnlySignEntireHeadersAndBody/>
                        </wsp:Policy>
                      </sp:AsymmetricBinding>
                      <sp:SignedParts>
                        <sp:Body/>
                        <sp:Header Name="To" Namespace=".../addressing"/>
                        <sp:Header Name="From" Namespace=".../addressing"/>
                        <sp:Header Name="FaultTo" Namespace=".../addressing"/>
                        <sp:Header Name="ReplyTo" Namespace=".../addressing"/>
                        <sp:Header Name="MessageID" Namespace=".../addressing"/>
                        <sp:Header Name="RelatesTo" Namespace=".../addressing"/>
                        <sp:Header Name="Action" Namespace=".../addressing"/>
                      </sp:SignedParts>
                      <sp:Trust13>
                        <wsp:Policy>
                          <sp:MustSupportIssuedTokens/>
                          <sp:RequireClientEntropy/>
                          <sp:RequireServerEntropy/>
                        </wsp:Policy>
                      </sp:Trust13>
                    </wsp:Policy>
                  </sp:BootstrapPolicy>
                </wsp:Policy>
              </sp:SecureConversationToken>
            </wsp:Policy>
          </sp:ProtectionToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic128Rsa15/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
        </wsp:Policy>
      </sp:SymmetricBinding>
      <sp:EncryptedParts>
        <sp:Body/>
      </sp:EncryptedParts>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

В листинге 3 внешняя политика предписывает использование симметричного шифрования (<sp:SymmetricBinding>) тела (см. элемент <sp:EncryptedParts> внизу листинга) пересылаемых сообщений. Внутри политики симметричного шифрования элемент <sp:ProtectionToken> и вложенный элемент <sp:SecureConversationToken> сообщают, что для осуществления симметричного шифрования следует использовать WS-SecureConversation.

Политики, применяемые при работе с STS, определяются в элементе <sp:BootstrapPolicy> (выделенном жирным шрифтом), вложенном в элемент <sp:SecureConversationToken>. Эта политика просто предписывает подписывать тело и заголовки адреса сообщений с помощью сертификатов X.509. Этот тип подписи мы уже видели в предыдущих статьях этой серии, посвященных WS-Security.

Обратите внимание, что при использовании этой политики сообщения, которыми обмениваются клиент и STS, не шифруются. Это позволяет легко отследить все, что происходит, однако в реальной жизни этот обмен стоит защитить либо шифрованием транспортного уровня (TLS/SSL), либо шифрованием с помощью WS-Security.

Обмен сообщениями

В листинге 4 показаны заголовки сообщений 1 и 2 — запроса к STS и ответа клиенту соответственно. (Тела этих мы уже видели сообщений в листинге 1 и листинге 2.)

Листинг 4. Заголовки запроса к STS и ответа от него
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>

    <Action xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-32320445"
      >http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT</Action>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-2673180"
      >urn:uuid:24ce01d5-3c17-4df6-ad89-2fc0720152cd</MessageID>
    <To xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-5132526"
      >http://localhost:8800/cxf-seismicsc-signencr/</To>
    ...
    <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">
      <wsse:BinarySecurityToken xmlns:wsse="...wssecurity-secext-1.0.xsd"
        xmlns:wsu="...wssecurity-utility-1.0.xsd"
        EncodingType="...soap-message-security-1.0#Base64Binary"
        ValueType="...x509-token-profile-1.0#X509v3"
        wsu:Id="CertId-CF15C330C32618BF4912736604028486"
        >MIICo...8/0n33w==</wsse:BinarySecurityToken>
      <wsu:Timestamp xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-7">
        <wsu:Created>2010-05-12T10:33:22.831Z</wsu:Created>
        <wsu:Expires>2010-05-12T10:38:22.831Z</wsu:Expires>
      </wsu:Timestamp>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-8">
        <ds:SignedInfo>
          ...
          <ds:Reference URI="#Id-7059772">
            ...
          </ds:Reference>
          ...
          <ds:Reference URI="#Timestamp-7">
            ...
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>TYIbt...V0dd8=</ds:SignatureValue>
        <ds:KeyInfo Id="KeyId-CF15C330C32618BF4912736604028487">
          <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd"
            xmlns:wsu="...wssecurity-utility-1.0.xsd"
            wsu:Id="STRId-CF15C330C32618BF4912736604028488">
            <wsse:Reference xmlns:wsse="...wssecurity-secext-1.0.xsd"
            URI="#CertId-CF15C330C32618BF4912736604028486"
            ValueType="...x509-token-profile-1.0#X509v3"/>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu="..." wsu:Id="Id-7059772">
    ...
  </soap:Body>
</soap:Envelope>

soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-33522601"
      >http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/SCT</Action>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-9229531"
      >urn:uuid:d9d1b9b2-a864-446b-ab81-3176f868046e</MessageID>
    <To xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-25551189"
      >http://www.w3.org/2005/08/addressing/anonymous</To>
    <RelatesTo xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-32148925"
      >urn:uuid:24ce01d5-3c17-4df6-ad89-2fc0720152cd</RelatesTo>
    <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">
      <wsu:Timestamp xmlns:wsu=
        "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wssecurity-utility-1.0.xsd" 
        wsu:Id="Timestamp-7">
        <wsu:Created>2010-05-12T10:33:22.913Z</wsu:Created>
        <wsu:Expires>2010-05-12T10:38:22.913Z</wsu:Expires>
      </wsu:Timestamp>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-8">
        <ds:SignedInfo>
          ...
          <ds:Reference URI="#Id-4824957">
            ...
          </ds:Reference>
          ...
          <ds:Reference URI="#Timestamp-7">
            ...
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>tr1tx...GY4wk=</ds:SignatureValue>
        <ds:KeyInfo Id="KeyId-A167EB2B526E0894DA127366040291811">
          <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd"
            xmlns:wsu="...wssecurity-utility-1.0.xsd"
            wsu:Id="STRId-A167EB2B526E0894DA127366040291812">
            <wsse:KeyIdentifier EncodingType="...soap-message-security-1.0#Base64Binary"
            ValueType="...soap-message-security-1.1#ThumbprintSHA1"
            >uYn3PK2wXheN2lLZr4n2mJjoWE0=</wsse:KeyIdentifier>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-4824957">
    ...
  </soap:Body>
</soap:Envelope>

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

В листинге 5 показан (сильно отредактированный) обмен сообщениями между клиентом и сервисом с использованием WS-SecureConversation:

Листинг 5. Запрос к сервису и ответ от сервиса клиенту
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing">urn:matchQuakes</Action>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing"
      >urn:uuid:c724a446-4375-4e8a-a318-fd3c84510eae</MessageID>
    ...
    <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">
      <wsc:SecurityContextToken xmlns:wsc=".../ws-secureconversation/200512"
        xmlns:wsu="...wssecurity-utility-1.0.xsd"
        wsu:Id="sctId-A167EB2B526E0894DA12736604029099">
        <wsc:Identifier>A167EB2B526E0894DA12736604029098</wsc:Identifier>
      </wsc:SecurityContextToken>
      <wsc:DerivedKeyToken xmlns:wsc=".../ws-secureconversation/200512"
        xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="derivedKeyId-9">
        <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd">
          <wsse:Reference xmlns:wsse="..." URI="#sctId-A167EB2B526E0894DA12736604029099"
          ValueType="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/sct"/>
        </wsse:SecurityTokenReference>
        <wsc:Offset>0</wsc:Offset>
        <wsc:Length>16</wsc:Length>
        <wsc:Nonce>AyUGKYBNNQstD9EmZUJqlA==</wsc:Nonce>
      </wsc:DerivedKeyToken>
      <wsc:DerivedKeyToken xmlns:wsc=".../ws-secureconversation/200512"
        xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="derivedKeyId-11">
        ...
      </wsc:DerivedKeyToken>
      <xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
        <xenc:DataReference URI="#EncDataId-12"/>
      </xenc:ReferenceList>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-10">
        <ds:SignedInfo>
          ...
          <ds:Reference URI="#Id-28812627">
            ...
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>6NHo8Si1ntZIb2Ivg3S/n1+2uzI=</ds:SignatureValue>
        <ds:KeyInfo Id="KeyId-CF15C330C32618BF4912736604029689">
          <wsse:SecurityTokenReference xmlns:wsse="..." xmlns:wsu="..."
          wsu:Id="STRId-CF15C330C32618BF49127366040296810">
            <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-9"/>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-28812627">
    <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" ...>
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd">
          <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-11"/>
        </wsse:SecurityTokenReference>
      </ds:KeyInfo>
      <xenc:CipherData>
        <xenc:CipherValue>+krS8lGA...CKSN0fwKR36Q==</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </soap:Body>
</soap:Envelope>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing"
      >http://ws.sosnoski.com/seismic/wsdl/SeismicInterface/quakeResponse</Action>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing"
      >urn:uuid:c3aa0671-8751-4d6b-8d4c-0e37ce3e394a</MessageID>
    <To xmlns="http://www.w3.org/2005/08/addressing"
      >http://www.w3.org/2005/08/addressing/anonymous</To>
    <RelatesTo xmlns="http://www.w3.org/2005/08/addressing"
      >urn:uuid:c724a446-4375-4e8a-a318-fd3c84510eae</RelatesTo>
    <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">
      <wsc:DerivedKeyToken xmlns:wsc="...ws-secureconversation/200512"
      ...
      </wsc:DerivedKeyToken>
      <wsc:DerivedKeyToken xmlns:wsc="...ws-secureconversation/200512"
      ...
      </wsc:DerivedKeyToken>
      <xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
        <xenc:DataReference URI="#EncDataId-12"/>
      </xenc:ReferenceList>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-10">
        <ds:SignedInfo>
          ...
          <ds:Reference URI="#Id-10766816">
            ...
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>rU6YoV7BiO0qSQjWw2vwCp9R+fg=</ds:SignatureValue>
        <ds:KeyInfo Id="KeyId-A167EB2B526E0894DA127366040304813">
          <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd" ...>
            <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-9"/>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-10766816">
    <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" ...>
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd">
          <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-11"/>
        </wsse:SecurityTokenReference>
      </ds:KeyInfo>
      <xenc:CipherData>
        <xenc:CipherValue>Cl0iUu...TJ6WkZl2A==</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </soap:Body>
</soap:Envelope>

В листинге 5 токен SecurityContextToken включается в заголовки каждого сообщения. Также он указывается в элементах <wsc:DerivedKeyToken>, предоставляющих параметры, используемые для получения секретного ключа, непосредственно применяемого для подписи и шифрования данных.


Была ли эта статья полезной?

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java, SOA и web-сервисы
ArticleID=789479
ArticleTitle=Web-сервисы Java: WS-Trust и WS-SecureConversation
publish-date=01262012