SOAP API - WS-Security

Co je WS-Security

WS-Security je standard (specifikace od OASIS) pro zabezpečení SOAP zpráv na úrovni zpráv. To znamená, že nezabezpečuje jenom přenos (jako HTTPS/TLS), ale přímo jednotlivé SOAP zprávy – a to tak, že bezpečnostní informace jsou součástí XML hlaviček. I kdyby zpráva putovala přes více systémů, stále zůstane podepsaná/zašifrovaná, protože bezpečnost je „zabudovaná“ přímo v XML.

Jak WS-Security funguje?

Každá SOAP zpráva má hlavičku <soap:Header>, kam WS-Security přidá bezpečnostní elementy (<wsse:Security>), např.:

<soap:Header>
  <wsse:Security>
    <wsse:UsernameToken>
      <wsse:Username>pavel</wsse:Username>
      <wsse:Password Type="...#PasswordDigest">abc123</wsse:Password>
    </wsse:UsernameToken>
    <ds:Signature>...</ds:Signature>
    <xenc:EncryptedData>...</xenc:EncryptedData>
  </wsse:Security>
</soap:Header>

Možnosti zabezpečení

WS-Security kombinuje několik mechanismů:

1. Autentizace

   • UsernameToken – jednoduché jméno/heslo v hlavičce (Plaintext nebo Digest).
   • X.509 certifikát – autentizace pomocí veřejného/privátního klíče.
   • Kerberos – integrovaná autentizace, méně používaný.

2. Integrita zprávy

   • Digitální podpis (Signature)
     • Pomocí XML Signature (ds:Signature) se ověří, že zpráva nebyla změněna.
     • Podepisuje se typicky tělo zprávy (SOAP Body) a případně časová značka.

3. Důvěrnost

   • Šifrování (Encryption)
     • Pomocí XML Encryption (xenc:EncryptedData) lze zašifrovat část nebo celé SOAP Body.
     • Používá se kombinace asymetrického a symetrického šifrování (RSA + AES).

4. Ochrana proti replay útokům

   • Timestamp – obsahuje <Created> a <Expires> hodnoty, aby zpráva byla platná jen krátkou dobu.

Typy WS-Security

V praxi "typy" WS-Security neznamenají úplně jiné protokoly, ale různé mechanismy, které standard WS-Security umožňuje použít — a které se mohou kombinovat.

UsernameToken (uživatelské jméno + heslo)

Jednoduché ověření identity uživatele, vhodné pro služby bez potřeby podepisování/šifrování zpráv.

Použití

Do hlavičky SOAP zprávy vloží element <wsse:UsernameToken>, kde je uživatelské jméno a heslo.

Varianty hesla:

• PasswordText – heslo je v otevřeném tvaru (méně bezpečné, používá se jen přes TLS).
• PasswordDigest – heslo je hashované (Base64(SHA1(nonce + created + password))), takže se neodesílá v čitelné podobě.

Často doplněno: Nonce (náhodný řetězec) a Created (časová značka) pro ochranu proti replay útokům.

Timestamp

Mechanismus proti replay útokům. Doplňuje ostatní metody (UsernameToken, Signature).

Použití

Do SOAP hlavičky vloží element <wsu:Timestamp> s <Created> a <Expires>.

Server pak odmítne zprávu, pokud je příliš stará nebo znovu přijatá.

Obvykle se spolu s daty podepisuje, aby útočník nemohl timestamp upravit.

XML Signature (digitální podpis)

Zajišťuje integritu a ověření původu zprávy. Používá se, když je potřeba zajistit, že zpráva nebyla cestou změněna a že pochází od konkrétního subjektu.

Použití

Pomocí privátního klíče podepíše vybrané části zprávy (nejčastěji SOAP Body + Timestamp).

• Odesílatel vytvoří hash obsahu (SHA-256, SHA-1, …).
• Hash zašifruje svým privátním klíčem (RSA).
• Výsledek vloží do <ds:Signature> elementu.
• Příjemce ověří podpis pomocí veřejného klíče (z certifikátu).

