Oracle COREid Federation

Jadwiga Gnybek

Bliżej, szybciej, krócej – to przymiotniki najczęściej używane do scharakteryzowania oczekiwań klientów w stosunku do systemów informatycznych. Systemy te już nie tylko muszą realizować swoje podstawowe funkcjonalności, ale muszą również utrzymywać łączność – zarówno pomiędzy systemami informatycznymi wspierającymi biznes, jak i pomiędzy ludźmi ten biznes realizującymi.

 

Wszystko to sprawia, że oprogramowanie służące do integracji systemów i autoryzacji dostępu cieszy się coraz większym zainteresowaniem. Konieczność coraz szybszego, a więc bardziej „bezpośredniego” kontaktu z partnerami, dostawcami czy klientami globalnych organizacji sprawia, że produkty takie jak Oracle COREid Federation stają się kluczowym elementem infrastruktury informatycznej. Produkty budujące tak zwane federacje tożsamości najszybciej znalazły zastosowanie w firmach bezwzględnie wymagających bezpiecznej wymiany informacji, czyli w telekomunikacji i bankowości.

W czasach gdy nie istnieją bariery technologiczne dla budowy rozległych sieci korporacyjnych realizujących swoje procesy biznesowe za pośrednictwem sieci globalnych, jedynym hamulcem bezpośredniego łączenia systemów informatycznych różnych podmiotów gospodarczych są względy bezpieczeństwa. Stąd zarządzanie tożsamością i dostępem wydaje się być tą dziedziną informatyki, która wkracza w swój „złoty wiek”. Federacje tożsamości oznaczają dziś bowiem dostęp do baz danych, zasobów katalogowych, aplikacji biznesowych.

Na czym polega idea federacji tożsamości?

Oprogramowanie budujące federacje tożsamości dostarcza infrastrukturę umożliwiającą wymianę danych o tożsamości i uprawnieniach użytkowników systemów informatycznych skupionych w różnych domenach sieci. A wszystko po to, aby użytkownik w globalnej sieci logował się tylko raz.

W najprostszym scenariuszu federacji mamy dwóch partnerów biznesowych, którzy chcą połączyć swoje systemy informatyczne tak, aby użytkownik mógł korzystać z zasobów obu firm bez konieczności wielokrotnego logowania. Dostęp do aplikacji obu firm użytkownicy uzyskują poprzez zalogowanie do portalu, który z jednej strony umożliwia im zarządzanie własnym kontem dostępu, z drugiej zaś udostępnia aplikacje, raporty i zasoby sieciowe do których zostali uprawnieni. A wszystko to bez konieczności przeprowadzania synchronizacji danych pomiędzy bazami użytkowników obu firm. To właśnie zalety federacyjnego zarządzania tożsamością.

Przyznajmy, że od frontu wygląda to nieźle. Zajrzyjmy zatem „od podwórza”. Jak łatwo zgadnąć, najważniejszym elementem tego systemu jest sposób wymiany informacji o użytkownikach pomiędzy udostępnianymi przez federację systemami. Wymiana ta realizowana jest w oparciu o kilka funkcjonujących na rynku standardów – takich, jak Liberty, SAML czy WS-Federation. Przyjrzyjmy się bliżej rozwiązaniu opartemu na standardzie SAML.

W omawianym tu rozwiązaniu zaimplementowane zostały trzy profile SAML: Browser/POST, Browser/Artifact (profil referencji) i profil współużytkowania atrybutów X.509. Przyjrzyjmy się im pokrótce.

