Перед тем как приступить к объяснению, что такое WS-Security, я уверен, важно понять, почему вообще существует WS-Security. Многие новички в Web сервисах видят SOAP как способ обмена сообщениями между двумя точками через HTTP. С помощью HTTP можно идентифицировать вызывающего, подписать сообщение и закодировать содержимое сообщения. Это формирует систему безопасности сообщения в нескольких измерениях: вызывающий известен, получатель сообщения может проверить, что сообщение не было изменено при передаче, и сущности, отслеживающие трафик, не могут определить обмен какими данными происходит. Для тех, кто рассматривает механизм обмена SOAP сообщениями как возможность решения больших проблем, системы безопасности на основе HTTP просто не достаточно. Большие проблемы вовлекают пересылку более сложных, чем запрос/ответ, сообщений или используют средства транспортировки, которые не используют HTTP. Идентичность, целостность и безопасность сообщения и вызывающего должны сохраняться в течение многих пересылок. Во время пересылки возможно использование более одного ключа шифрования. HTTP и его механизм безопасности обеспечивают безопасность только из точки в точку. Более сложным решениям необходимо обеспечение безопасности из конца в конец. WS-безопасность обращается к тому, как обеспечить безопасную передачу содержимого сообщения при многопунктовой передаче.

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

Промышленность решила многие подобные проблемы. Kerberos и X.509 обращаются к идентификации. X.509 также использует существующий PKI для управления ключами. XML Encryption и XML Signature описывают способы шифрования и подписи содержимого XML сообщений. XML Canonicalization описывает способы подготовки XML к подписанию и шифрованию. Что же добавляет WS-Security к этим существующим спецификациям? Оболочку для встраивания этих механизмов в SOAP сообщение. Это делается в режиме независимости от способа транспортировки.

Для переноса данных, связанных с обеспечением безопасности, WS-Security определяет элемент - SOAP Заголовок (Header). Если используется XML Signature, этот заголовок может содержать информацию, определенную XML Signature, которая указывает на то, как сообщение было подписано, какой ключ использовался и результирующее значение подписи. Аналогично, если элемент в сообщении зашифрован, информация о шифровании, подобная той, которую транспортирует XML Encryption, может содержаться в заголовке WS-Security. WS-Security не определяет формата подписи или шифрования. Вместо этого она устанавливает, как будет встраиваться в SOAP сообщение информация по безопасности, подготовленная другими спецификациями. WS-Security – это спецификация в основном для безопасных контейнеров метаданных на базе XML.

Что делает WS-Security, кроме использования других существующих протоколов обеспечения идентификации, целостности и конфиденциальности сообщений? Она определяет механизм передачи полномочий простого пользователя посредством элемента UsernameToken. Также определен BinarySecurityToken для того, чтобы пересылать двоичные маркеры, которые использовались для шифрования или подписи сообщения. В этом заголовке сообщения могут сохранять информацию о вызывающем, о том, как было подписано и зашифровано сообщение. WS-Security представляет решение для обеспечения безопасности Web сервиса из конца в конец путем хранения всей информации системы безопасности в SOAP части сообщения.

В этой статье мы рассмотрим то, как использовать WS-Security и другие спецификации для встраивания системы безопасности в само SOAP сообщение. Мы рассмотрим следующие вопросы:

• Идентификацию
• Подписи
• Шифрование

Эта триада обращается к главным проблемам безопасности и отвечает на вопросы:

• Кого я авторизую?
• Было ли изменено сообщение при пересылке?
• Пришло ли это сообщение именно от того, от кого я думаю?
• Как я спрячу вещи, от которых я хочу видеть только определенные части?

Для начала, давайте рассмотрим некоторые аналогии, просматриваемые в повседневной жизни.

Чтобы понять, что пытается сделать WS-Security, я сначала хочу взглянуть на параллели реального мира. А в частности, когда и как вы используете удостоверения (credentials) в каждодневной жизни? Как-никак, вы жизни вы все время пользуетесь удостоверениями. Если кто-то просит вас подтвердить свой возраст, вы залезаете в свой бумажник и вытаскиваете водительские права. Когда вы оплачиваете товары, для идентификации вашей личности кредитное учреждение использует кредитную карточку. При пересечении государственной границы или в иностранном государстве вашу личность удостоверяет паспорт. Все эти вещи – это удостоверения (credentials). Они подтверждают, что владелец кредитной карточки, водительских прав или паспорта – это именно тот человек, который назван в документе. Хотя они не удостоверяют подлинности вашей личности. Аутентификация (подтверждение подлинности) – это действие, которое документ не может осуществить. В мире бумажных документов аутентификацию осуществляют люди. Как же проводится аутентификация?

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

