Architektura Oracle Xellerate Identity Provisioning

Architektura Oracle Xellerate Identity Provisioning Dokument techniczny Oracle Grudzień 2005 ORACLE FUSION MIDDLEWARE

Architektura Oracle Xellerate Identity Provisioning Wstęp... 3 Architektura podstawowa... 3 Ogólna architektura n-warstwowych aplikacji J2EE...4 Podstawowe warstwy... 4 Warstwa prezentacji... 5 Warstwa prezentacji dynamicznej... 5 Warstwa logiki aplikacji...5 Warstwa dostępu do danych... 5 Warstwa integracji z systemami zaplecza... 6 N-warstwowa architektura aplikacji J2EE w Xellerate...6 Warstwa prezentacji... 6 Warstwa prezentacji dynamicznej... 7 Aplikacja internetowa Xellerate... 7 Konsola projektowa Xellerate... 9 Warstwa logiki aplikacji...9 Środowisko wykonawcze serwer aplikacji...9 Interfejsy klientów i implementacja logiki aplikacji... 11 Warstwa dostępu do danych... 12 Warstwa integracji z systemami zaplecza... 13 Baza danych...13 Komponent Remote Manager...16 Harmonogram zadań Xellerate...17 Model bezpieczeństwa platformy Xellerate... 18 Bezpieczne kanały komunikacji... 19 Bezpieczeństwo kluczy i certyfikatów... 19 Bezpieczeństwo komponentów Remote Manager...20 Uwierzytelnianie JAAS... 20 Konfiguracje wdrożenia... 20 Konfiguracja 1 wdrożenie proste...21 Konfiguracja 2 wdrożenie klastra...21 Konfiguracja 3 wdrożenie z serwerem proxy...22 Konfiguracja 4 wdrożenie partycjonowane...23 Konfiguracje wdrożenia komponentów Remote Manager...24 Podsumowanie...24 Architektura dostarczania tożsamości Oracle Xellerate Strona 2

Architektura Oracle Xellerate Identity Provisioning Oracle Xellerate Identity Provisioning to korporacyjne rozwiązanie Oracle do obsługi tożsamości. WSTĘP Oracle Xellerate Identity Provisioning to bezpieczne rozwiązanie korporacyjne do obsługi tożsamości o sprawdzonych możliwościach zarządzania tożsamością. Korporacyjna obsługa tożsamości obejmuje czynności administracyjne, procesy biznesowe i technologie związane z tworzeniem, modyfikacją i usuwaniem praw dostępu użytkowników do systemów informatycznych, aplikacji i zasobów fizycznych organizacji. Dążąc do uzyskania większej kontroli nad prawami dostępu użytkowników, przedsiębiorstwa coraz częściej wybierają zautomatyzowane systemy obsługi tożsamości, pozwalające działać zgodnie ze strategią bezpieczeństwa firmy i obowiązującymi przepisami. Niniejszy artykuł opisuje architekturę platformy Xellerate niezawodnej technologii leżącej u podstaw mechanizmu Oracle Xellerate Identity Provisioning. Przedstawiony zostanie przegląd technologii, na których opiera się ta architektura, a następnie opis ich wykorzystania do stworzenia skalowalnego, wysoce dostępnego rozwiązania do obsługi tożsamości, pozwalającego zarządzać danymi o tożsamości w środowiskach heterogenicznych. ARCHITEKTURA PODSTAWOWA Podstawę Oracle Xellerate Identity Provisioning stanowi nowoczesna, n-warstwowa architektura wdrożeniowa w technologii J2EE, zapewniająca rozdzielenie warstw prezentacji, logiki aplikacji i danych. Ścisła separacja warstw pozwala szybko skalować Xellerate stosownie do potrzeb klienta. Architektura ta daje możliwość wykorzystania najbardziej elastycznych i najszerzej obsługiwanych wieloplatformowych usług J2EE, wykorzystujących języki Java i XML oraz techniki obiektowe. Dzięki przyjętej architekturze, Xellerate stanowi skalowalne, odporne na błędy rozwiązanie dla najbardziej nawet ambitnych wdrożeń w skali globalnej. Architektura Xellerate stosuje przyjęte standardy J2EE, w tym JSP, serwlety Java i komponenty EJB, wykorzystując tym samym wydajność i skalowalność, którymi wyróżniają się serwery J2EE. Xellerate obsługuje dodatkowo łączenie serwerów aplikacji w klastry, co pozwala osiągnąć wyższą wydajność i niemal całkowicie automatyczne przełączanie awaryjne w środowiskach obliczeniowych o znaczeniu krytycznym. Wykorzystanie standardów branżowych pozwala Xellerate obsługiwać warstwę danych za pomocą różnych korporacyjnych systemów baz danych, w tym Oracle Database i Microsoft SQL Server. Architektura dostarczania tożsamości Oracle Xellerate Strona 3

Xellerate obejmuje wszystkie możliwości, jakich można się spodziewać po najlepszym w branży systemie obsługi tożsamości. Architektura Xellerate ma za zadanie sprostać następującym celom przy wdrożeniach korporacyjnych: krótki czas wdrożenia błyskawiczne wdrażanie usług Xellerate, wysoka wydajność krótkie czasy reakcji i wydajna nawigacja, przenośność minimalizacja zależności od konkretnych platform i systemów zewnętrznych, skalowalność skalowanie od kilkunastu do wielu tysięcy użytkowników, łatwość utrzymania bezproblemowe administrowanie i konserwacja, wysoka dostępność system jest gotowy do pracy wtedy, gdy jest potrzebny, niezawodność spójność aplikacji i transakcji. Oracle Xellerate Identity Provisioning osiąga te cele dzięki przemyślanej architekturze i zastosowaniu nowoczesnych technologii J2EE, Java, XML i innych. N-warstwowa architektura była od samego początku opracowywana z myślą o wydajności, skalowalności i rozszerzalności i jest w całości zaimplementowana w języku Java. Projekt systemu stanowi odzwierciedlenie wieloletniego doświadczenia i specjalistycznych umiejętności w dziedzinie tworzenia i wdrażania wysokiej jakości korporacyjnych systemów obsługi tożsamości. Oracle Xellerate Identity Provisioning ma architekturę n- warstwowej aplikacji J2EE. OGÓLNA ARCHITEKTURA N-WARSTWOWYCH APLIKACJI J2EE Celem niniejszego rozdziału jest przedstawienie zarysu ogólnej architektury tworzonych w technologii J2EE (Java 2 Enterprise Edition) n-warstwowych aplikacji jakości produkcyjnej, do których należy również rozwiązanie Xellerate. Platforma J2EE definiuje szereg standardów dla tworzenia skalowalnych i niezawodnych aplikacji korporacyjnych z komponentów wielokrotnego użytku. J2EE określa też definicje takich standardowych modułów, dostarcza kompletny zestaw usług i obsługuje wiele szczegółowych aspektów funkcjonowania aplikacji. Podstawowe warstwy Opracowanie aplikacji n-warstwowej w J2EE wymaga wyróżnienia w jej architekturze kilku odrębnych warstw. Typowa n-warstwowa aplikacja korporacyjna zawiera następujące warstwy, z których każda pełni osobną funkcję: warstwa prezentacji, warstwa dynamicznej prezentacji, warstwa logiki aplikacji, warstwa dostępu do danych, warstwa integracji z systemami zaplecza. Rysunek 1 ilustruje miejsce poszczególnych warstw w typowej aplikacji rozproszonej J2EE. Architektura dostarczania tożsamości Oracle Xellerate Strona 4

