Nowa specyfikacja dla tożsamości sfederowanej

W środowiskach dynamicznego e-biznesu niezbędna jest szybka i efektywna reakcja na zdarzenia. Firmy spoglądające w przyszłość projektują swoje rozproszone usługi w oparciu o zasadę sterowania przez zdarzenia. Strategia taka zapewnia, że istotne zdarzenia – w systemach aplikacyjnych i komponentach – są komunikowane w czasie rzeczywistym odpowiednim stronom.

Usługi powiadamiania o zdarzeniach pozwalają aplikacjom określać typ publikowanego lub subskrybowanego zdarzenia, format w jakim powiadamianie ma być transmitowane i częstotliwość, z jaką powinny być wysyłane.

Do niedawna przemysł Web services nie dysponował standardem powiadamiania o zdarzeniach. Pod koniec ubiegłego roku dwie grupy przemysłowe udostępniły konkurencyjne specyfikacje standaryzujące ten problem. Grupa pierwsza – BEA Systems, Microsoft i Tibco Software – opublikowała specyfikację o nazwie Web Services Eventing (WS-Eventing), druga – w której wiodąca role odgrywa IBM – specyfikację Web Services Notification (WS-Notification).

Zobacz również:

Jednym z ważnych mechanizmów WS-Evening i WS-Notification jest to, że nie ograniczają one typów czy zawartości wiadomości, które mogą być powiadomieniem o zdarzeniu. Nie ograniczają też, które jednostki mogą publikować i subskrybować te wiadomości. Takie podejście daje projektantom możliwość zaprojektowania ogólnej infrastruktury zdarzeń i udostępnienia jej dla wszystkich aplikacji i usług, kiedy tylko Web services oparte na SOAP staną się powszechne.

Powiadamianie o zdarzeniach generowanych przez użytkownika powinno być dystrybuowane w ramach tej samej infrastruktury ogólnego użytku, która obsługuje powiadomienia poziomu systemowego. WS-Eventing lub WS-Notification (lub jakaś podobna specyfikacja, która zastąpi obie) powinny być implementowane w systemach zarządzania tożsamością, zapewniając powiadamianie aplikacji o istotnych zdarzeniach dotyczących poszczególnych użytkowników. Środowisko zarządzania tożsamością może np. powiadamiać autoryzowaną aplikację o tym, że użytkownik podłączył się do sieci, zalogował się do szczególnej domeny, przemieścił się do określonej szerokości geograficznej i ma zagwarantowane szczególne role, pozwolenia i ustawienia personalne.

Przepływ informacji związanej z tożsamością w różnym stopniu jest określany przez profile implementacyjne protokołów zarządzania tożsamością, takie jak: SAML 1.1 (Security Assertion Markup Language); Libery Alliance ID-FF 1.2 (Identity Federation Framework) i ID-WSF 1.0 (Identity Web Services Framework); WS-Federation 1.0 (Web services Federation Language).

Zarówno Liberty ID-WSF 1.0 jak i WS-Federation definiują złożoną infrastrukturę pośredniczącą w przekazywaniu atrybutów tożsamości użytkownika pomiędzy domenami zarządzania sfederowaną tożsamością. Jednak obie specyfikacje nie spełniają wymagań w zakresie definiowania protokołów publikowania i subskrypcji, niezbędnych do obsługi wymiany informacji identyfikacyjnych pomiędzy infrastrukturami zarządzania sfederowaną tożsamością.

Jest to obszar, gdzie swoją niezbędność uzasadniają WS-Eventing i WS-Federation. Są one częścią szerszego zestawu specyfikacji WS-* projektowanych metodą wzajemnych powiązań i zanurzeń w ramach struktury Web services. Oznacza to że inne Web services nie muszą zagnieżdżać swojej własnej, specjalnej infrastruktury zdarzeń – wystarczy, że mają dostęp do uniwersalnej obsługi zdarzeń, która implementuje jedną z tych dwóch specyfikacji.

Liberty Alliance powinna uwzględnić obie lub jedną z tych specyfikacji w swoich protokołach zarządzania tożsamością, a projektanci WS-Federation powinni zrobić to samo w przyszłych rewizjach swojej specyfikacji. Także Komitet Techniczny Security Services OASIS powinien rozważyć potrzebę ogólnego środowiska dla sfederowanego zarządzania tożsamością w specyfikacji SAML. Lista mechanizmów SAML 2.0 została już w znacznej mierze sfinalizowana i nie ma na niej powiadomień o zdarzeniach. Zagadnienie to stanie się więc kandydatem do opracowania w SAML 3.0 – do tego czasu powinien pojawić się standard opracowany w oparciu o WS-Eventing i/lub WS-Notification.


TOP 200