Канонізація XML, HTML, XML, DHTML, Інтернет-технології, статті

Білал Сіддікуі

Ця стаття відкриває серію публікацій, що розповідають про Рекомендації міжнародного консорціуму W3C: “Канонічний XML” (Canonical XML) і “Виняткова канонізація XML” (Exclusive XML Canonicalization). У першій статті описується процес канонізації XML, тобто те, як, згідно з відповідною специфікації, встановлюється спрощена форма XML-документа. Спочатку давайте розглянемо, коли і чому може виявитися необхідним канонізувати XML-документ.

Введення

Для того, щоб спілкуються сторони могли обмінюватися значущою інформацією, XML визначає формат структурування даних. Гнучкість правил складання XML означає, що одна і та ж структура документа і одна і та ж частина інформації можуть бути представлені різними XML-документами. Розглянемо Листинги 1 і 2, які логічно рівнозначні, тобто дотримуються однакової структури документа (однакової схеми XML) і призначені для передачі однакової інформації. Незважаючи на те, що зазначені листинги є логічними еквівалентами, XML-файли цих лістингів не містять одну і ту ж послідовність символів (або послідовність байтів або октетів).

Лістинг 1

<?xml version="1.0" ?> 
<rooms>
    <room type="single" charge="50" currency="USD" />
    <room type="double" charge="70" currency="USD" />
    <room type="suite" charge="100" currency="USD" />
</rooms>

Лістинг 2

<?xml version="1.0" ?> 
<rooms>
    <room type="single" currency="USD" charge="50" />
    <room type="double" currency="USD" charge="70" />
    <room type="suite" currency="USD" charge="100" />
</rooms>

В цьому випадку різницю між послідовностями символів і октетів в цих двох XML-файлах пояснюється різним розташуванням атрибутів в елементі room. Розбіжність в потоках октетів для логічно еквівалентних XML-документів може бути викликане і іншими причинами. Мета перебування канонічної (або спрощеною) форми XML-документа – встановити логічну рівноцінність між XML-документами. Згідно з правилами канонізації, певним Консорціумом W3C, канонічна форма двох XML-документів буде однаковою, якщо вони логічно еквівалентні.

Тоді, всякий раз, коли нам потрібно встановити, є чи два XML-документа логічними еквівалентами, ми будемо канонізувати кожен з цих документів і порівнювати ці канонічні форми, зіставляючи октет за октетом. Якщо ці дві канонічні форми містять однакову послідовність октетів, значить, що розглядаються XML-файли є логічними еквівалентами.

Перш ніж перейти до детального розгляду технології процесу канонізації, давайте з’ясуємо, коли і чому необхідно перевіряти логічну рівноцінність XML-документів.

Причини визначення логічної рівноцінності між XML-документами

Електронні XML-підпису – це рекомендація консорціуму W3C, яка визначає XML-формат для підписання XML-документів (а також документів, що не є XML). Можна сказати, що освіта електронної підпису нагадує підписання звичайних паперових документів. Якщо підпис на документах (наприклад, незаповнених чеках) є незмінним атрибутом традиційного бізнесу, то ведення електронного бізнесу через Інтернет, ймовірно, зажадає вміння підписувати електронні документи.

Давайте розглянемо, процес підписання порожнього чека. Незаповнений чек є частиною системи, яка покликана відповідати двом основним вимогам:

До електронних XML-підписам пред’являються такі самі вимоги. Так, штамп, надрукований на банківському чеку, аналогічний алгоритму отримання профілю повідомлення (Message Digest), а роль зразків підпису, зберігаються в банку, виконує криптографічний пара закритий-відкритий ключ (private-public key pair) в сервісі довіри (trust service) інфраструктури відкритих ключів (Public Key Infrastructure, PKI).

Алгоритми отримання профілю повідомлення та інфраструктура відкритих ключів – загальноприйняті терміни, які широко використовуються в літературі з безпеки в Інтернеті. Нижченаведене короткий виклад призначено для XML-програмістів, незнайомих з цим питанням. За більш докладною інформацією див. посилання в кінці статті.

Профіль повідомлення