Rysunek 1. Ogólna architektura n-warstwowa J2EE Warstwa prezentacji W typowej aplikacji n-warstwowej korzystającej z mechanizmów WWW warstwę prezentacji stanowi uruchomiona na komputerze klienckim przeglądarka internetowa odpowiedzialna za prezentację danych przekazywanych jej jako kod HTML, aplety Javy, skrypty JavaScript itd. Do warstwy prezentacji mogą też należeć niezależne aplikacje bezpośrednio komunikujące się z warstwą merytoryczną za pomocą wybranego protokołu obsługiwanego przez warstwę pośrednią. Warstwa prezentacji dynamicznej Choć możliwe byłoby wykonywanie części przetwarzania niezbędnego do prezentacji danych bezpośrednio w przeglądarkach, większość operacji związanych z dynamicznym generowaniem prezentacji odbywa się na serwerze WWW z wykorzystaniem stron JSP, serwletów, języków XML i XSL itp. Zalety takiego podejścia to jednolita obsługa wszystkich przeglądarek oraz generowanie danych prezentacji optymalnie dopasowanych do potrzeb. Warstwa logiki aplikacji Właściwa logika funkcjonowania aplikacji jest implementowana w warstwie pośredniej za pomocą serwera aplikacji J2EE wykorzystującego komponenty EJB (Enterprise Java Beans) i inne technologie J2EE, co pozwala wdrażać aplikacje złożone ze skalowalnych, rozproszonych i modułowych komponentów i usług. Warstwa dostępu do danych W tej warstwie znajdują się najczęściej komponenty dostępu do danych (w tym komponenty bean) umożliwiające współpracę z relacyjnymi bazami danych. Odbywa się tu również zarządzanie pulą połączeń JDBC. Mechanizm dostępu do danych można sobie wyobrazić jako obiektowe opakowanie dla relacyjnych baz danych, implementowane w postaci rozproszonych komponentów wielokrotnego użytku. Architektura dostarczania tożsamości Oracle Xellerate Strona 5

Warstwa integracji z systemami zaplecza Zaplecze systemu stanowi najczęściej zestaw rozproszonych relacyjnych baz danych, zintegrowanych z warstwą pośrednią z wykorzystaniem mechanizmu Java Database Connectivity (JDBC), który dodatkowo stanowi jednolity interfejs dostępu do wielu różnych baz danych. Warstwa integracji może też zawierać inne istniejące systemy, które są integrowane z aplikacją za pomocą odpowiedniej technologii dla konkretnego typu systemu. N-WARSTWOWA ARCHITEKTURA APLIKACJI J2EE W XELLERATE Jak już wspomniano, w każdej n-warstwowej aplikacji biznesowej stworzonej w technologii J2EE można wyróżnić pięć podstawowych warstw. W tej sekcji zostanie opisana implementacja tych warstw w architekturze J2EE zastosowanej w Xellerate. Rysunek 2 przedstawia n-warstwową architekturę J2EE rozwiązania Xellerate. Rysunek 2: N-warstwowa architektura Xellerate Warstwa prezentacji Warstwa prezentacji składa się z dwóch klientów: konsoli administratora i użytkownika oraz konsoli projektowej. Konsola administratora i użytkownika to uboga aplikacja kliencka dostępna za pośrednictwem dowolnej przeglądarki internetowej. Większość prezentowanych w niej treści jest wysoce dynamiczna, stąd też są one generowane przede wszystkim w warstwie prezentacji dynamicznej. Konsola udostępnia funkcje samoobsługi i administrowania delegowanego, pozwalające skutecznie obsłużyć większość użytkowników systemu dostarczania tożsamości. Wygląd i zachowanie aplikacji klienckiej można dostosować do konkretnych potrzeb za pomocą kaskadowych arkuszy stylów (CSS). Dodatkowe modyfikacje można wprowadzać w stronach JSP i komponentach Tile w obrębie warstwy prezentacji dynamicznej, zgodnie z poniższym opisem. Architektura dostarczania tożsamości Oracle Xellerate Strona 6