Profil SAML Browser/Artifact polega na przekazywaniu asercji SSO SAML z serwisu źródłowego do docelowego poprzez referencję. Przekazana referencja jest następnie odczytywana poprzez osobny, bezpieczny kanał komunikacji (np. SSL), po czym wskazana przez nią asercja jest pobierana z serwisu źródłowego. W praktyce wygląda to następująco: użytkownik loguje się do COREid Federation; po pomyślnym uwierzytelnieniu jest generowany plik cookie przeznaczony do jednokrotnego logowania; plik ten jest zapisywany w przeglądarce internetowej użytkownika. W następnym kroku użytkownik zgłasza żądanie dostępu do zasobu w domenie docelowej; usługa przekazująca serwisu źródłowego inicjuje procedurę jednokrotnego logowania, która generuje referencję zawierającą identyfikator serwisu źródłowego i adres samej asercji. W tym momencie przeglądarka użytkownika wraz z referencją zapisaną w łańcuchu zapytania adresu URL jest przekierowywana do usługi odbierającej serwisu docelowego. Usługa ta pobiera potrzebne informacje, w tym referencję, identyfikator źródła i adres asercji, po czym dodatkowym, bezpiecznym kanałem komunikacji wysyła do serwisu źródłowego żądanie przesłania pełnej asercji. Usługa odpowiedzi serwisu źródłowego przetwarza żądanie i odsyła odpowiednią asercję do serwisu docelowego. Dalej asercja jest przetwarzana przez usługę odbierającą serwisu docelowego, która odwzorowuje ją na lokalne konto użytkownika. Na koniec, gdy wszystkie niezbędne informacje o użytkowniku są już znane, serwis docelowy może podjąć ostateczną decyzję odnośnie udostępnienia lub odmówienia użytkownikowi dostępu do żądanego zasobu. Nie jest to może procedura krótka, ale nie zapominajmy o pryncypiach. Wygodnie i łatwo ma być „od frontu”! „Od podwórza” ma być bezpiecznie!

Profil SAML Browser/POST polega na bezpośrednim przekazywaniu asercji SAML SSO serwisowi docelowemu. Nie jest w tym przypadku wymagany osobny kanał komunikacji. Prześledźmy scenariusz obiegu informacji przy zastosowaniu tego profilu. Na dobry początek użytkownik loguje się do COREid Federation. Po pomyślnym uwierzytelnieniu, w przeglądarce użytkownika zapisywany jest niezbędny dla sesji jednokrotnego logowania plik cookie. Teraz gdy użytkownik otwiera skrót zasobu w serwisie docelowym, usługa przekazująca serwisu źródłowego generuje dla tego użytkownika asercję, której treść jest tworzona na podstawie atrybutów pobieranych z katalogu użytkowników (na przykład katalogu LDAP). Teraz serwis źródłowy buduje odpowiedź zawierającą asercję i adres serwisu docelowego jako zmienne ukryte, po czym cała odpowiedź jest podpisywana cyfrowo. Przeglądarka internetowa użytkownika wysyła gotowy formularz metodą POST do usługi odbierającej serwisu docelowego, gdzie odpowiedź jest deszyfrowana i sprawdzana pod kątem zgodności treści asercji z asercją pierwotnie wygenerowaną przez źródło. Jeśli weryfikacja asercji przebiegnie pomyślnie, asercja odwzorowywana jest na konto użytkownika w domenie docelowej. W tym momencie użytkownik może już zostać zalogowany i otrzymuje plik cookie dla jednokrotnego logowania. W tym momencie serwis docelowy jest już w stanie jednoznacznie ustalić, czy użytkownik jest uprawniony do korzystania z żądanego zasobu.

Profil SAML współużytkowania atrybutów X.509 dla odmiany umożliwia rozproszoną autoryzację wykorzystującą uwierzytelnianie certyfikatami X.509. Użytkownik uwierzytelnia się w serwisie docelowym jako klient SSL, przedstawiając swój certyfikat X.509 na etapie negocjacji połączenia SSL. Po pomyślnym uwierzytelnieniu, serwis docelowy przesyła zarządzającemu tożsamością serwisowi źródłowemu danego użytkownika zgodne z SAML żądanie przesłania atrybutów niezbędnych do przeprowadzenia autoryzacji. Przekładając to na konkretne zadania, scenariusz komunikacji wygląda tu następująco. W chwili gdy użytkownik próbuje otworzyć w przeglądarce internetowej znajdujący się w serwisie docelowym zasób chroniony, serwis ten żąda podania danych uwierzytelniających, które użytkownik przedstawia w postaci certyfikatu X.509v3. Uwierzytelnianie odbywa się z wykorzystaniem technik uwierzytelniania klienta SSL. Jeśli uwierzytelnienie przebiegnie pomyślnie, serwis docelowy wysyła do serwisu źródłowego podpisaną asercję w celu uzyskania niezbędnych atrybutów. Adres serwisu źródłowego, do którego kierowana jest asercja, ustalany jest na podstawie nazwy wyróżniającej (Distinguished Name) pobranej z certyfikatu użytkownika. Następnie serwis źródłowy odbiera asercję, sprawdza poprawność serwisu docelowego i odsyła podpisaną odpowiedź zawierającą żądane atrybuty użytkownika. Na podstawie uzyskanych w ten sposób informacji serwis docelowy może podjąć decyzję o udostępnieniu lub odmówieniu użytkownikowi dostępu do żądanego zasobu. Uff…