• Оба документа содержат фотографию зарегистрированного владельца, а также другие идентифицирующие характеристики: рост, вес и цвет глаз. Человек, проверяющий документ, может убедиться в том, что вы выглядите также, как и человек, показанный и описанный в документе.
• Срок действия документа ограничен. Это делается для того, чтобы в документе были представлены именно современные данные.
• В документе есть подпись, которую можно сравнить с подписью человека, его предъявляющего. Сложность точного воспроизведения подписи другого человека делает обоснованным ее использование вместе с описанием человека для установления идентичности личности.

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

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

Что же тогда делают такие документы как кредитная карточка?

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

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

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

В конце концов, мы тоже хотим иметь механизм сокрытия информации от несанкционированных сторон. В мире идентификации личности я подтверждаю, кто я есть, предъявляя водительские права или паспорт. Я доказываю, что имею определенные права, с помощью членской карточки. В моем бумажнике есть карточки, которые обеспечивают мне возможность получать товары и услуги, оформлять библиотечные книги, направлять медицинские счета моей страховой компании и получать скидки в местных гастрономах. WS-Security обеспечивает мне возможность применять те же концепции к SOAP сообщениям. Используя маркеры безопасности для идентификации вызывающего и подтверждения его прав, сообщение может переправлять следующую информацию:

• Идентификацию вызывающего: Я Joe User.
• Принадлежность к группе: Я ColdRooster.com разработчик.
• Подтверждение прав: Поскольку я ColdRooster.com разработчик, я могу создавать базы данных и добавлять Web приложения в машины ColdRooster.com.

Чтобы создать сообщение, которое может создать новую базу данных на серверах ColdRooster.com, используя такую технологию аутентификации как Kerberos, приложению придется запрашивать некоторые маркеры доступа. Приложению, создающему сообщение, понадобится запросить маркеры доступа, которые идентифицируют его, как действующего от лица Joe User. Joe User предоставляет эти признаки при входе в системы с помощью имя пользователя/пароля или используя смарт-карту. Полагая, что инфраструктура системы безопасности использует Kerberos, среда, используемая Joe, имеет Центр распределения ключей (Key Distribution Center), который присваивает Joe при его входе в систему Ticket Granting Ticket (TGT). Когда Joe принимает решение создавать новую базу данных в ColdRooster.com, среда идет в Сервис присваивания удостоверений (Ticket Granting Service) и запрашивает Удостоверение сервиса (Service Ticket), который показывает, что у Joe есть право на создание новой базы данных на ColdRooster.com. Среда берет это Удостоверение сервиса (Service Ticket (ST)) и представляет его серверу базы данных в ColdRooster.com. Этот сервер проверяет достоверность удостоверения и затем позволяет Joe создавать новый процесс.

WS-Security стремится инкапсулировать взаимодействия системы безопасности, описанные выше, в наборе SOAP заголовков. WS-Security осуществляет управление удостоверениями двумя способами. Если Web сервис использует обычную аутентификацию, определяется специальный элемент UsernameToken для передачи имени пользователя и пароля. WS-Security также предоставляет место для обеспечения двоичных маркеров, таких как Kerberos Tickets и X.509 сертификатов: BinarySecurityToken.

На Рисунке 1 показано, что станет довольно обычной передачей сообщения.

Рисунок 1. Обычная передача сообщения.

Сервисом Маркера доступа (Security Token) могут быть Kerberos, PKI или сервис проверки достоверности имени пользователя/пароля. Этот сервис может не основываться на Web сервисе. Действительно, к Сервису присваивания сертификатов (Ticket Granting Service) сервиса Kerberos можно доступаться через протоколы Kerberos, используя функции системы безопасности операционной системы. Как только клиент получит маркеры, которые хочет использовать в сообщении, он встроит их в сообщение. Клиент должен подписать сообщение данными, известными только им. Сервер сможет проследить сигнатуру несколькими способами. Если для аутентификации клиент использует UsernameToken, клиент должен послать хэшированный пароль и подписать сообщение, используя этот пароль. Сервер сможет проверить то, что клиент отправил сообщение, если подписи, генерируемые им для сообщения, совпадают с подписями, содержащимися в сообщении.

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