Konsola projektowa to bogato wyposażona aplikacja kliencka, uruchamiania w środowisku Java na komputerze użytkownika. Konsola pozwala wykorzystać pełen zakres możliwości konfiguracyjnych i projektowych Xellerate, udostępniając między innymi moduły do projektowania formularzy i przepływu zadań, moduł tworzenia adapterów oraz narzędzie wdrożeniowe wspomagające zautomatyzowane zarządzanie zmianami. Konsola projektowa współpracuje bezpośrednio z komponentami warstwy logiki aplikacji, więc zawiera też warstwę prezentacji dynamicznej. Warstwa prezentacji dynamicznej Treści prezentowane zarówno w konsoli administratora i użytkownika, jak i w konsoli projektowej są wysoce dynamiczne, więc za ich generowanie odpowiada warstwa prezentacji dynamicznej. O ile jednak w przypadku tej pierwszej aplikacji istnieje wyraźny podział na warstwę prezentacji i warstwę prezentacji dynamicznej, o tyle dla konsoli projektowej tego rozgraniczenia już nie ma. Aplikacja internetowa Xellerate Konsola administratora i użytkownika korzysta z możliwości systemu Xellerate za pośrednictwem aplikacji internetowej Xellerate, stworzonej z wykorzystaniem stron JSP, serwletów i komponentów JavaBeans w technologii Struts with Tiles. Struts to rozwijana jako oprogramowanie o otwartym kodzie źródłowym technologia budowania aplikacji internetowych w języku Java. Trzon technologii Struts stanowi elastyczna warstwa sterowania wykorzystująca standardowe mechanizmy w rodzaju serwletów Javy, komponentów JavaBean i ResourceBundle, języka XML oraz wybranych pakietów Jakarta Commons. Aktualna wersja klienta WWW Xellerate została zaprojektowana i opracowana z wykorzystaniem API Xellerate, z myślą o sprawnej współpracy z systemami w architekturze J2EE. Projekt aplikacji internetowej Xellerate opiera się na architekturze JavaServer Pages Model 2, stanowiącej rozwinięcie znanego wzorca projektowego Model-Widok-Kontroler (MVC Model-View-Controller). Rysunek 3 przedstawia ogólny schemat wzorca projektowego MVC. Architektura dostarczania tożsamości Oracle Xellerate Strona 7

Rysunek 3. Wzorzec projektowy Model-View-Controller (MVC) Struts dostarcza własny komponent kontrolera, natomiast komponenty modelu i widoku są dostarczane poprzez integrację z innymi technologiami model może być utworzony za pomocą standardowych technologii dostępu do danych, na przykład JDBC i EJB, a tworzenie widoku może się odbywać z wykorzystaniem JavaServer Pages (w tym JSTL i JSF), jak również szablonów Velocity, arkuszy XSLT i innych mechanizmów prezentacji. Model aplikacji internetowej Xellerate jest oparty na udostępnianych interfejsach API Xellerate, natomiast widok jest implementowany za pomocą technologii JavaServer Pages. Dostosowywanie Dzięki wykorzystaniu mechanizmu Struts aplikacja internetowa Xellerate daje duże możliwości konfiguracji i dostosowywania do konkretnych potrzeb. Klienci mogą z łatwością rozbudowywać aplikację o strony i przepływy operacji optymalnie dostosowane do środowiska instalacji. Modułowa struktura Podobnie jak pozostałe części systemu, również aplikacja internetowa Xellerate jest zbudowana modułowo. Tworzą ją przeznaczone do wielokrotnego użytku komponenty i elementy interfejsu użytkownika, z których klienci mogą swobodnie korzystać podczas dostosowywania aplikacji do własnych potrzeb. Podejście to pozwala znacznie ograniczyć nakład pracy niezbędnej do tworzenia komponentów przepływów zadań. Podejście projektowe Założenia projektowe aplikacji internetowej Xellerate opierają się na łatwości użytkowania i intuicyjnych zasadach obsługi. Dostępnych jest szereg kreatorów prowadzących użytkowników przez typowe zadania w przemyślany i intuicyjny sposób. Architektura dostarczania tożsamości Oracle Xellerate Strona 8

Konsola projektowa Xellerate Konsola projektowa Xellerate jest zaimplementowana jako aplikacja kliencka w języku Java z interfejsem użytkownika Swing, komunikująca się bezpośrednio z warstwą logiki aplikacji. Konsola udostępnia bogato wyposażony interfejs o stopniu zaawansowania niezbędnym do obsłużenia oferowanych przez Xellerate funkcji konfiguracyjnych i projektowych, na przykład projektowania formularzy i przepływów zadań czy też tworzenia adapterów i zarządzania nimi. Konsola ma budowę ściśle obiektową i komunikuje się bezpośrednio z komponentami EJB aplikacji Xellerate za pomocą zestawu interfejsów programowania. W konsolę wbudowane są dodatkowo zaawansowane mechanizmy administracji delegowanej, ograniczające zakres dostępu użytkowników wyłącznie do tych elementów konfiguracyjnych, do których używania mają oni niezbędne uprawnienia. Warstwa logiki aplikacji Warstwa logiki aplikacji Xellerate jest zaimplementowana w oparciu o komponenty EJB. Xellerate działa na najlepszych platformach serwerowych zgodnych z J2EE, maksymalnie wykorzystując udostępniane przez serwery usługi J2EE w celu dostarczenia aplikacji korporacyjnej o wysokiej jakości i odporności na błędy. Środowisko wykonawcze serwer aplikacji Serwer aplikacji, na którym działa system Xellerate, udostępnia komponentom logicznym Xellerate niezbędne usługi bezpieczeństwa, wdrażania, wykonywania i zarządzania czasem eksploatacji. Do usług tych należą: skalowalne zarządzanie zasobami (klastry, przełączanie awaryjne), zarządzanie transakcjami, zarządzanie bezpieczeństwem, obsługa dostępu klientów, zasoby techniczne (pule połączeń z bazami danych, komunikacja itd.). Dostępne są również wszelkie inne usługi wymagane do stworzenia platformy serwerowej i zarządzania nią. Klastry Klastrem w architekturze J2EE jest ogólnie grupa złożona z dwóch lub większej liczby zgodnych z J2EE serwerów WWW lub serwerów aplikacji, z których każdy zawiera te same dane, utrzymywane i aktualizowane za pomocą mechanizmów przezroczystej replikacji obiektów. Każdy serwer (węzeł) klastra ma taką samą konfigurację i jest połączony z pozostałymi w sieć działającą jako pojedynczy serwer wirtualny. Zgłoszenia klientów do takiego serwera wirtualnego mogą być obsłużone przez każdy z serwerów J2EE wchodzących w skład klastra, co daje taki sam efekt, jak w przypadku obsługi danej aplikacji J2EE przez pojedynczy serwer fizyczny. Wysoka dostępność oznacza w tym kontekście możliwość zapewnienia stałego funkcjonowania aplikacji udostępnianych klientom przez warstwę pośrednią. Osiągnięcie wysokiej dostępności Architektura dostarczania tożsamości Oracle Xellerate Strona 9

