5.9.3. Шифрування змісту елементу

Розглянемо Лістинг 8, в якому зашифрований тільки зміст елементу GetSpecialDiscountedBookingForPartners - для цього цей зміст був замінений структурою EncryptedData. Цей прийом схожий на шифрування елементу (див. Лістинг 7). Відмінність полягає в тому, що цього разу значення атрибуту Type тега EncryptedData рівне http://www.w3.org/2001/04/xmlenc#Content. Це значення говорить про те, що зашифровані дані повинні інтерпретуватися як зміст елементу.

Лістинг 8

<?xml version=”1.0”?> <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”> <SOAP-ENV:Body> <s:GetSpecialDiscountedBookingForPartners xmlns:s=“http://www.MyHotel.com/partnerservice/” ID="GetSpecialDiscountedBookingForPartners"> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Content"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:KeyName>MyKeyIdentifier</ds:KeyName> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>B457V645B45........</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </s:GetSpecialDiscountedBookingForPartners> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

5.9.4. Обробка шифрування xml

Розглянемо, як брандмауер XML працює з поняттями шифрування. Брандмауер отримує Лістинг 7 або 8 (SOAP-повідомлення із зашифрованими елементами або змістом) і, перш ніж переслати SOAP-серверу розшифрований запит SOAP-повідомлення, перетворить їх зміст в дешифровану форму.

Одержувач зашифрованого XML-файла (наприклад, в даному випадку брандмауер XML готелю) розшифровує цей XML-файл, виконуючи наступну послідовність дій:

1. Витягує зашифрований зміст елементу CypherValue;

2. Прочитує значення атрибуту алгоритму елементу EncryptionMethod;

3. Прочитує значення атрибуту Type елементу EncryptedData;

4. Отримує інформацію про ключ з елементу ds:KeyInfo;

5. Використовує отриману інформацію для створення простого текстового (розшифрованого) файлу.

5.10. Введення в безпеку Web-сервісів

Виникає питання, яким чином брандмауер XML використовує підписи і шифрування XML для захисту SOAP-серверів? Адже, не дивлячись на те, що можливості цих двох технологій були продемонстровані на численних прикладах, необхідно з'ясувати, як застосовувати ці дві специфікації при використанні брандмауера XML для захисту SOAP-серверів, особливо якщо врахувати жодна з них не є специфічною для SOAP. Потрібно зрозуміти, чому вся інформація, що стосується підпису, була поміщена в заголовок SOAP, а не в тіло SOAP.

Специфікація консорціуму OASIS “Безпека Web-сервісів” детально визначає, як застосовувати технології підпису і шифрування XML при обміні SOAP-повідомленнями. Цей стандарт отримує елементи низького рівня з розглянутих вище специфікацій (“Цифровий підпис XML” і “Шифрування XML”) і задає високорівневий синтаксис для обгортання в SOAP-повідомленнях інформації про безпеку.

Специфікація “Безпеку Web-сервісів” описує механізм безпечного обміну SOAP-повідомленнями. Вона забезпечує наступну функціональність:

1. Цілісність повідомлення;

2. Призначену для користувача аутентифікацію;

3. Конфіденційність.

Розглянемо Лістинг 9 - це SOAP-повідомлення, яке несе інформацію про безпеку згідно синтаксису специфікації “Безпека Web-сервісів”. Лістинг 9 - цей той же самий SOAP-запит GetSpecialDiscountedBookingForPartners, який неодноразово приводився в цьому розділі. Проте цього разу заголовок запиту передає інформацію про цифровий підпис відповідно до даної специфікації.

Лістинг 9

<?xml version="1.0" encoding="utf-8"?> <SOAP:Envelope xmlns:SOAP="http://www.w3.org/2001/12/soap-envelope" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/xx/secext" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <SOAP:Header> <wsse:Security> <wsse:BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary" wsu:Id="MyTourOperatorCertificate"> LKSAJDFLKASJDlkjlkj243kj;lkjLKJ... </wsse:BinarySecurityToken> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml -exc-c14n# "/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#myDiscountRequestBody"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>BSDFHJYK21f...</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> GKLKAJFLASKJ52kjKJKLJ345KKKJ... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#MyTourOperatorCertificate"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </SOAP:Header> <SOAP-ENV:Body> <s:GetSpecialDiscountedBookingForPartners xmlns:s=“http://www.MyHotel.com/partnerservice/” ID="myDiscountRequestBody"> <!--Parameters passed with the method call--> </s:GetSpecialDiscountedBookingForPartners> </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Щоб краще зрозуміти синтаксис специфікації “Безпека Web-сервісів”, розглянемо Лістинг 9:

1. Елемент SOAP:Envelope містить оголошення просторів імен для SOAP, “Безпека Web-сервісів” і “Цифрового підпису XML”.

2. У елементу SOAP:Header є тільки один дочірній елемент (wsse:Security), який є обгорткою для всієї інформації про безпеку. У елементу wsse:Security два дочірні елементи: wsse:BinarySecurityToken і ds:Signature.

3. Елемент wsse:BinarySecurityToken містить маркер доступу (security token). Маркер доступу подібний до пропуску, що видається службою безпеці, або посвідчення особи, яке необхідно пред'явити при вході в область обмеженого доступу. Нижче описані основні типи маркерів доступу. Найбільш популярний і широко використовуваний маркер доступу - це пара логін-пароль, як та, що застосовується при перевірці електронної пошти. Пара логін-пароль - це маркер доступу, призначений для людини. Існують маркери доступу, які мають бінарну форму (і, отже, можуть бути нечитабельні). Такі маркери називаються бінарними маркерами доступу. Наприклад, сертифікат X509 (дуже популярний формат цифрових сертифікатів, розроблений Міжнародним союзом електрозв'язку, - сектори телекомунікацій (International Telecommunications Union - Telecommunications sector, ITU-T)) - це бінарний маркер доступу. Атрибут ValueType елементу wsse:BinarySecurityToken містить інформацію про те, який тип бінарного маркера доступу загорнуть в елемент wsse:BinarySecurityToken. У Лістингу 9 значення цього атрибуту рівне wsse:X509v3, що означає сертифікат X509. Атрибут EncodingType елементу wsse:BinarySecurityToken показує, яке кодування у бінарного маркера доступу. Як вже наголошувалося вище, бінарні дані не можуть бути загорнуті у формат XML. Отже, вони повинні бути перетворені в даний формат (як правило, вони представляються в кодуванні base-64). Сертифікат X509 обернутий в елемент wsse:BinarySecurityToken як зміст цього елементу.

4. Елемент ds:Signature такий самий, як і той, що був розглянутий раніше в розділі про підпис XML. Необхідно звернути увагу на наступні два моменти:

   • Значення атрибуту URI (#myDiscountRequestBody) елементу Reference є ідентифікатором фрагмента, який указує на елемент SOAP:Body. Це означає, що елемент SOAP:Body - це той елемент, який вже був підписаний і обернутий в теги цифрового підпису XML.

   • У елементу ds:KeyInfo є елемент wsse:SecurityTokenReference, який містить посилання на маркери доступу. В даному випадку у нього є дочірній елемент wsse:Reference, атрибут URI якого указує на елемент wsse:BinarySecurityToken, розглянутий в пункті 3 цього розділу. Це означає, що відкритий ключ в сертифікаті X509 (те, що обертає елемент wsse:BinarySecurityToken) використовується для перевірки підпису.

Розглянутий приклад дуже простий, він знайомить з підписаними повідомленнями захищених Web-сервісів.