Если важна аутентификация, критичным является то, были ли подписаны или зашифрованы SOAP сообщения. Почему? Достоверный маркер идентичности недостаточен для сообщения. Эти маркеры могут быть украдены из достоверных сообщений и добавлены в сообщения, используемые хакерами. Необходимы доказательства того, что идентичность, используемая в сообщении, создала сообщение. Без использования XML Подписи и подписывания сообщения вы не можете сказать, что сообщение не было изменено или что маркер идентичности не был испорчен.

Здесь, я думаю, вы понимаете, что делает WS-Security. Давайте копнем поглубже и посмотрим как это происходит.

Начиная с этого раздела и далее в статье я буду использовать фрагменты XML. Но чтобы мне не приходилось везде показывать описания Пространства имен XML и загрязнять фрагменты, используемые Пространства имен XML я вынес в Таблицу 1:

Таблица 1: Пространства имен XML

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

<xs:element name="Security">
    <xs:complexType>
        <xs:sequence>
        <xs:any processContents="lax" 
            minOccurs="0" maxOccurs="unbounded">
        </xs:any>
        </xs:sequence>
        <xs:anyAttribute processContents="lax"/>
    </xs:complexType>
</xs:element>

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

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

Итак, как посредник знает, какой заголовок WS-Security у него есть? SOAP сообщение может содержать множество заголовков WS-Security. Каждый заголовок идентифицирован уникальным актором. Один и тот же актор не может использоваться двумя заголовками WS-Security, актор не может быть пропущен. Использование актора упрощает посредникам процесс определения, какие заголовки WS-Security содержат необходимую им информацию. Конечно же, посреднику не надо знать, URI какого актора он обрабатывает. Ассоциирование URI с актором и обеспечение того, что посредник знает, что делать, - это то, что должно управляться программно. Атрибут actor в любом SOAP заголовке означает: этот заголовок предназначен для любой конечной точки, действующей с capacity, указанной URI актора. Что дает это значение URI? Команда, которая создает Web сервис присваивает URI значение. Это значит, что посредник может работать с разными capacities. В результате, посредник может потреблять ноль, один или более заголовков. Да, он даже может потреблять множество заголовков безопасности.

После составления мнения о WS-Security обнаружилось, что некоторое количество элементов необходимо сделать более прозрачными для системы безопасности, в частности. А в общем, также необходимо определить дополнительные элементы для Web сервисов. Части приложения, применяемые для системы безопасности, раскрываются в статье. В этом разделе я хочу рассмотреть два элемента, не характерных для системы безопасности: wsu:Id и wsu:Timestamp. Приложение конкретно определяет, что эти два элемента делают, и как их надо использовать.

wsu:Id

Атрибут Id использует тип ID XML Schema. Этот элемент был добавлен для облегчения обработки для посредников Web сервисов, а также получателей. Значение этого атрибута не должно дублироваться нигде в документе. Приложение не углубляется в детали того, как должен использоваться элемент, кроме использования его в качестве уникального идентификатора в спецификациях GXA. Дверь остается широко открытой, чтобы предоставить возможность другим спецификациям ограничить использование Id.

wsu:Timestamp

Общей проблемой в сообщение-ориентированных системах является своевременность данных. Если данные слишком старые, их можно выбросить. Если приходят два противоречивых сообщения, связанные с ними временные метки могут использоваться для определения, какое сообщение обрабатывать, а какое проигнорировать. Чтобы решить связанные со временем проблемы, выявленные в WS-Security и которые обнаружатся в других GXA спецификациях, был определен элемент wsu:Timestamp вместе с несколькими вспомогательными элементами.

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

• wsu:Created: содержит время создания сообщения.
• wsu:Expires: задается отправителем или посредником, определяет время аннулирования сообщения.
• wsu:Received: описывает, когда сообщение было получено конкретным посредником.

Все приведенные выше элементы могут появляться независимо или как часть элемента wsu:Timestamp. Каждый может содержать атрибут wsu:Id для уникального определения элемента. По умолчанию эти временные метки выражают время как тип xs:dateTime. Чтобы обеспечить гибкость для других, нестандартных временных меток, которые могут обрабатываться в других проблемных доменах, каждый из этих элементов также содержит атрибут ValueType. Этот атрибут не нужен, если время выражено как xs:dateTime.

Элемент wsu:Received предусматривает два дополнительны атрибута, не определенных в wsu:Created или wsu:Expires. Элемент может выражать URI актора, с которым он связан, используя атрибут Actor и величину задержки, в миллисекундах, обусловленную актором, с помощью атрибута Delay.