jest możliwe dzięki zastosowaniu w obrębie klastra nadmiarowych serwerów WWW i serwerów aplikacji oraz wykorzystaniu możliwości awaryjnego przełączania między węzłami klastra. Jeśli zadanie przekazane jednemu z komponentów aplikacji nie zostanie wykonane, mechanizm przełączania klastra przekieruje to zadanie i wszelkie dane wymagane do jego realizacji do kopii tego samego obiektu na innym serwerze, który przejmie dalsze wykonywanie. Obsługa środowiska klastrów jest wbudowana w aplikację Xellerate. Oznacza to między innymi, że wszystkie komponenty EJB i obiekty wartości używane do składowania danych obsługują serializację, która jest niezbędna dla funkcjonowania replikacji obiektów. Wyrównywanie obciążenia Pełne wykorzystanie oferowanej przez konfigurację klastrową wysokiej dostępności, skalowalności i wydajności wymaga stosowania mechanizmów wyrównywania obciążenia, czyli optymalnego rozdzielania zgłoszeń klientów pomiędzy serwery J2EE wchodzące w skład klastra. Wybór konkretnego serwera jest dokonywany na podstawie danych o wydolności, dostępności, czasie reakcji, aktualnym obciążeniu i dotychczasowej wydajności, jak również na podstawie priorytetów administracyjnych przypisanych poszczególnym serwerom w klastrze. Komponent wyrównywania obciążenia (programowy lub sprzętowy) pośredniczy między Internetem a fizycznym klastrem serwerów jako serwer wirtualny. W przypadku każdego nadchodzącego zgłoszenia klienta komponent ten niemal natychmiastowo podejmuje inteligentną decyzję o wyborze serwera J2EE, który w danej chwili najlepiej obsłuży konkretne żądanie. Architektura Xellerate w pełni wykorzystuje wbudowane mechanizmy wyrównywania obciążenia dla serwera aplikacji, na którym jest uruchomiona. Zarządzanie bezpieczeństwem Ogólna infrastruktura bezpieczeństwa Xellerate wykorzystuje niektóre usługi bezpieczeństwa udostępniane przez serwer aplikacji. Usługi te są omówione szczegółowo w części Bezpieczeństwo, opisującej ogólny model bezpieczeństwa Xellerate. Wykorzystanie komunikatów Java Messaging Service pozwala systemowi Oracle Xellerate zapewnić wyższą wydajność i mechanizmy wyrównywania obciążenia. Komunikaty W odniesieniu do aplikacji rozproszonych, komunikaty to wymieniane między komponentami samodzielne pakiety informacji, składające się z właściwych danych i nagłówków adresowych. Komunikacja z wykorzystaniem protokołów RMI i HTTP polega na dwukierunkowej, aktywnej wymianie informacji między klientem a serwerem, podczas gdy mechanizm komunikatów polega na asynchronicznej (czyli niewymagającej oczekiwania na odpowiedź) komunikacji dwóch lub większej liczby stron za pośrednictwem serwera komunikatów. JMS (Java Messaging Service) to usługa komunikatów Javy, zdefiniowana jako standardowe API J2EE opakowujące mechanizmy komunikacji. Wszystkie standardowe serwery aplikacji dostarczają własne implementacje serwerów JMS (serwerów komunikatów) w ramach oferowanych usług. Platforma Xellerate wykorzystuje mechanizmy komunikatów w celu dostarczenia wyższej wydajności i obsługi wyrównywania obciążenia. Odbywa się to poprzez przekazywanie zadań do wykonania w trybie offline, co pozwala oddzielić interakcję użytkownika z aplikacją od faktycznego przetwarzania inicjowanego przez działania użytkownika. Jeśli użytkownik inicjuje Architektura dostarczania tożsamości Oracle Xellerate Strona 10

działanie, które może wymagać intensywnego przetwarzania, wskazane jest przekazanie sterowania z powrotem do konsoli użytkownika jeszcze przed zakończeniem samej operacji. W tym celu żądane przez użytkownika działanie nie jest podejmowane bezpośrednio po otrzymaniu żądania, lecz do systemowej kolejki komunikatów dodawany jest komunikat dotyczący tego działania. Wysłanie komunikatu jest operacją niewymagającą obliczeniowo, a użytkownik natychmiast otrzymuje informację o aktualnym stanie przetwarzania. Komunikat zostanie odebrany asynchronicznie, po czym zostaną podjęte operacje stosowne dla jego treści. Moduły obsługujące komunikaty mogą być rozproszone po całym klastrze serwerów aplikacji, dzięki czemu możliwe jest optymalne rozkładanie obciążenia związanego z obsługą wielu równoczesnych działań użytkowników na poszczególne węzły klastra. Rysunek 4 przedstawia przegląd stosowanego w Xellerate przetwarzania offline opartego na komunikatach. Rysunek 4: Przetwarzanie offline oparte na komunikatach Komunikaty są trwale zapisywane w składzie danych w celu zagwarantowania ich dostarczenia w przypadku przełączenia awaryjnego. Trwałym składowaniem sterują standardowe, konfigurowane przez administratora mechanizmy serwera aplikacji. Interfejsy klientów i implementacja logiki aplikacji Warstwa logiki aplikacji Xellerate jest implementowana w postaci aplikacji EJB. Podstawowe możliwości platformy Xellerate są zrealizowane w Javie z wykorzystaniem modułowej i ściśle obiektowej metodyki projektowej, dzięki której aplikacja jest bardzo elastyczna i łatwa w rozbudowie. Dotyczy to w równej mierze wszystkich mechanizmów przetwarzających składających się na Xellerate, a więc mechanizmów przepływu zadań, obsługi żądań, zarządzania użytkownikami, zarządzania regułami i ujednolicania danych, jak również bazującej na Adapter Factory warstwy integracji, która na podstawie metadanych definiujących adaptery dynamicznie tworzy kod integrujący. Dostęp do możliwości platformy odbywa się za pośrednictwem zestawu komponentów EJB sesji, które można podzielić na dwie kategorie: Architektura dostarczania tożsamości Oracle Xellerate Strona 11