Алгоритми отримання профілів діють відповідно до октетами повідомлення і класифікує (використовують) їх для обчислення значення профілю. Значення профілю залежать від алгоритму отримання профілю і самого повідомлення. Якщо повідомлення буде модифіковано сторонньою особою, значення профілю можна використовувати для того, щоб виявити цю зміну. Отже, профіль повідомлення є електронним спосіб забезпечення цілісності.

Сервіси довіри інфраструктури відкритих ключів

Сервіси довіри створюють і підтримують криптографічні пари. Подібно до того, як банк є зберігачем ваших грошей і даних про ваших рахунках, ці сервіси є хранителями пар закритий-відкритий ключів.

Закриті ключі є конфіденційною інформацією, тобто тільки сервіс довіри і користувач (що має повноваження ставити підпис) знають значення особистого ключа. З іншого боку, відкриті ключі доступні кожному. Особа, що ставить підпис, використовує свій закритий ключ, щоб в електронному вигляді підписати повідомлення разом із значенням профілю повідомлення. Будь-яка людина може скористатися відкритим ключем, щоб перевірити справжність цього підпису і профілю повідомлення. Відкриті ключі можна використовувати тільки для перевірки підписів, вони не можуть використовуватися для створення підписів. Отже, до тих пір, поки зберігається конфіденційність вашого закритого ключа, ви застраховані від “підробки” свого підпису.

Підписання цифрових даних

Підписання XML-документа виконується в два етапи. Спочатку користувач класифікують XML-файл, що підлягає підписанню, і синтезує значення профілю. Потім, він підписує і XML-повідомлення і профіль з допомогою користувацького закритого ключа.

Перевірка справжності підписів

Додаток, який отримує підписане повідомлення, буде встановлювати достовірність підписаного повідомлення за допомогою відкритого ключа, яке належить особі, що поставило це повідомлення, а також контролювати цілісність повідомлення за допомогою перевірки профілю повідомлення. Процес класифікування XML-повідомлення спирається на послідовність байтів, які представляє XML-повідомлення. Фактично, це послідовність байтів, яка утворюють підпис і значення профілю повідомлення. А це означає, що Листинги 1 і 2, хоч і представляють одну і ту ж інформацію, не синтезують однакове значення профілю. Якщо ви підпишіть Лістинг 1, а отримує сторона спробує перевірити Лістинг 2, спираючись на вашу підпис (що більш ніж розумно, оскільки ці обидва документи несуть однакову інформацію), процес верифікації потерпить невдачу.

Канонізація, що передує підписанню та перевірку

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

Канонізація XML-документа

Специфікація канонічного XML визначає алгоритм складання канонічної форми XML-документів. Для того, щоб канонізувати XML-документ, необхідно виконати наступну послідовність дій:

1. Схема кодування (Encoding Scheme)

Всі XML-документи складаються з тексту, який може бути прочитаний людиною і якої є послідовністю символів. Схеми кодування призначені для позначення символом за допомогою октетів. Отже, якщо змінити кодування XML-файла, то один і той же XML-файл може бути представлений абсолютно різним потоком октетів.

Специфікація канонічного XML вимагає, щоб канонічна форма XML-документів була в кодуванні UTF-8. Отже, якщо XML-файл, який підлягає канонізації, має будь-яку іншу систему кодування, її необхідно змінити на UTF-8.

2. Обриви рядків

Зазвичай обриви рядків зображуються в текстових файлах за допомогою шестнадцатірічное А (десяткове 10) або шестнадцатірічное D (десяткове 13), або комбінації цих двох октетів. Оскільки XML-файли є простими текстовими файлами, у всіх XML-файлах як розривів рядків використовуються # xA і # xD.

Згідно канонічної формі XML, все розриви рядків (# xD або комбінація # xA і # xD) повинні бути замінені на # xA. Ця вимога має бути виконано до початку обробки XML-файла.

3. Нормалізація значень атрибутів

Необхідно, щоб усі атрибути були нормалізовані в канонічній формі, як якщо б це виконав верифікаційний XML-парсер. Процес нормалізації значень атрибутів викладено в рекомендації W3C XML 1.0 (див. Ресурси).

Простий приклад нормалізації значень атрибутів

Лістинг 3

<?xml version="1.0"?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory "Part has been tested according
       to the specified standards.">
]>