Как я уже говорил, вы можете использовать элементы wsu:Received, wsu:Created и wsu:Expires в других структурах. Например, возможно, обычно видеть wsu:Created элемент, используемый для отображения того, когда конкретный элемент был добавлен в сообщение. При отображении большей информации о сообщении и использовании более одного таких элементов одновременно, элементы могут быть завернуты в элемент wsu:Timestamp. Каждый из трех элементов может появляться только раз в рамках одной временной метки. Временная метка может использоваться в сообщении как целое, в таком случае она появляется как потомок узла soap:Header. Например, сообщение может показывать, что оно действительно в течение следующих пяти минут, используя следующий заголовок wsu:Timestamp.

<wsu:Timestamp>
    <wsu:Created wsu:Id=
        "Id-2af5d5bd-1f0c-4365-b7ff-010629a1256c">
            2002-08-19T16:15:31Z
    </wsu:Created>
    <wsu:Expires wsu:Id=
        "Id-4c337c65-8ae7-439f-b4f0-d18d7823e240">
            2002-08-19T16:20:31Z
    </wsu:Expires>
</wsu:Timestamp>

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

WS-Security предусматривает бесчисленное множество способов проверки достоверности пользователя. Из этого бесчисленного множества спецификация выделяет три метода:

• Имя пользователя/Пароль
• PKI через сертификаты X.509
• Kerberos

В этом разделе мы рассмотрим то, как работает каждый из этих методов аутентификации и как эта информация шифруется в SOAP сообщение.

Имя пользователя/Пароль

Один из наиболее распространенных способов передачи удостоверения пользователя – использование комбинации имени пользователя и пароля. Это техника, используемая в аутентификациях HTTP Basic и Digest. Собственно говоря, если вы хорошо знакомы с тем, как работает аутентификация HTTP Digest, с этим механизмом аутентификации вы будете чувствовать себя вполне комфортно. Для передачи удостоверения пользователя таким способом, в WS-Security определен элемент UsernameToken. Схема для элемента следующая:

<xs:element name="UsernameToken">
    <xs:complexType>
        <xs:sequence>
            <xs:element ref="Username"/>
            <xs:element ref="Password" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="Id" type="xs:ID"/>
        <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
</xs:element>

Этот фрагмент использует два других типа: Username и Password. Эти два типа, в сущности, - строки, которые, если необходимо, могут содержать дополнительные атрибуты. Password содержит атрибут Type, который отображает, как передается пароль. Пароль может передаваться как простой текст или в цифровом формате. При передаче UsernameToken в SOAP сообщении XML может выглядеть как нечто такое:

<wsse:UsernameToken>
    <wsse:Username>scott</wsse:Username>
    <wsse:Password Type="wsse:PasswordText">password</wsse:Password>
</wsse:UsernameToken>

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

<wsse:UsernameToken>
    <wsse:Username>scott</wsse:Username>
    <wsse:Password Type="wsse:PasswordDigest">
        KE6QugOpkPyT3Eo0SEgT30W4Keg=</wsse:Password>
    <wsse:Nonce>5uW4ABku/m6/S5rnE+L7vg==</wsse:Nonce>
    <wsu:Created xmlns:wsu=
        "http://schemas.xmlsoap.org/ws/2002/07/utility">
            2002-08-19T00:44:02Z
    </wsu:Created>
</wsse:UsernameToken>

Это добавляет немного безопасности, потому что пароль теперь скрыт с помощью SHA1 хэша. Цифровой пароль является объединением данного времени, времени создания и пароля. Данное время занимает 16 байт и передается как шифрованное значение base64. Клиент создает хэш пароля, используя эту информацию плюс пароль. Получатель проверяет данные, получая простой пароль и создавая хэш снова. Если результаты соответствуют, пароль должен быть правильным. Эта защита не защищает от атак воспроизведения. Если вы используете ее, убедитесь, что вы также включили заголовок wsu:Timestamp с достаточно малым временным окном для значений создания и аннулирования. Затем подпишите элементы wsu:Timestamp в сообщении таким образом, чтобы можно было определить любые манипуляции и временными метками. В противном случае, хакер может использовать полный UsernameToken для атаки на ваш Web сервис. Для защиты против атаки воспроизведения вам также понадобится включить механизм, отслеживающий некоторые уникальные характеристики поступающих сообщений. Этому механизму надо сохранять эти характеристики в кэше на, по крайней мере, период ожидания сообщения.

Сертификаты X.509

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