Podepsat lze celé tělo zprávy případně jen určité elementy (např. část <soap:Body>).

XML Encryption (šifrování)

Zajišťuje důvěrnost dat v SOAP zprávě. Používá se, když je nutné, aby obsah zprávy viděl jen oprávněný příjemce. Umožňuje selektivně skrýt jen určité citlivé části zprávy.

Použití

Zašifruje celé SOAP Body nebo jen jeho část.

• Generuje se náhodný symetrický klíč (např. AES-256).
• Symetrickým klíčem se zašifruje obsah.
• Symetrický klíč se zašifruje veřejným klíčem příjemce (RSA).
• Vše se vloží do <xenc:EncryptedData> a <xenc:EncryptedKey>.

Kombinace metod

V praxi se WS-Security často kombinuje:

UsernameToken + Timestamp – lehká autentizace. Signature + Timestamp – integrita + ochrana proti replay. Sign-then-Encrypt – vysoká úroveň bezpečnosti (podpis zůstane chráněný šifrováním). Encrypt-then-Sign – příjemce vidí, že šifrovaná data jsou od důvěryhodného odesílatele, ale podpis je pak veřejně viditelný.

Méně používané typy

• SAML Token – přenos identity uživatele pomocí SAML assertion.
• BinarySecurityToken – přímé vložení certifikátu do hlavičky zprávy.
• Kerberos Token – autentizace přes Kerberos.
• Custom Token – vlastní formát tokenu definovaný organizací.

SAML Token

• XML struktura podle standardu SAML (Security Assertion Markup Language), která obsahuje informace o identitě uživatele a případně o jeho oprávněních.

Použití: Často pro Single Sign-On (SSO) v enterprise prostředí. Server ověří SAML assertion a ví, kdo uživatel je.

Výhoda: Přenáší nejen jméno, ale i role, skupiny a další atributy.

BinarySecurityToken

• Element <wsse:BinarySecurityToken> obsahující binární data (většinou Base64), typicky X.509 certifikát nebo jiný binární klíč.

Použití: Klient přiloží certifikát přímo do SOAP hlavičky, aby server měl veřejný klíč pro ověření podpisu nebo šifrování.

Výhoda: Jednoduchý způsob, jak „předat“ klíč přímo ve zprávě.

Kerberos Token

• Token vytvořený Kerberos protokolem (tzv. Kerberos AP-REQ), vložený do SOAP hlavičky.

Použití: Autentizace v prostředí, kde běží Kerberos (Windows doména, Active Directory).

Výhoda: Silná, vzájemná autentizace, bez posílání hesel.

Custom Token

• Jakýkoli token definovaný organizací mimo standardy WS-Security (např. interní XML formát nebo proprietární ID).

Použití: Když standardní typy nevyhovují, ale potřebuješ přenést vlastní bezpečnostní informace.

Výhoda: Flexibilita, ale nutnost vlastní implementace klienta i serveru.

Různé scénáře použití

Username + PasswordDigest

• Jednoduchá autentizace, heslo se posílá v zahashované podobě.
• Vhodné pro služby, které nepotřebují vysokou úroveň šifrování.

SignOnly

• Zpráva se podepíše privátním klíčem odesílatele.
• Příjemce ověří podpis pomocí veřejného klíče.
• Chrání proti modifikaci zprávy.

EncryptOnly

• Zpráva (nebo její část) je zašifrovaná.
• Používá se, když je potřeba zachovat důvěrnost, ale neřeší se integrita.

Sign + Encrypt

• Zpráva se podepíše a poté zašifruje.
• Zajišťuje integritu i důvěrnost.

WS-Security vs HTTPS (TLS)

Často se používají oba přístupy zároveň – TLS pro transport-level, WS-Security pro message-level (TLS chrání přenos, WS-Security chrání samotné zprávy).