<product xmlns="http://www.myFictitiousCompany.com/product"
         xmlns:sup="http://www.myFictitiousCompany.com/supplier"
         name='rotating disc "Energymeter"'
         id="P 184.435"
         classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>&testhistory;</comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>&testhistory;</comments>
        </part>
    </parts>
</product>

Лістинг 4

<?xml version="1.0"?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory "Part has been tested according to the specified standards.">
]>

<product xmlns="http://www.myFictitiousCompany.com/product"
         xmlns:sup="http://www.myFictitiousCompany.com/supplier"
         name='rotating disc "Energymeter"'
         id="P 184.435"
         classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>&testhistory;</comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>&testhistory;</comments>
        </part>
    </parts>
</product>

Лістинг 3 – це вихідний XML-файл до нормалізації значень атрибутів; в Лістинг 4 значення всіх атрибутів представлені в нормалізованому вигляді.

Всі атрибути в Лістингу 3 відносяться до строчному типу без будь-яких посилань на розділ (entity) і символ. У цьому випадку нормалізація значення атрибута просто увазі нормалізацію вільного місця (все типи вільного місця [white space], то є символи табуляції, розриви рядків і нерозривні прогалини, повинні бути перетворені в # x20, який є октетом, що становлять нерозривні пробіли). Всі атрибути id в Лістингу 3 мають у них два символи табуляції. Кожен символ табуляції в атрибуті id в Лістингу 3 був замінений в Лістингу 4 на пробіл.

4. Подвійні лапки для значень атрибутів

У канонічної формі для викладу (encapsulate) значень атрибута можуть використовуватися тільки подвійні лапки. Погляньте на Лістинг 4, де атрибут name елемента product укладено в одинарні лапки. В Лістингу 5 одинарні лапки навколо атрибута name замінені на подвійні.

Лістинг 5

<?xml version="1.0"?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory "Part has been tested according to the specified standards.">
]>

<product xmlns="http://www.myFictitiousCompany.com/product"
         xmlns:sup="http://www.myFictitiousCompany.com/supplier"
         name="rotating disc "Energymeter""
         id="P 184.435"
         classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>&testhistory;</comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>&testhistory;</comments>
        </part>
    </parts>
</product>

5. Спеціальні символи в значеннях атрибутів та зміст символів

Однак, заміна одинарних лапок на подвійні в Лістингу 5 привела до виникнення наступної проблеми. Цей лістинг більше не є правильно оформленим XML-файлом, оскільки рядок, що представляє значення атрибута name, Вже містить подвійні лапки, які є частиною значення рядка. Для вирішення цієї проблеми, згідно специфікації канонічного XML, необхідно замінити всі спеціальні символи (наприклад, подвійні лапки) в значеннях атрибутів та утриманні елементів на символьні розділи (наприклад, “для подвійних лапок). Лістинг 6 – результат застосування цього правила до лістингу 5.

Лістинг 6

<?xml version="1.0"?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory "Part has been tested according to the specified standards.">
]>

<product xmlns="http://www.myFictitiousCompany.com/product"
         xmlns:sup="http://www.myFictitiousCompany.com/supplier"
         name="rotating disc "Energymeter""
         id="P 184.435"
         classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>&testhistory;</comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>&testhistory;</comments>
        </part>
    </parts>
</product>

6. Посилання на розділ

Лістинг 6 містить декларацію DTD (Опис шаблону документа), яка описує розділ, званий testhistory (історія тестування). На цей розділ testhistory посилається зміст елемента comments.

Канонічний XML вимагає, щоб всі посилання на розділ були замінені на утримання, представлене розділом (наприклад, в Лістингу 6 розділ testhistory представляє рядок “Part has been tested according to the standards” (“Частина була відтестували згідно із зазначеними стандартам”)). Лістинг 7 – результат заміни посилань на розділ в Лістингу 6.

Лістинг 7

<?xml version="1.0"?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory "Part has been tested according to the specified standards.">
]>