1. API niepubliczne: komponenty EJB sesji udostępniające operacje wyłącznie na potrzeby konsoli projektowej. 2. API publiczne: komponenty EJB sesji publicznie udostępniające operacje Xellerate. Warstwa interfejsu API pośredniczy w dostępie do uogólnionych mechanizmów wysokiego poziomu Xellerate. API publiczne stanowi również podstawę implementacji aplikacji internetowej Xellerate, a zewnętrzne aplikacje mogą za jego pośrednictwem korzystać z operacji udostępnianych prze Xellerate. Dostęp do aplikacji odbywa się poprzez moduł fabrykujący API. Wszystkie interfejsy API są zaimplementowane jako bezstanowe komponenty EJB sesji i wykorzystują infrastrukturę J2EE do obsługi wyszukiwania i komunikacji. Środowisko klienckie Oracle Identity Provisioning daje duże możliwości dostosowania do konkretnych potrzeb. Zewnętrzne aplikacje klienckie Dość często pojawia się potrzeba współpracy systemu obsługi tożsamości z firmową aplikacją kliencką. Typowe czynniki przemawiające za wprowadzeniem takiej aplikacji to: integracja aplikacji z istniejącym portalem korporacyjnym, tworzenie nowych przepływów zadań dla obsługi użytkowników, tworzenie nowych widoków systemu obsługi tożsamości, dostosowanych do konkretnych potrzeb klienta, utrzymanie zgodności z firmowymi zasadami dostępu do portalu. Xellerate udostępnia aplikacjom zewnętrznym większość potrzebnych operacji za pośrednictwem publicznych interfejsów API. Wraz z aplikacją dostarczany jest również obszerny zestaw narzędzi programistycznych wspomagających proces tworzenia aplikacji klienckich. Warstwa dostępu do danych Technologia J2EE obsługuje kilka mechanizmów dostępu do zasobów transakcyjnych (przede wszystkim baz danych), w tym JDBC, JTA i JTS. W architekturze Xellerate wykorzystane są następujące usługi J2EE: tworzenie pul połączeń z bazą danych, integracja z JNDI obejmująca lokalizację źródeł danych w przestrzeni nazw JNDI, zgodność ze standardem XA, grupowe aktualizacje. Z punktu widzenia administratora, zarządzanie źródłami danych wygląda tak samo, jak w przypadku innych standardowych aplikacji J2EE w firmie. Xellerate wykorzystuje następnie te źródła danych do komunikacji z warstwą baz danych. Xellerate zawiera specjalnie stworzoną warstwę trwałości danych. Jest ona oparta na mechanizmach JDBC, a jej zadaniem jest zarządzanie trwałym zapisem informacji w bazie danych. Opracowanie wyspecjalizowanej implementacji miało na celu optymalizację przetwarzania złożonych danych występujących w transakcjach związanych z obsługą tożsamości i osiągnięcie znacznie wyższej wydajności niż w przypadku wykorzystania kontenerowych lub uogólnionych mechanizmów trwałego składowania. Architektura dostarczania tożsamości Oracle Xellerate Strona 12

Istotnym wymaganiem dla prawidłowej pracy aplikacji Xellerate jest zgodność wykorzystywanej bazy danych ze standardem XA, co wymaga włączenia obsługi tego standardu na poziomie samego systemu baz danych. Obsługa standardu XA jest konieczna, aby serwer aplikacji mógł poprawnie zarządzać transakcjami obejmującymi nie tylko połączenia z bazą danych, lecz również dostarczanie i potwierdzanie odbioru komunikatów. Warstwa integracji z systemami zaplecza Baza danych Warstwę danych Xellerate stanowi repozytorium zarządzające metadanymi zapisywanymi w relacyjnej bazie danych zgodnej ze standardem ANSI SQL 92. Działanie Xellerate jest w dużym stopniu oparte na metadanych, a wszystkie niezbędne informacje są składowane w repozytorium. To właśnie dzięki metadanym system Xellerate jest tak elastyczny i łatwy w adaptacji do potrzeb użytkowych. W repozytorium składowane są informacje o atrybutach przyporządkowanych podmiotom zarządzanym przez system, jak również wszystkie dane śledzenia, stanowiące trzon procesów dostarczania tożsamości. Wszystko to oznacza, że baza danych jest elementem kluczowym dla funkcjonowania architektury Xellerate. System baz danych musi w związku z tym dostarczać faktycznie skalowalną i nadmiarową warstwę danych. Funkcjonowanie systemu Xellerate w dużym stopniu zależy od możliwości udostępnianych przez zastosowany dla niego system zarządzania bazą danych. Niezbędne funkcje to między innymi: obsługa klastrów, zapasowe bazy danych, replikacja. Obsługa klastrów Większość uznanych producentów systemów baz danych ma w swej ofercie certyfikowany sprzęt i oprogramowanie, na którym można łatwo uruchomić bazę danych w konfiguracji klastrowej. Xellerate wykorzystuje te możliwości do dostarczenia nadmiarowości danych. Rysunek 6 przedstawia przykładową konfigurację klastra. Architektura dostarczania tożsamości Oracle Xellerate Strona 13

Rysunek 6: Przykładowy klaster baz danych Przedstawiona powyżej konfiguracja zawiera dwa węzły serwerowe, z których każdy dysponuje dwiema kartami sieciowymi. Węzły te współdziałają w celu stworzenia pojedynczego logicznego punktu dostępowego do bazy danych, a wszystkie otrzymywane zgłoszenia klientów są kierowane do jednego z węzłów fizycznych. Każdy z serwerów wykorzystuje jedną ze swych kart sieciowych do komunikacji z drugim serwerem w obrębie klastra. Węzły korzystają z prywatnych adresów IP, tworząc w efekcie prywatną sieć ethernetową dla klastra. Druga karta sieciowa każdego z serwerów jest podłączona do głównej sieci ethernetowej, przy czym również w tym przypadku każdy serwer ma własny adres IP. Klaster ma dodatkowo własny adres IP, używany do komunikacji ze światem zewnętrznym. Kierowanie nadchodzących zgłoszeń do odpowiedniego serwera fizycznego jest obsługiwane wewnętrznie przez oprogramowanie klastra. Baza danych jest instalowana na współużytkowanej macierzy dysków twardych SCSI w konfiguracji sprzętowej RAID 5 zapewniającej nadmiarowość i szybki dostęp do danych. Za pośrednictwem interfejsu administracyjnego można łatwo przełączyć całe obciążenie klastra na jeden z węzłów, co może być przydatne w razie konieczności wyłączenia jednego z serwerów w celach konserwacyjnych. Wszystkie aplikacje aktualnie uruchomione na jednym z serwerów zostaną przeniesione na drugi serwer. Przesyłanie i synchronizacja danych po ponownym dołączeniu węzła do klastra mogą się odbywać automatycznie lub o ustalonych porach. Inną ważną zaletą wykorzystania klastrów jest to, że implementacja prostego klastra nie wymaga żadnych specjalnych zabiegów programistycznych, gdyż z punktu widzenia aplikacji klaster to po prostu pojedynczy serwer baz danych z bezpośrednim dostępem do dysku. Architektura dostarczania tożsamości Oracle Xellerate Strona 14