Mechanizmy SMART

SAML nie jest jedynym standardem wykorzystywanym przez Oracle COREid Federation. Produkt ten oferuje również inne mechanizmy umożliwiające stworzenie wielodomenowego rozwiązania do jednokrotnego logowania. Jednym z nich jest SmartMarks, który wspiera uwierzytelnianie użytkowników starających się o dostęp do zasobów bez ważnego pliku sesji cookie. W takim przypadku, mechanizm SmartMarks przekieruje użytkownika do właściwej domeny w celu uwierzytelnienia. W przypadku użytkowników korzystających z serwisu docelowego lokalnie, ten sam mechanizm może przekierować użytkownika do ekranu logowania. Użytkownicy niezalogowani w swojej domenie źródłowej zostaną skierowani do serwisu źródłowego w celu uwierzytelnienia.

Kolejnym mechanizmem z serii SMART jest SmartWalls. Pozwala on domenom docelowym sprawdzać, czy autor i podmiot asercji pochodzą z tej samej domeny. Jeśli domeny te są różne, asercja jest odrzucana. Z chronionych zasobów mogą więc korzystać wyłącznie użytkownicy zalogowani do prawidłowej domeny źródłowej, a asercja dla danego użytkownika może być wysyłana tylko z jednej, odpowiedniej dla tego użytkownika domeny.

I na koniec SmartMaps – mechanizm pozwalający uwierzytelniać użytkowników, którzy jeszcze nie mają konta w serwisie docelowym. Uwierzytelnienie nowego użytkownika może być dokonane w dwojaki sposób: może on zostać automatycznie odwzorowany na istniejącą tożsamość lokalną, albo zostanie dla niego stworzona nowa tożsamość. W przypadku współpracy z systemem Oracle COREid Access and Identity, może też zostać uruchomiony ciąg zadań tworzący nowego użytkownika Oracle COREid.

A po co to wszystko?

Oczywiście, aby ułatwić partnerom w biznesie współdzielenie informacji dotyczących tożsamości użytkowników i bezpieczeństwa, bez konieczności utrzymywania przez każdą z organizacji osobnej kopii wszystkich profilów tożsamości. Dzięki temu nowoczesne przedsiębiorstwa mogą z jednej strony zacieśniać integrację z klientami i partnerami biznesowymi, z drugiej zaś zwiększać zgodność użytkowanych systemów z obowiązującymi przepisami dotyczącymi poufności i bezpieczeństwa informacji.

Słownik pojęć przydatnych

Asercja – według specyfikacji SAML, stwierdzenia dotyczące uwierzytelniania, atrybutów i autoryzacji.

Źródło, czyli dostawca tożsamości (IdP) – serwis uwierzytelniający użytkownika, a następnie przesyłający asercję do serwisu docelowego.

Cel, czyli dostawca usługi (SP) – serwis wykorzystujący dane przekazane w asercji do ustalenia zakresu uprawnień użytkownika i na tej podstawie udzielający lub odmawiający dostępu do żądanego zasobu.

Profil Browser/Artifact (profil referencji) – zdefiniowany w SAML profil jednokrotnego logowania internetowego (Web Single Sign On – Web SSO) wykorzystujący przekierowania HTTP i protokół SOAP do przekazania asercji z serwisu źródłowego do serwisu docelowego.

Profil Browser/POST – zdefiniowany w SAML profil Web SSO wykorzystujący formularz HTML wysłany metodą POST, do przekazania asercji z serwisu źródłowego do serwisu docelowego.