<product xmlns="http://www.myFictitiousCompany.com/product"
         xmlns:sup="http://www.myFictitiousCompany.com/supplier"
         name="rotating disc "e;Energymeter"e;"
         id="P 184.435"
         classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
    </parts>
</product>

Декларація DTD в Лістингу 7 визначає атрибут за замовчуванням, званий >approvedpart. Жоден з тегів part в Лістингу 7 не містить цього атрибута.

Канонічний XML вимагає, щоб атрибути за замовчуванням були включені в канонічну XML-форму. Лістинг 8 – результат додавання атрибута approved із значенням за умовчанням в Лістингу 7.

Лістинг 8

<?xml version="1.0"?>
<!DOCTYPE product [
<!ATTLIST part approved CDATA "yes">
<!ENTITY testhistory "Part has been tested according to the specified standards.">
]>

<product xmlns="http://www.myFictitiousCompany.com/product"
         xmlns:sup="http://www.myFictitiousCompany.com/supplier"
         name="rotating disc "e;Energymeter"e;"
         id="P 184.435"
         classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing"
              approved="yes">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product"
              approved="yes">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>Part has been tested according to the
specified standards.</comments>
        </part>
    </parts>
</product>

8. Декларації XML і DTD

Канонічний XML не вимагає декларацій XML і DTD. Отже, декларації XML і DTD повинні відображатися в канонічній формі. Незважаючи на те, що ми використовували декларацію DTD при заміні посилань на розділ і додаванні атрибутів за умовчанням, наявні декларації XML і DTD повинні бути видалені, як показано в лістингу 9.

Лістинг 9

<product xmlns="http://www.myFictitiousCompany.com/product"
         xmlns:sup="http://www.myFictitiousCompany.com/supplier"
         name="rotating disc "e;Energymeter"e;"
         id="P 184.435"
         classification = "MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675"
              name="bearing"
              approved="yes">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>Part has been tested according to the specified standards.>/comments>
        </part>
        <part id="P 184.871"
              name="magnet"
              xmlns="http://www.myFictitiousCompany.com/product"
              approved="yes">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>Part has been tested according to the specified standards.>/comments>
        </part>
    </parts>
>/product>

9. Вільне місце в елементі документа

Канонічний XML-документ починається з символу ‘<'. Це означає, що перед першим вузлом не повинно бути вільного місця.

10. Вільне місце в початкових і кінцевих елементах