Wdrożenia Oracle Xellerate Identity Provisioning maksymalnie wykorzystują mechanizmy wysokiej dostępność baz danych Oracle10g. Zapasowa baza danych Zapasowa baza danych pracuje w trybie bez połączenia (offline) i zawiera dokładną kopię podstawowej bazy danych, która jest w trybie z połączeniem (online) i obsługuje bieżące zgłoszenia aplikacji. W celu zapewnienia dostępności bazy danych w przypadku awarii dotykających całego stanowiska instalacji serwera, baza podstawowa i zapasowa muszą się znajdować na różnych serwerach fizycznych w różnych lokalizacjach fizycznych. Obie bazy danych muszą pracować w trybie odtwarzania nośnika. Musi też istnieć mechanizm, który w miarę wypełniania grup plików dziennika bazy podstawowej wpisami archiwalnymi wprowadza zarejestrowane operacje do bazy zapasowej w celu bieżącej synchronizacji jej zawartości ze zmianami wprowadzanymi w bazie głównej. Rysunek 7 przedstawia ogólną strukturę konfiguracji z zapasową bazą danych. Rysunek 7: Konfiguracja z zapasową bazą danych W przypadku awarii powodującej niedostępność podstawowej bazy danych przez niedopuszczalnie długi czas możliwa jest aktywacja bazy zapasowej i przełączenie jej w tryb online. W takiej sytuacji Xellerate musi przełączyć się na nową bazę główną. Możliwość przełączenia bazy danych w środowisku Oracle wymaga takiego skonfigurowania sieci SQL*Net, aby uwzględniane były obie bazy. Replikacja W kontekście baz danych replikacja to proces współużytkowania danych między bazami w różnych lokalizacjach fizycznych, polegający na tworzeniu specjalnych kopii (replik) całej bazy danych. Użytkownicy w poszczególnych lokalizacjach pracują na lokalnych kopiach baz, a wprowadzane zmiany są współużytkowane (synchronizowane). Wdrożenie systemu Xellerate może obejmować mechanizmy replikacji baz danych, co pozwala obsługiwać niezbędne w przypadku wdrożeń globalnych przetwarzanie z wykorzystaniem rozproszonych baz danych. Replikacja baz danych różni się od replikacji plików, która w gruncie rzeczy sprowadza się do kopiowania plików. Replikacja bazy danych wymaga zapisywania wybranych transakcji do specjalnie utworzonych tabel zarządzania replikacją. Oprogramowanie replikujące regularnie śledzi zmiany wprowadzane w tych tabelach i wprowadza te same zmiany w bazach docelowych z zachowaniem spójności danych. Replikacja baz danych pozwala sprostać wielu problemom związanym z tworzeniem systemu rozproszonego: Architektura dostarczania tożsamości Oracle Xellerate Strona 15

Utworzenie replik baz danych w poszczególnych oddziałach przedsiębiorstwa pozwala użytkownikom pracować na lokalnej kopii danych, bez konieczności ciągłego łączenia się z centralnym serwerem przez sieć rozległą. Proces replikacji może również obejmować przesyłanie wybranych zestawów danych do serwera raportów, co pozwala zdjąć z głównej transakcyjnej bazy danych obciążenie związane z wykonywaniem wymagających obliczeniowo operacji analitycznych. Komponent Remote Manager Remote Manager to uruchamiany na systemie docelowym komponent serwerowy Xellerate zapewniający warstwę obsługi sieci i mechanizmów bezpieczeństwa niezbędną do poprawnej integracji z aplikacjami pozbawionymi odpowiednich do tych celów interfejsów API. Komponent ten jest zaimplementowany jako lekki serwer RMI (Remote Method Invocation). Stosowanym protokołem komunikacyjnym jest RMI tunelowany przez HTTP/HTTPS. Dostępne w J2EE mechanizmy RMI pozwalają tworzyć logicznie jednolite, rozproszone usługi i aplikacje. Aplikacje oparte na RMI składają się z obiektów Javy wywołujących wzajemnie swoje metody, niezależnie od faktycznej lokalizacji poszczególnych obiektów. RMI pozwala obiektowi Javy wywoływać metody innego obiektu uruchomionego na innej maszynie wirtualnej w taki sam sposób, jak miałoby to miejsce dla obiektu działającego w tej samej maszynie wirtualnej. Rysunek 8 przedstawia schemat działania serwera Remote Manager. Rysunek 8: Architektura serwera Remote Manager Architektura dostarczania tożsamości Oracle Xellerate Strona 16

Mechanizmy planowania zadań Oracle Xellerate Identity Provisioning pozwalają wykonywać regularne operacje związane z obsługą tożsamości, w tym dobowe aktualizacje, konfigurowanie pakietowe i obsługę wyjątków. HARMONOGRAM ZADAŃ XELLERATE Systemy przedsiębiorstw często korzystają z mechanizmów planowania zadań, których przeznaczeniem jest uruchamianie innych programów o wskazanych porach. Harmonogramy zadań są nierzadko wykorzystywane do uruchamiania w nocy aplikacji generujących raporty, formatujących dane lub przeprowadzających operacje analityczne. Często służą też do regularnego wykonywania rutynowych prac zdefiniowanych jako zadania wsadowe, czyli zestawy zaplanowanych operacji. Systemy planowania zadań stanowią też nieodłączny element każdego korporacyjnego rozwiązania do obsługi tożsamości, gdzie obsługują zadania wymagające cyklicznego uruchamiania. Przykłady takich operacji to: wykonywane co noc ujednolicenie wszystkich zmian wprowadzonych bezpośrednio do zarządzanej aplikacji, przenoszenie zadań niewykonanych w wymaganym terminie na wyższy poziom obsługi, obsługa zgłoszeń, których wykonanie zostało zaplanowane na określoną godzinę. W skład platformy Xellerate wchodzi harmonogram zadań dostarczający wszystkie mechanizmy niezbędne do sprawnej pracy korporacyjnego rozwiązania do dostarczania tożsamości. Podstawę modułu planowania zadań stanowi dostępny na zasadach open source komponent J2EE o nazwie Quartz. Usługa Quartz podlega zarządzaniu jako element platformy Xellerate, a nie jako osobny moduł. Rysunek 9 przestawia ogólny schemat architektury harmonogramu zadań Xellerate. Architektura dostarczania tożsamości Oracle Xellerate Strona 17

