<s:Body>
<wsse:RequestSecurityTokenResponse> <wsse:RequestedSecurityToken> <wsse:BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary"> KkFPle ... </wsse:3inarySecurityToken> </wsse: RequestedSecu rityToken> </wsse:RequestSecurityTokenRespcnse> </s:Body>
Возвращаемый сертификат размещается в элементе BinarySecurityToken, описанном в WS-Security. Хотя этого нет в данном примере, вместе с сер- тификатом может быть получен закрытый ключ, соответствующий откры- тому ключу для данного сертификата. Для этого в WS-Trust определен элемент в котором может содержаться подобная
информация для всех типов маркеров защиты.
Кроме того, WS-Trust вводит несколько дополнений к элементу Request- SeruiiuToken. Среди них возможность указать алгоритм и размер ключа, которые должны применяться при создании маркера защиты. Так, иници- атор запроса может потребовать использования алгоритма RSA и 1024- битного ключа. и механизм запроса маркера защиты от име-
ни другого пользователя. Третье дополнение служит для указания срока действия маркера защиты и возможности его продления.
WS-Trust предусматривает также механизм подтверждающего запроса - вызов-ответ (challenge/response mechanism), - который применим при запросе маркера защиты. Механизма непосредственной аутентификации, показанного на рис. 5, может быть достаточно, но может быть и так, что службе маркеров защиты понадобится дополнительное подтверждение личности инициатора запроса. Что если, как и в предыдущем примере, зап- рос не содержит временной метки? Откуда служба маркеров защиты узна- ет, что это не воспроизведение того же запроса, но на этот раз отправлен- ного хакером