У канонічної формі початкові і кінцеві елементи повинні мати нормалізоване вільне місце. Це означає, що повинні виконуватися такі вимоги:

  • Між лівою кутовий дужкою (‘<') І ім'ям першого елемента не повинно бути вільного місця. Аналогічно, вільне місце має бути відсутнім між косою рисою ('/') І ім'ям кінцевого елемента.
  • Між ім’ям елемента і ім’ям першого атрибута, якщо такий є, повинен бути присутнім єдиний символ # x20.
  • До і після знака рівності в парах атрибут-значення не повинно бути вільного місця.
  • Між парами атрибут-значення має бути символ # x20.
  • За закриває лапками значення останнього атрибута не повинно бути вільного місця.
  • У разі відсутності атрибутів, між ім’ям елемента і правої кутової дужки (‘>’) не повинно бути вільного місця.

Лістинг 10 – результат нормалізації вільного місця в початкових і кінцевих елементахЛістінга 9

Лістинг 10

<product xmlns="http://www.myFictitiousCompany.com/product" xmlns:sup="http://www.myFictitiousCompany.com/supplier" 
name="rotating disc "e;Energymeter"e;" id="P  184.435" classification="MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675" name="bearing" approved="yes">
            <sup:supplier id="S 1753"/>
            <sup:supplier id="S 2341"/>
            <sup:supplier id="S 3276"/>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
        <part id="P 184.871" name="magnet" xmlns="http://www.myFictitiousCompany.com/product" approved="yes">
            <sup:supplier id="S 3908"/>
            <sup:supplier id="S 4589"/>
            <sup:supplier id="S 1098"/>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
    </parts>
</product>

11. Порожні елементи

Канонічний XML вимагає наявності початкового і кінцевого тегів для всіх елементів, у тому числі і для порожніх елементів. Отже, все порожні елементи у вигляді повинні бути перетворені до . Лістинг 11 – результат застосування цього правила до лістингу 10.

Лістинг 11

<product xmlns="http://www.myFictitiousCompany.com/product" xmlns:sup="http://www.myFictitiousCompany.com/supplier" 
name="rotating disc "Energymeter"" id="P  184.435" classification="MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675" name="bearing" approved="yes">
            <sup:supplier id="S 1753"></sup:supplier>
            <sup:supplier id="S 2341"></sup:supplier>
            <sup:supplier id="S 3276"></sup:supplier>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
        <part id="P 184.871" name="magnet" xmlns="http://www.myFictitiousCompany.com/product" approved="yes">
            <sup:supplier id="S 3908"></sup:supplier>
            <sup:supplier id="S 4589"></sup:supplier>
            <sup:supplier id="S 1098"></sup:supplier>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
    </parts>
</product>

12. Декларація простору імен

В Лістингу 11 присутні три декларації просторів імен, два в елементі product і одна в другому елементі part. Канонічний XML вимагає збереження всіх декларацій самих просторів імен (разом з префіксами простору імен) крім декларацій надлишкових просторів імен (такі декларації не впливають на контекст простору імен в будь-якому вузлі XML-файла).

Простір імен, оголошене у другому елементі в product Лістингу 11, є надмірною. Його видалення з цього елемента не вплине на контекст простору імен в будь-якому вузлі цього файлу. Ось чому Лістинг 12 не включає саме цю декларацію простору імен, залишивши решту Лістинг 11 без змін.

Лістинг 12

<product xmlns="http://www.myFictitiousCompany.com/product" xmlns:sup="http://www.myFictitiousCompany.com/supplier" 
name="rotating disc "Energymeter"" id="P  184.435" classification="MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675" name="bearing" approved="yes">
            <sup:supplier id="S 1753"></sup:supplier>
            <sup:supplier id="S 2341"></sup:supplier>
            <sup:supplier id="S 3276"></sup:supplier>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
        <part id="P 184.871" name="magnet" approved="yes">
            <sup:supplier id="S 3908">>/sup:supplier>
            <sup:supplier id="S 4589">>/sup:supplier>
            <sup:supplier id="S 1098"></sup:supplier>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
    </parts>
</product>

13. Порядок атрибутів і декларацій просторів імен

Згідно з канонічним XML, всі декларації просторів імен і атрибутів повинні бути приведені в лексикографічному порядку, за зростанням. Усередині відкриває елемента спочатку повинні слідувати декларації всіх просторів імен, а потім пари атрибут-значення. Лістинг 13 – результат застосування цієї вимоги до лістингу 12.

Лістинг 13

<product xmlns="http://www.myFictitiousCompany.com/product" xmlns:sup="http://www.myFictitiousCompany.com/supplier" 
name="rotating disc "Energymeter"" id="P  184.435" classification="MeasuringInstruments/Electrical/Energy/">
    <parts>
        <part id="P 184.675" name="bearing" approved="yes">
            <sup:supplier id="S 1753"></sup:supplier>
            <sup:supplier id="S 2341"></sup:supplier>
            <sup:supplier id="S 3276"></sup:supplier>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
        <part id="P 184.871" name="magnet" approved="yes">
            <sup:supplier id="S 3908"></sup:supplier>
            <sup:supplier id="S 4589"></sup:supplier>
            <sup:supplier id="S 1098"></sup:supplier>
            <comments>Part has been tested according to the specified standards.</comments>
        </part>
    </parts>
</product>

Лістинг 13 – це остаточна канонічна форма всіх лістингів, починаючи з 3-го і закінчуючи 12-м.

Виключно заради різноманітності розглянемо ще один приклад – Лістинг 14 і 15. (Лістинг 15 – канонічна форма лістингу 14.) Лістинг 15 не був виконаний в ручну – він був згенерований за допомогою розробки Canonical XML групи програмістів IBM alphaWorks; цей проект є частиною їх XML Security Suite (див. Ресурси). Однак, допитливий читач може отримати з лістингу 14 Лістинг 15, виконавши послідовно все викладених вище тринадцять пунктів.

Лістинг 14

<?xml version="1.0" encoding="UTF-8"?>
<saml:Assertion
    targetNamespace="urn:oasis:names:tc:SAML:1.0:assertion"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
    xmlns="http://www.w3.org/2001/XMLSchema"
    MajorVersion="1"
    MinorVersion="0"
    AssertionID="192.168.2.124.9756438564783"
    Issuer="CanonicalXMLTestExampleFictitiousService"
    IssueInstant="2002-09-01T18:18:38Z" >

    <saml:Conditions
        NotBefore='2002-09-02T12:00:00Z'
        NotOnOrAfter='2002-09-03T12:00:00Z'>
        <saml:Condition
            xsi:type="AudienceRestrictionConditionType"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <saml:Audience>CanonicalXMLPart1Sep2002ByBilalSiddiquiForXMLDotCom
            </saml:Audience>
        </saml:Condition>
        <saml:AuthenticationStatement
            AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
            AuthenticationInstant="2002-09-01T18:18:20Z">
            <Subject>
                <NameIdentifier>Bilal Siddiqui</NameIdentifier>
            </Subject>
            <saml:SubjectLocality DNSAddress="www.xml.com/authors/auth15"/>
            <saml:AuthorityBinding
                AuthorityKind="samlp:AttributeQuery"
                Location ="http://MyFictitiousSAMLAuthority.com"
                Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding">
            </saml:AuthorityBinding>
        </saml:AuthenticationStatement>
    </saml:Conditions>
</saml:Assertion>

Лістинг 15

<saml:Assertion xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="192.168.2.124.9756438564783" 
IssueInstant="2002-09-01T18:18:38Z" Issuer="CanonicalXMLTestExampleFictitiousService" 
MajorVersion="1" MinorVersion="0" targetNamespace="urn:oasis:names:tc:SAML:1.0:assertion">

    <saml:Conditions NotBefore="2002-09-02T12:00:00Z" NotOnOrAfter="2002-09-03T12:00:00Z">
        <saml:Condition xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AudienceRestrictionConditionType">
            <saml:Audience>CanonicalXMLPart1Sep2002ByBilalSiddiquiForXMLDotCom
            </saml:Audience>
        </saml:Condition>
        <saml:AuthenticationStatement AuthenticationInstant="2002-09-01T18:18:20Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
            <Subject>
                <NameIdentifier>Bilal Siddiqui</NameIdentifier>
            </Subject>
            <saml:SubjectLocality DNSAddress="www.xml.com/authors/auth15"></saml:SubjectLocality>
            <saml:AuthorityBinding AuthorityKind="samlp:AttributeQuery" Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="http://MyFictitiousSAMLAuthority.com">
            </saml:AuthorityBinding>
        </saml:AuthenticationStatement>
    </saml:Conditions>
</saml:Assertion>

Зверніть увагу, що в Лістингу 14 немає декларації DOCTYPE. Отже, в даному випадку деякі кроки, як, наприклад, заміна посилань на розділ і додавання атрибутів за умовчанням, необов’язкові.

Висновок

У другій статті цього циклу ми продовжимо вивчення цієї концепції і розглянемо деякі її більш складні аспекти, як обробка частин XML-документів, секції CDATA, коментарі та директиви. Ми також обговоримо деякі каверзні ситуації, коли процес канонізації робить XML-документи марними з точки зору їх передбачуваної функції.

Ресурси

  • Офіційна специфікація Canonical XML доступна на сайті консорціуму W3C.
  • Скачайте і спробуйте IBM XML Security Suite.
  • У цій статті згадувалося про XML, Просторах імен (Namespaces) and Схема (Schema). Більш детальна інформація – на офіційному сайті W3C.
  • Офіційна специфікація Електронної XML-підпису (XML Digital Signatures).
  • Цикл статей, Присвячених питанням криптографії, в яких розглянуті ключі, електронні підписи, довідники повідомлень та інші найважливіші аспекти безпеки в Інтернеті.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*