Rysunek 9: Architektura harmonogramu zadań Xellerate Najważniejsze spośród wykorzystywanych przez Xellerate funkcji modułu Quartz to: możliwość tworzenia dowolnie złożonych harmonogramów zadań, wykonywanych w dowolnych miejscach systemu i obejmujących od kilkunastu do wielu tysięcy zadań, możliwość uruchamiania harmonogramu w konfiguracji klastra w celu dostarczenia wymaganych mechanizmów wysokiej dostępności (przełączania awaryjnego i wyrównywania obciążenia), możliwość trwałego składowania definicji zadań w celu łatwiejszego zarządzania i obsługi przełączania awaryjnego, możliwość definiowania kompleksowych mechanizmów obsługi błędów i nieudanych operacji. Usługa harmonogramu Quartz może także być uruchamiana na tym samym serwerze aplikacji, co aplikacja Xellerate, jak i na innym serwerze aplikacji. Zadania wykonywane w ramach harmonogramu mogą korzystać z operacji udostępnianych przez publiczne API Xellerate, ale mogą też wykonywać dowolny inny kod niezbędny do komunikacji z innymi systemami, co jest szczególnie przydatne w przypadku zadań związanych z ujednolicaniem danych. MODEL BEZPIECZEŃSTWA PLATFORMY XELLERATE Xellerate jest bezpieczną aplikacją korporacyjną, zapewniającą bezpieczeństwo wszystkich poufnych danych przepływających przez systemy firmowe. Wysoce elastyczny model uprawnień daje precyzyjną kontrolę nad różnorodnymi aspektami działania aplikacji, jednak szczegółowe jego omówienie wykracza poza ramy niniejszego artykułu. Architektura dostarczania tożsamości Oracle Xellerate Strona 18

Oracle Xellerate Identity Provisioning wykorzystuje mechanizmy bezpieczeństwa J2EE w celu dostarczenia bezpiecznego środowiska aplikacyjnego. Bezpieczne kanały komunikacji Model zabezpieczeń J2EE umożliwia szyfrowanie wszystkich kanałów komunikacji w całym systemie z wykorzystaniem standardowego protokołu SSL. Xellerate wykorzystuje tę możliwość do zabezpieczenia wszystkich przesyłanych informacji dotyczących dostarczania tożsamości przez dostępem osób niepowołanych i próbami włamania. Rysunek 10 przedstawia architekturę bezpieczeństwa systemu Xellerate. Rysunek 10: Schemat zabezpieczeń transmisji danych w Xellerate Wypada tu zauważyć, że kanał JDBC używany do wymiany danych między Xellerate a bazą danych nie jest domyślnie szyfrowany z wykorzystaniem SSL. Informacje wymieniane z bazą danych są już zaszyfrowane przez Xellerate tajnym kluczem bazy danych, więc dodatkowe szyfrowanie transmisji jest w tym przypadku wyłączone w celu zwiększenia wydajności. W razie potrzeby, administrator może włączyć szyfrowanie również tego kanału, postępując zgodnie z odpowiednimi procedurami dla używanej bazy danych. Bezpieczeństwo kluczy i certyfikatów W domyślnej instalacji aplikacji Xellerate wszystkie klucze szyfrujące i certyfikaty są składowane w bezpiecznych repozytoriach Javy. Możliwa jest konfiguracja algorytmów używanych do szyfrowania repozytoriów oraz określanie metod zabezpieczania komponentów i zarządzania nimi. Architektura dostarczania tożsamości Oracle Xellerate Strona 19

Bezpieczeństwo komponentów Remote Manager Jedną z kluczowych zalet komponentu Remote Manager jest to, że umożliwia on bezpieczną komunikację systemu Xellerate z aplikacjami pozbawionymi własnej warstwy bezpieczeństwa. Każdy komponent Remote Manager objęty wdrożeniem Xellerate ma własny certyfikat, za pomocą którego uwierzytelnia się na serwerze Xellerate. Certyfikaty te stanowią również podstawę zestawiania szyfrowanych połączeń SSL dla kanału wywołań RMI tworzonego między każdym komponentem Remote Manager a serwerem Xellerate. Serwer ufa wyłącznie certyfikatom zarejestrowanym, co uniemożliwia uzyskanie nieautoryzowanego dostępu do danych poprzez przedstawienie fałszywego certyfikatu. Co więcej, komunikację z komponentem Remote Manager może nawiązywać tylko serwer Xellerate. Rysunek 11 przedstawia architekturę zabezpieczeń komponentu Remote Manager. Rysunek 11: Struktura zabezpieczeń komponentu Remote Manager Uwierzytelnianie JAAS Mechanizmy zabezpieczeń J2EE są również wykorzystywane przez Xellerate do zabezpieczania dostępu do publicznych API komponentów EJB służy do tego usługa JAAS (Java Authentication and Authorization Services). Z metod API udostępniających operacje Xellerate mogą dzięki temu korzystać wyłącznie użytkownicy uwierzytelnieni. Xellerate obsługuje moduły uwierzytelniania JAAS optymalnie wykorzystujące możliwości certyfikowanych serwerów aplikacji, na których można uruchamiać system Xellerate. KONFIGURACJE WDROŻENIA Xellerate w pełni wykorzystuje elastyczność i skalowalność platformy J2EE, dzięki czemu klienci mogą wybierać spośród wielu konfiguracji wdrożenia i wybrać tę, która najlepiej pasuje do ich potrzeb. W niniejszym rozdziale przedstawionych zostanie kilka typowych konfiguracji. Architektura dostarczania tożsamości Oracle Xellerate Strona 20