Когда сообщение посылает сертификат X.509, оно передаст открытую версию сертификата в маркер WS-Security BinarySecurityToken. Сам сертификат получает отправленное как шифрованные base64 данные. BinarySecurityToken имеет следующую схему:

<xs:element name="BinarySecurityToken">
    <xs:complexType>
        <xs:simpleContent>
            <xs:extension base="xs:string">
                <xs:attribute name="Id" type="xs:ID" />
                <xs:attribute name="ValueType" type="xs:QName" />
                <xs:attribute name="EncodingType" type="xs:QName" />
                <xs:anyAttribute namespace="##other" 
                    processContents="strict" />
            </xs:extension>
        </xs:simpleContent>
    </xs:complexType>
</xs:element>

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

• wsse:X509v3: X.509, версия 3 сертификата.
• wsse:Kerberosv5TGT: A ticket granting ticket, как определено разделом 5.3.1 спецификации Kerberos.
• wsse:Kerberosv5ST: A service ticket, как определено разделом 5.3.1 спецификации Kerberos.

Если эта информация по Kerberos ничего не значит для вас, я немного лучше объясню это в следующем разделе. EncodingType – это другое перечисление. Оно может быть wsse:Base64Binary или wsse:HexBinary. Как вы могли догадаться, это значение просто отображает, какой метод шифрования использовался. В заголовке WS-Security этот элемент при передачи сертификата X.509 будет выглядеть примерно так:

<wsse:BinarySecurityToken 
    ValueType="wsse:X509v3" 
    EncodingType="wsse:Base64Binary" 
    Id="SecurityToken-f49bd662-59a0-401a-ab23-1aa12764184f"
>MIIHdjCCB...</wsse:BinarySecurityToken>

Помните, когда вы используете сертификат X.509, вы хотите также сделать что-то еще, например, подписать сообщение. Эта подпись, созданная путем использования секретного ключа сертификата, подтверждает, что клиент – законный владелец сертификата. Такое сообщение может быть воспроизведено. Для уменьшения проблем воспроизведений вы должны ввести политику, которая определяет возраст сообщения, при достижении которого оно игнорируется. Время передается в элементе wsu:Timestamp, который поставляется как SOAP Header в сообщении.

Kerberos

Чтобы использовать Kerberos, пользователь представляет набор удостоверений, таких как имя пользователя/пароль или сертификат X.509. Если все подтверждается, система безопасности предоставляет пользователю ticket granting ticket (TGT). TGT – это непрозрачная часть данных, которые пользователь не может считать, но должен представить, чтобы доступаться к другим ресурсам. Обычно пользователь представляет TGT, чтобы получить Удостоверение сервиса (Service Ticket) (ST). Система работает следующим образом:

1. Клиент аутентифицируется Key Distribution Center (KDC), и ему предоставляется TGT.
2. Клиент принимает TGT и использует его для доступа к Ticket Granting Service (TGS).
3. Клиент запрашивает ST для конкретного ресурса сети. Затем TGS выпускает ST для клиента.
4. Клиент представляет ST ресурсу сети и начинает доступаться к ресурсу с разрешением, указанным в ST.

Привлекательность Kerberos в том, что он содержит механизм для подтверждения клиентом identity сервису и для доказательства сервисом его идентичности клиенту. ST подходит только для доступа к сетевому ресурсу и может использоваться для определения, кем является пользователь. При наличии в сообщении Kerberos удостоверения данные должны быть вслепую скопированы в само сообщение. WS-Security не объясняет, как получаются TGT или ST.

Подпись

Когда сообщение подписано, сообщение практически невозможно испортить. Подпись не защищает само сообщение от внешних сторон, просматривающих его содержимое. Используя подпись, получатель SOAP сообщения может знать, что подписанные элементы не были изменены по пути. Насколько это возможно, вы должны использовать XML Signature для подписывания сообщений. Почему? XML Signature уже установила некоторое количество крепких элементов для этого. WS-Security просто описывает, как использовать подпись для подтверждения того, что сообщение не было изменено. Все три упомянутых выше механизма аутентификации предоставляют способ подписания сообщения, поэтому вы можете быть уверенными в двух вещах:

• Пользователь, идентифицированный сертификатом X.509, UsernameToken или Kerberos удостоверением, подписал сообщение.
• Сообщение не изменялось с тех пор, как было подписано.

Каждый из методов использует секрет, который может использоваться для подписи сообщения. X.509 дает возможность отправителю подписывать сообщение с помощью секретного ключа. Kerberos предоставляет сеансовый ключ, который создает и передает в удостоверении отправитель. Только предполагаемый получатель этого сообщения может прочитать удостоверение, узнать сеансовый ключ и проверить аутентичность подписи. И наконец, UsernameToken может быть подписан с помощью пароля.

