Dzisiaj, większość połączeń Web services, nawet tych przechodzących przez zaporę ogniową, jest odzwierciedleniem Weba: klient i serwer współdziałają - mniej lub bardziej – w czasie rzeczywistym, z ochroną kontrolowaną przez serwer.

Takie proste interakcje zazwyczaj zdają się na uwierzytelnianie typu „identyfikator – hasło” oraz szyfrowanie wiadomości zapewniające również jej integralność (SSL). Bardziej złożone wymagania, takie jak autoryzacja i niezaprzeczalność, mogą być kodowane w aplikacjach usługowych.

Zobacz również:

• Czy Elon Musk reaktywuje usługę Vine?

Rzecz się komplikuje, jeżeli są spełnione co najmniej trzy warunki:

- architektura zawiera elementy pośredniczące (tzn. wiadomości musi być przesyłana przez szereg punktów pośrednich);

- wiadomości są przechowywane i muszą być zabezpieczone również w czasie, kiedy nie są transmitowane;

- więcej niż jedna strona chce kontrolować pewne aspekty bezpieczeństwa (np. identyfikator i hasło używane po stronie klienta przy dostępie do serwera, który ma niezależna koncepcję uwierzytelniania).

Są to elementy wymagające wprowadzenia nowych standardów i protokołów.

WS-Security jest głównym standardem Web services, obsługującym bardziej złożone uwierzytelnianie, poufność i integralność wiadomości SOAP. Przewiduje hasła, Kerberos, certyfikaty X.509 i inne schematy uwierzytelniania. Specyfikacja Komitetu Technicznego OASIS w praktyce nie ma konkurencji i została już zaimplementowana przez BEA Systems, Microsoft, IBM i inne firmy.

Jednak WS-Security jest tylko strukturą, w ramach której ma miejsce uwierzytelnianie i autoryzacja, bardzo często poprzez asercję bezpieczeństwa. Asercja bezpieczeństwa jest formalną deklaracją uwierzytelnienia użytkownika lub grupy, do której należy – działa jako pewnego rodzaju proxy. Zamiast transmitować obowiązujące identyfikator i hasło czy certyfikat cyfrowy, asercja może być poświadczeniem, że klient jest autoryzowany do używania Web services. Jedną z propozycji standardu asercji komunikacyjnych jest WS-Trust. Inną, szeroko używany SAML (Security Assertion Markup Language), który pokrywa się z WS-Trust.

SAML można rozpatrywać w dwóch częściach: reprezentacja samych asercji i protokół, którym są one transmitowane. Jeżeli się je rozłączy, to ta pierwsza może być używana w ten sam sposób, jak każdy inny token bezpieczeństwa (certyfikat cyfrowy itp.) WS-Trust. Połączenie WS-Trust i SAML jest tak naturalne, że prawdopodobnie stanie przedmiotem standaryzacji w przyszłym roku.

Używając tych protokołów strony mogą negocjować schemat bezpieczeństwa dla komunikacji Web services, ale celem ostatecznym jest określenie takiego schematu dla samych uczestników. Do tego potrzebny jest sposób komunikowania polityki bezpieczeństwa z jednego punktu SOA do innego – czyli wyrażenie wymagań bezpieczeństwa i negocjowanie opcji pomiędzy uczestnikami bez interwencji człowieka. Jest to dziedzina, którą zajmuje się WS-SecurityPolicy - załącznik do bardziej ogólnej specyfikacji WS-Policy. (WS-SecurityPolicy jest implementowana w zestawie narzędzi Microsoftu - Web Services Enhacement).

WS-SecurityPolicy pokrywa się częściowo z inną specyfikacji OASIS -XACML (Extensible Access Control Markup Language). Jest ona trochę bardziej dojrzała, ale mniej znana. WS-SecurityPolicy może więc wchłonąć XACML jako jeden ze schematów polityki sterowania dostępem.