Konfiguracja 1 wdrożenie proste Najprostsze wdrożenie polega na uruchomieniu na jednym serwerze aplikacji wszystkich elementów Xellerate, w tym serwera tożsamości, serwera WWW i harmonogramu zadań. Konfigurację tę ilustruje Rysunek 12. Rysunek 12: Proste wdrożenie Xellerate Konfiguracja 2 wdrożenie klastra Kolejna konfiguracja rozbudowuje konfigurację prostą o możliwości oferowane przez klaster serwerów, obejmujące mechanizmy wyrównywania obciążenia i przełączania awaryjnego. Konfiguracja ta jest zatem odpowiednia dla wdrożeń wymagających wysokiej dostępności. Możliwa jest współpraca systemu z istniejącymi zaporami sieciowymi. Wysoką dostępność można zapewnić również na poziomie danych poprzez wybór odpowiedniej konfiguracji serwera baz danych. Rysunek 13 przedstawia przykładową konfigurację klastrową Xellerate. Rysunek 13: Wdrożenie Xellerate w konfiguracji klastra Architektura dostarczania tożsamości Oracle Xellerate Strona 21

Konfiguracja 3 wdrożenie z serwerem proxy Konfiguracja z serwerem proxy polega na rozbudowaniu konfiguracji 2 o dodatkową warstwę umożliwiającą udostępnianie użytkownikom interfejsu WWW przez osobny serwer WWW (na przykład IIS lub Apache), pełniący rolę serwera proxy dla żądań stron WWW zgłaszanych do komponentu aplikacji Xellerate na serwerze aplikacji. Konfiguracja taka daje następujące dodatkowe możliwości: przezroczyste przełączanie awaryjne klientów WWW za pośrednictwem wtyczek serwera aplikacji do serwerów WWW, obsługę uwierzytelniania z jednokrotnym logowaniem, przenoszenie treści statycznych i grafiki na serwer WWW w celu zwiększenia wydajności. Liczbę serwerów WWW można też zwiększać stosownie do obciążenia ze strony użytkowników, a niezależnie od liczby serwerów aplikacji, co daje skalowalność poziomą. Rysunek 14 przedstawia konfigurację Xellerate z serwerem proxy. Rysunek 14: Konfiguracja Xellerate z serwerem proxy Architektura dostarczania tożsamości Oracle Xellerate Strona 22

Oracle Xellerate Identity Provisioning można wdrożyć w kilku różnych konfiguracjach, co pozwala dopasować wdrożenie do konkretnych potrzeb przedsiębiorstwa. Konfiguracja 4 wdrożenie partycjonowane Kolejna konfiguracja polega na wprowadzeniu dodatkowego podziału do konfiguracji 3. Komponent serwera Xellerate jest dzielony na dwa komponenty logiczne obsługujące różne rodzaje zgłoszeń: Serwer aplikacji obsługujący klientów dostarcza wszystkie usługi Xellerate niezbędne dla prawidłowego funkcjonowania aplikacji internetowej Xellerate. Serwer aplikacji zaplecza obsługuje harmonogram zadań, przejmując tym samym wymagające intensywnego przetwarzania regularne zadania ujednolicania danych. Komponent ten dostarcza wszystkie usługi niezbędne do pracy harmonogramu zadań. Konsola projektowa może współpracować z obydwoma komponentami serwera aplikacji, jednak do zarządzania funkcjami harmonogramu zadań (definiowania nowych zadań, przeglądania istniejących zadań itd.) konieczne jest połączenie z serwerem aplikacji zaplecza. Rysunek 15 przedstawia przykład wdrożenia partycjonowanego Xellerate. W pokazanej konfiguracji każda z partycji jest niezależną instalacją Xellerate uruchomioną na osobnym klastrze i wymagającą osobnego zarządzania (z punktu widzenia adapterów i innych elementów konfiguracyjnych). Partycje korzystają jednak ze wspólnych danych konfiguracyjnych, na przykład kluczy szyfrujących. Obsługa partycjonowania sprowadza się do prostej konfiguracji każdej z instalacji Xellerate w kwestii obsługi harmonogramu. Rysunek 15: Wdrożenie Xellerate w konfiguracji partycjonowanej Architektura dostarczania tożsamości Oracle Xellerate Strona 23

Konfiguracje wdrożenia komponentów Remote Manager Rysunek 16: Możliwości wdrożenia komponentów Remote Manager Wybór konfiguracji wdrożenia poszczególnych komponentów Remote Manager wchodzących w skład rozwiązania Xellerate zależy od wymaganego sposobu działania każdego z tych komponentów. Jeśli komponent Remote Manager odwołuje się do interfejsów API dostępnych wyłącznie na fizycznej maszynie obsługującej aplikację docelową lub obsługuje bezpieczną komunikację z taką aplikacją, to powinien on być uruchamiany na tej samej maszynie fizycznej (komponent R1 z Rysunku 16). Jeżeli jednak komponent Remote Manager nie korzysta z lokalnych interfejsów API na tej samej maszynie, lecz wywołuje operacje na innym komputerze w tej samej domenie/sieci lub korzysta z tego samego systemu operacyjnego, co maszyna docelowa (a różnego od systemu operacyjnego serwera aplikacji Xellerate), to można go uruchomić na maszynie pośredniej (komponent R2 z Rysunku 16). PODSUMOWANIE Oracle Xellerate Identity Provisioning to bezpieczne, skalowalne i elastyczne korporacyjne rozwiązanie do obsługi tożsamośc, które umożliwia dostosowanie do różnorodnych potrzeb. Wszystkie dostępne funkcje opierają się na solidnej podstawie architektury Xellerate, stanowiącej przykład wykorzystania najlepszych nowoczesnych procedur w dziedzinie tworzenia n-warstwowych aplikacji w technologii J2EE. Dzięki elastycznej architekturze możliwych jest wiele konfiguracji wdrożenia Oracle Xellerate Identity Provisioning od prostego wdrożenia na pojedynczym serwerze aplikacji po rozbudowane wdrożenia z klastrami i serwerami pośrednimi, zapewniające mechanizmy płynnego przełączania awaryjnego, skalowalność pionową i wysoką wydajność. Architektura dostarczania tożsamości Oracle Xellerate Strona 24