Tożsamość i standardy

Niezwykle ważna jest wiedza o tym, kto używa usługi SOA i wykorzystanie jej do kontrolowania dostępu oraz na potrzeby audytu. Zadanie kontrolowania dostępu do usługi wymaga zastosowania różnych standardów - uznanych, takich jak certyfikaty X.509, i niektórych nowych, takich jak SAML i WS-Security. Ważne, aby nie polegać tylko na standardach, zwłaszcza kiedy są łączone w skomplikowany sposób.

Hasła, certyfikaty X.509 i WS-Security Passwords funkcjonują od dawna. Są szeroko stosowane w ramach SOA Security. W wielu przypadkach jest to po prostu HTTP Authentication, wysyłane przez połączenia SSL tak, aby hasło nie było przesyłane w postaci jawnej. Jest to istotne nawet wtedy, gdy stosowane jest Digest Authentication, gdzie hasło nie jest przesyłane w postaci jawnej - używanie SSL pozwala w tym przypadku na zablokowanie niektórych ataków "przechwyć i odtwórz". Chociaż HTTP Authentication over SSL jest technologią nie nową już, to jednak szeroko stosowaną przy uwierzytelnianiu typu punkt-punkt w ramach SOA.

Certyfikaty X.509 są wykorzystywane w kontekście uwierzytelniania SSL, gdzie Web services mogą udowadniać swoją tożsamość względem strony klienckiej lub, w przypadku dwukierunkowego SSL, klient udowadnia swoją tożsamość względem usługi. Wówczas tożsamość jest pojęciem amorficznym, ponieważ interakcje Web services często obejmują kontakty aplikacja-aplikacja, bez włączania czynnika ludzkiego. Tak więc, tożsamość to również pojęcie odnoszące się do aplikacji. Ponadto, tak jak w przypadku jakiegokolwiek użycia certyfikatów X.509, zaufanie opiera się na wydawcy certyfikatów X.509 (Certificate Authority - CA).

Podobnie jak SSL, certyfikaty X.509 są często stosowane w kontekście podpisów cyfrowych. XML Signature to standard definiujący jak dane XML mogą być podpisywane z użyciem kluczy prywatnych, które są zgodne z certyfikatem X.509, tak aby każdy, kto otrzyma podpis zgodny z X.509 Certificate mógł ten podpis sprawdzić.

XML Encryption jest standardem, który definiuje sposób szyfrowania danych XML. Różnica między szyfrowaniem danych XML a danych innego rodzaju polega na tym, że te pierwsze mogą być szyfrowane selektywnie. Ponieważ komunikaty SOA są głównie komunikatami XML (z wyjątkiem REST i JSON dla usług Web 2.0), XML Encryption jest bardzo użyteczne w stosowaniu zasad prywatności.

Dojrzałą technologią jest również Kerberos, która nadal jest używana w ramach SOA Security. Ponadto jest ona często stosowana w szczególności w środowiskach sieciowych Windows.

Wszystkie te funkcjonujące już od dłuższego czasu technologie są wciąż używane w zabezpieczaniu SOA.

WS-Security

Standardy takie jak WS-Security dopuszczają stosowanie polityki bezpieczeństwa w odniesieniu do SOA, pozwalając tym samym na kontrolowane jej używanie i monitorowanie. WS-Security jest technologią nowszą, która stała się standardem w roku 2004. Zbudowano ją z elementów wcześniej już istniejących. Definiuje ona, w jaki sposób XML Encryption i XML Signature stosują się do SOAP, w celu szyfrowania i/lub podpisywania wiadomości SOAP. Dodatkowo określa, gdzie umieszczane są hasła i certyfikaty X.509 w wiadomościach SOAP oraz jak SOAP może współdziałać z Kerberos. Umożliwia to współpracę między różnymi aplikacjami używającymi WS-Security.

Technologie WS-Security są zawarte m.in. w platformach Microsoft .Net i Sun Glassfish. Umożliwiają przetwarzanie podpisanych danych XML (wykorzystując XML Signature z WS-Security), uwierzytelnianie (z zastosowaniem haseł, Kerberos lub certyfikatów) i szyfrowanie (XML Encryption z WS-Security).

Bramy XML

Bramy XML zapewniają bezpieczeństwo SOA, udostępniając bezpieczne przetwarzanie w sieci z wykorzystaniem akceleratorów sprzętowych. Stosują reguły polityki bezpieczeństwa do usług w ramach chronionego środowiska SOA. Prezentują też usługi wirtualne, które funkcjonują na styku z rzeczywistymi Web services. Takie wirtualne usługi są przyspieszane sprzętowo i mogą zapewniać przekształcenia, które są niezbędne zanim wywołana zostanie rzeczywista Web service. Brama XML może np. zapewniać interfejs REST na wejściu do rzeczywistej SOAP Web service.

W ten sposób brama często zapewnia pośrednictwo między protokołami, transformacje i przyspieszenie oraz zabezpieczenie.