Подпись генерируется с использованием XML Signature. Чтобы подписать простое сообщение, такое как "Hello World", должен быть отдельно подписан практически каждый элемент в сообщении. wsu:Timestamp представляет интересную проблему, потому что посредник может добавить элемент wsu:Received в wsu:Timestamp. При каждом изменении элемента подпись должна обновляться. Почему? Если изменилось содержимое, подпись не будет совпадать. В SOAP сообщении подписи и необходимые дополнительные данные добавляют совсем немного дополнительной информации.

Шифрование

Обеспечения подлинности отправителя и демонстрации того, что сообщение не было изменено, бывает не достаточно. Если вы посылаете номер кредитной карты или банковский счет в виде простого текста, но способом подписания, хакер может определить, что другие хакеры не изменяли содержимого сообщения. В результате, у них есть глубокая уверенность, что данные действительны. Это не очень хорошо для вас, не так ли? Напротив, вам надо, чтобы данные были зашифрованы так, чтобы только предполагаемый получатель сообщения мог прочитать его. Кто бы ни следил за обменом информацией, он не должен знать о содержимом сообщения. Как и с подписью сообщений, спецификация WS-Security поступила правильно и приняла уже существующий стандарт, который хорошо выполняет работу, связанную с шифрованием. Правильно, они включили XML Encryption.

Когда вы шифруете данные, вы можете выбрать использовать симметричное или асимметричное шифрование. Для симметричного шифрования требуется совместно используемый секрет (shared secret). Т.е. ключ, который используется для шифрования сообщения, - это тот же ключ, который вы будете использовать и для его дешифровки. Симметричное шифрование хорошо, если вы контролируете обе конечные точки и можете доверять людям и приложениям, которые используют ключи. В симметричном шифровании нет проблем с распространением ключей. В некоторый момент времени ключ должен быть отправлен получателю. Как вы делаете это? Вы пересылаете диск по почте или передаете ключ, когда он нужен? И то, и другое.

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

Итак, как будет выглядеть зашифрованное сообщение? Если вы используете Triple-DES, и отправителю, и получателю придется обмениваться ключом каким-то безопасным способом. Симметричный ключ можно спрятать в Kerberos удостоверении или передаваться вне связки. Сообщения WS-Security со встроенной информацией XML Encryption будут выглядеть примерно так:

<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope 
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <soap:Header    
        xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"
        xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
        <wsu:Timestamp>
            <wsu:Created 
                wsu:Id="Id-3beeb885-16a4-4b65-b14c-0cfe6ad26800"
                >2002-08-22T00:26:15Z</wsu:Created>
            <wsu:Expires 
                wsu:Id="Id-10c46143-cb53-4a8e-9e83-ef374e40aa54"
                >2002-08-22T00:31:15Z</wsu:Expires>
        </wsu:Timestamp>
        <wsse:Security soap:mustUnderstand="1" >
            <xenc:ReferenceList>
                <xenc:DataReference 
        URI="#EncryptedContent-f6f50b24-3458-41d3-aac4-390f476f2e51" />
            </xenc:ReferenceList>
            <xenc:ReferenceList>
                <xenc:DataReference 
        URI="#EncryptedContent-666b184a-a388-46cc-a9e3-06583b9d43b6" />
            </xenc:ReferenceList>
        </wsse:Security>
    </soap:Header>
    <soap:Body>
        <xenc:EncryptedData 
            Id="EncryptedContent-f6f50b24-3458-41d3-aac4-390f476f2e51" 
            Type="http://www.w3.org/2001/04/xmlenc#Content">
            <xenc:EncryptionMethod Algorithm=
                "http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <KeyName>Symmetric Key</KeyName>
            </KeyInfo>
            <xenc:CipherData>
                <xenc:CipherValue
                >InmSSXQcBV5UiT...  Y7RVZQqnPpZYMg==</xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedData>
    </soap:Body>
</soap:Envelope>

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

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

WS-Security позволяет определять вызывающего SOAP сообщения, подписывать сообщение и шифровать его содержимое. Для уменьшения количества изобретений, необходимых для безопасной доставки SOAP сообщения, по мере возможности используются существующие спецификации. Поскольку вся информация доставляется в самом сообщении, сообщение становится безразличным к методу транспортировки. Сообщение будет в безопасности, если доставляется через HTTP, по e-mail или на CD-ROM.