Hegemon informacyjnej dżungli

16 maja br. zakończono prace nad nieco szerszą niż UDDI wersją standardu do komunikacji biznesowej przy użyciu XML. Po 18 miesiącach działań organizacji OASIS został zdefiniowany ebXML. Przeznaczenie ebXML i UDDI jest niemal takie samo. Architektura ebXML pozwala: definiować komunikat (pakiet) przesyłany do usługi, ogłaszać swoje usługi (wraz z profilem firmy) w specjalnym repozytorium, a także zapewnia ujednolicony protokół transmisji. Repozytorium ebXML i UDDI może być ujednolicone - w standardzie ebXML zdefiniowane są schematy odwołujące się do UDDI, tak by możliwe było jednoczesne przeszukiwanie dwóch odrębnych magazynów w poszukiwaniu interesującej usługi.

Specyfikacja ebXML, mimo że jest nowsza, nie określa sposobu ochrony informacji przechowywanych w repozytorium (odpowiedni dokument ma status propozycji dla komitetu OASIS). Mało prawdopodobne jest więc, by w najbliższym czasie powstało nietestowe repozytorium ebXML. W ebXML jest także zdefiniowany protokół, który pozwala definiować kanał komunikacyjny między dwoma stronami transakcji. W UDDI z repozytorium były odczytywane parametry usługi Web i sposób jej wywołania. ebXML pozwala wymienić znacznie więcej szczegółów technicznych. UDDI zakładało, że obie strony posługują się protokołem SOAP, ebXML definiuje własną warstwę transportową (format komunikatów), ale pozwala, by strony transakcji uzgodniły, że będą wywoływane przy użyciu innych protokołów.

Bezpieczeństwo nadal kuleje

Warto podkreślić kwestię związaną z bezpieczeństwem rozwiązań opartych na XML. Pliki XML są plikami tekstowymi i mogą być przesyłane tak jak pliki HTML - za pomocą protokołów HTTP i HTTPS. To ich ogromna zaleta. W przypadku protokołu SOAP skutkiem przesłania pliku XML jest np. zdalne wywołanie pewnej metody, czyli uruchomienie procesu na serwerze. Konieczna jest więc autoryzacja przesyłanych komunikatów. Docelowo będą musiały powstać firewalle kolejnej generacji, które ochronią korporacje przed atakiem wykorzystującym usługi Web.

Rozwiązaniem dobrze współpracującym z SOAP jest AuthXML. To specyfikacja, która pozwala zaszyć w komunikacie SOAP informacje jednoznacznie identyfikujące nadawcę i pozwalające związać przychodzący komunikat z jego profilem czy sesją danych. AuthXML jest oparty na innym standardzie - XML Signature - który pozwala podpisywać dokumenty XML kluczem elektronicznym. Informacje służące do autoryzacji mogą być wysyłane na żądanie drugiej strony w dowolnym momencie komunikacji albo na początku komunikacji - wraz z pierwszym komunikatem SOAP.

Pełną gamę rozwiązań związanych z bezpieczeństwem zaproponowała firma VeriSign. Podstawowym rozwiązaniem jest S2ML (Security Services Markup Language), pełniące analogiczną rolę do AuthXML. Ten protokół jest przeznaczony zarówno do autoryzacji, jak i identyfikacji. S2ML może wykorzystywać wiele różnych schematów autoryzacji, począwszy od najprostszego, nazwy użytkownika i hasła, przez SSL, podpisy cyfrowe, Kerberos czy karty chipowe. Może także współpracować z AC czy Java Authorization Model. Podstawowym celem w projektowaniu S2ML jest dostarczenie wspólnego schematu opisującego wiele technik autoryzacyjnych. S2ML pozwala, by informacje autoryzacyjne były przekazywane między wieloma usługami Web (AuthXML był związany z konkretnym ciągiem komunikatów SOAP).

XMLPay to standard pozwalający określić sposób płacenia (wykonywania transakcji) przy użyciu XML. Uwzględnia kilka stron transakcji: płatnika, odbiorcę oraz centrum autoryzacyjne. Może także współpracować np. z usługami Web, zapewniającymi autoryzację transakcji dokonywanych kartą kredytową.

Powstał także standard XKMS (XML Key Management Specification), który integruje mechanizmy autoryzacyjne z podpisem cyfrowym. Jest to również specyfikacja API, pozwalająca szyfrować komunikację przy użyciu mechanizmów PKI. Wszystkie niezbędne elementy są przekazywane przy użyciu XML.


TOP 200