POLSKO JAPOŃSKA WYŻSZA SZKOŁA TECHNIK KOMPUTEROWYCH

Wielkość: px
Rozpocząć pokaz od strony:

Download "POLSKO JAPOŃSKA WYŻSZA SZKOŁA TECHNIK KOMPUTEROWYCH"

Transkrypt

1 POLSKO JAPOŃSKA WYŻSZA SZKOŁA TECHNIK KOMPUTEROWYCH KATEDRA INŻYNIERII OPROGRAMOWANIA PIOTR STERNA NR ALBUMU 5976 UDOSTĘPNIANIE USŁUG KORPORACYJNYCH W OPARCIU O JĘZYK SPML Praca magisterska napisana pod kierunkiem: dra inż. Mariusza Trzaski Warszawa, luty 2010

2 2 Streszczenie Niniejsza praca traktuje o wykorzystaniu Service Provisioning Markup Language w korporacyjnych systemach informatycznych. Technologia ta dostarcza specyfikacji języka oraz protokołu wymiany danych przedstawiających spójny standard implementowania projektów integracyjnych opartych o zarządzanie grupami obiektów biznesowych. W pierwszej części pracy autor skupia się na usystematyzowaniu wiedzy nt. SPML i opisie wzorców sprawdzonych przy projektowaniu systemów opartych o tę technologię. Poruszone zostaną również problemy wynikające z nieprecyzyjności niektórych założeń specyfikacji oraz zostanie wskazanych kilka konkretnych błędów w niej znalezionych. Druga część pracy opisuje implementacje istniejących systemów oraz bibliotek programistycznych opartych o SPML. W szczególności przedstawiona zostanie pokrótce architektura systemu Sun Identity Manager, będącego najpopularniejszą aktualnie aplikacją oficjalnie wspierającą SPML. W trzeciej części autor opisuje główne założenia prostej implementacji własnej biblioteki udostępniającej operacje SPML oraz pokrótce opisuje główne założenia jej wykorzystania. Podziękowania Autor składa podziękowania dla Gabe a Garzy, członka Central Architecture Team korporacji Sabre Holdings. Był on głównym inicjatorem integracji firmowych systemów informatycznych za pomocą języka SPML, a jednocześnie nieocenionym źródłem wskazówek w trakcie ponad półrocznej pracy autora nad projektem integrującym systemy kilkunastu linii lotniczych.

3 3 Spis treści Spis treści Wstęp Cel i rezultat pracy Uwagi ogólne Usługi sieciowe SOAP Komunikat SOAP Bezpieczeństwo SOAP a pozostałe specyfikacje Service Provisioning Markup Language Requesting Authority Provisioning Service Provider Provisioning Service Target Obiekty zarządzane (PSO) Struktura obiektów zarządzanych Profile SPML Model żądania i odpowiedzi Kody błędów Tryby wykonywania operacji Grupowanie żądań Operacje Funkcjonalności Podstawowe - Core Funkcjonalności Hasła Password Funkcjonalności dezaktywacji obiektu - Suspend Niestandardowe Funkcjonalności Transakcyjność Istniejące implementacje SPML OpenSPML Sun Identity Manager Adaptery zasobów... 40

4 Nazwy użytkowników a heterogeniczne systemy docelowe Przepływy prac IDM a SPML Open Content Istniejące implementacje IDM Uwagi ogólne Wykorzystane technologie Spring Hibernate Apache CXF Apache Directory Server PostgreSQL Implementacja specyfikacji SPML Opis biblioteki Obsługa błędów Niskopoziomowa walidacja komunikatów Przykład użycia biblioteki integracja z Sun Identity Manager Podsumowanie Źrodła i bibliografia... 80

5 5 1. Wstęp Termin udostępnianie usług w tytule pracy nie jest dosłownym tłumaczeniem angielskiego terminu service provisioning, stanowiącego właściwy przedmiot niniejszego opracowania. Niestety ten ostatni nie posiada w języku polskim odpowiednika, a terminu prowizjonowanie, wykorzystywanego w kręgach IT brak jest w słownikach języka polskiego. Z racji na mogące wynikać z tego powodu nieporozumienia, w tytule pracy zaproponowano termin udostępnianie. Service provisioning jest pojęciem znanym w korporacyjnych systemach informatycznych i rozumianym, jako zespół działań mających na celu wstępne przygotowanie pewnych zasobów i usług, które z kolei mają być wykorzystywane przez grupę powiązanego ze sobą oprogramowania. Pod względem biznesowym zasoby dzielimy na 2 rodzaje źródła danych oraz usługi. Do tych pierwszych zaliczamy głównie wszelkiego rodzaju bazy danych, serwery usług katalogowych oparte o protokół LDAP, czy choćby pliki tekstowe lub binarne stanowiące miejsce przechowywania danych dla systemów informatycznych. Pod pojęciem usług zaś rozumiemy zarówno same systemy informatyczne, jak również ich komponenty składowe reprezentujące logikę biznesową z wyłączeniem źródeł danych. Powyższy podział może wydawać się jakoby sztuczny, bo po pierwsze dla obiektu będącego podmiotem i jakoby klientem przygotowywania usług takie niuanse techniczne są mało istotne, a po drugie z reguły systemy informatyczne i tak korzystają z jakichś źródeł danych. Jak się jednak przekonamy w opisie części praktycznej rozdzielenie tych dwóch typów zasobów ma nie tylko sens, ale jest wręcz koniecznością biznesową. Poza zasobami, centralnymi punktami odniesienia w przygotowywaniu usług są byty zwane użytkownikiem, organizacją oraz rolą (zwaną też czasami produktem ). Poprzez użytkownika rozumiemy zarówno ludzi jak i ściśle określoną logikę biznesową wykonującą jakiegoś rodzaju operacje w systemie. Organizacją jest zwykle jakieś przedsiębiorstwo lub też jej dział. Natomiast rolą może być jakikolwiek zespół cech nadający użytkownikowi prawa mające sens z biznesowego punktu widzenia. W środowiskach korporacyjnych byty te są przedmiotami znacznej części operacji informatycznych. W dobie bardzo szybkiej informatyzacji przedsiębiorstwa nabywają lub implementują bardzo wiele różnych systemów heterogenicznych, z których każdy często wymaga osobnego utrzymania i administracji. W większości z nich funkcjonują pojęcia konta, profilu lub użytkownika, określające najczęściej jakąś personalizację systemu i zbiór posiadanych przywilejów. Celem, który stawiany jest przed systemami przygotowywania usług jest centralizacja i automatyzacja zarządzania tymi zasobami oraz delegacja części zadań do innych, zewnętrznych systemów. Podyktowane jest to najczęściej koniecznością skrócenia czasu konfigurowania owych aplikacji docelowych, a przez to również duże oszczędności finansowe. Odpowiedzią na rosnące zapotrzebowanie uporządkowania środowisk przygotowywania usług jest Service Provisioning Markup Language (SPML), patrz [1, 2, 3]. Jest to język znaczników wyspecyfikowany przez konsorcjum OASIS, opisujący strukturę najczęściej wykonywanych operacji na pewnych obiektach i zasobach takich jak dodawanie, edycja, usuwanie, wyszukiwanie, czasowe zawieszanie funkcjonowania, przywracanie do działania, wygasanie ważności itd. Struktura ta oparta jest na naturalnym dla sieciowych zastosowań języku XML, którego wykorzystanie jest dosyć powszechne w opisanej pokrótce w pierwszym rozdziale filozofii tworzenia usług sieciowych opartych o architekturę zorientowaną usługowo (ang. Service Oriented Architecture, SOA). Kluczową zaletą specyfikacji SPML jest natomiast to, że opisuje ona nie tylko konstrukcję języka, ale skupia się przede wszystkim na opisie

6 6 samego protokołu komunikacyjnego w opartych o niego usługach. Jest to nie do przecenienia przy projektowaniu i implementacji logiki przepływów danych w korzystających z niego systemach informatycznych. Service Oriented Architecture jest koncepcją tworzenia systemów informatycznych, w której główny nacisk stawia się na definiowanie zestawu usług spełniających wymagania użytkownika. Obejmuje ono techniki organizacyjne oraz integracyjne mające na celu jak najlepsze powiązanie biznesowej strony organizacji z jej zasobami informatycznymi. Dosyć popularnym (choć nieco mylnym) synonimem dla SOA jest Web Services, czyli usługi sieciowe, natomiast konkretnym opisem tego podejścia jest protokół SOAP. Specyfikacja SOAP ta zakłada wysoką przenośność i skalowalność protokołu wymiany informacji. Przesył komunikatów pomiędzy kilkoma systemami stworzonymi teoretycznie w różnych technologiach, odbywa się przy wykorzystaniu języka XML do kodowania danych oraz (najczęściej) protokołu HTTP do ich przenoszenia. SOAP składa się z kilku luźno powiązanych, lecz jednocześnie dobrze dopasowanych warstw specyfikacji formatu wiadomości, wzorców wymiany wiadomości oraz procesów ich modelowania. Te cechy oraz możliwość rozszerzania całego protokołu i jego czysta postać tekstowa sprawiły, że zyskał on olbrzymią popularność i często stanowi podstawę do tworzenia specyfikacji innych technologii. Przykładowymi technologiami opartymi na SOAP i zaimplementowanymi w języku Java są Apache CXF, Apache Axis i Spring WebServices. SOAP jest fundamentalną częścią Enterprise Service Bus (ESB), czyli korporacyjnej szyny usługowej, będącej pierwotnie wierną implementacją specyfikacji Java Business Integration, a od niedawna zaczynającej funkcjonowanie, jako samodzielny termin w branży informatycznej Cel i rezultat pracy Celem teoretycznym niniejszej pracy będzie opis podstawowych właściwości i protokołów języka SPML oraz wskazanie głównych obszarów zastosowań operacji w nim zdefiniowanych. Położony zostanie nacisk na wyjaśnienie wszelkich niejasności i błędów powstałych w samej specyfikacji. Ponadto opisane zostaną podstawy protokołu SOAP opakowującego komunikaty SPML i wykorzystanego w części praktycznej. Celem praktycznym będzie implementacja biblioteki usługowej opartej o SPML na podstawie w/w zasad. Wykorzystane zostaną m.in. biblioteki: Spring, Apache CXF, JaxB, Apache Commons i inne, stanowiące projekty powstałe na licencjach otwartego oprogramowania (ang. open source). Naturalne rozwinięcie części praktycznej będzie stanowił przykład zastosowania utworzonej implementacji w integracji z menedżerem tożsamości systemem Sun Identity Manager (IDM). Jest to aplikacja rozwijana przez firmę Sun Microsystems, której głównymi zadaniami są wspomaganie zarządzania obiektami takimi jak konta użytkowników i powiązanymi z nimi zasobami. Umożliwia ona centralizację części zadań administracyjnych w heterogenicznych systemach informatycznych, propagowanie zmian do wielu systemów jednocześnie, a przez to skrócenie czasu udostępniania i przygotowywania usług. Poprzez architekturę zorientowaną na usługi udostępnia on punkty końcowe dające możliwość zdalnego administrowania nim za pomocą języka SPML. Przykładowa instancja menedżera tożsamości będzie zintegrowana ze źródłem danych, stanowiącym serwer usług katalogowych LDAP.

7 Uwagi ogólne Na rynku brak jest ogólnodostępnych źródeł odnośnie Service Provisioning Markup Language, które w sposób spójny, zorganizowany i daleki od czysto technicznej formy opisywałyby jego właściwości czy też pokazywałyby jego przykładowe sposoby implementacji lub sposoby wykorzystania. Większość zasobów traktujących o SPML stanowią krótkie artykuły w Internecie, blogi i dokumentacje do produktów informatycznych, które w jakimś stopniu robią z niego użytek. Stąd też cała cześć opisowa niniejszej pracy dotycząca tego zagadnienia jest sumą blisko półrocznych doświadczeń i spostrzeżeń wynikających z pracy nad budową usług integracyjnych dla kilkunastu dużych linii lotniczych.

8 8 2. Usługi sieciowe Usługi sieciowe, w świecie informatycznym bardziej znane pod mało precyzyjnym terminem Web Services to grupa specyfikacji stworzonych przez społeczność The World Wide Web Consortium (W3C) w celu ustandaryzowania wymiany wszelkiego rodzaju danych biznesowych poprzez sieć. Standaryzacja ta polega na wykorzystaniu języka XML i jego pochodnych, jako protokołu porządkującego informacje w taki sposób, by posiadały one ujednoliconą strukturę, a przede wszystkim były przenośne pomiędzy jak największą liczbą platform sprzętowych i systemowych. Usługi sieciowe zdefiniowane przez W3C opierają się na takich podstawowych pojęciach jak: SOAP, będący protokołem zdalnego wywoływania dostępu do obiektów jak i specyfikacją opisującą strukturę pojedynczej wiadomości. Web Service Definition Language (WSDL), będący językiem definiującym zestaw tzw. punktów końcowych wraz z usługami przez nie udostępnianymi, wiązaniem ich do stosowanego protokołu wymiany danych oraz opisującym typy tych ostatnich. Extensible Markup Language (XML), rozszerzalny język znaczników, będący bazowym formatem opisującym przesyłane dane. Wyżej wymienione technologie są zarówno bazowymi dla wielu innych protokołów jak i ich składowymi, np. SOAP poprzez JMS, SPML, SAML. Implementacje usług sieciowych stanowią nieodłączną część wielu systemów opartych o pojęcie Enterprise Service Bus czy specyfikację Java Business Integration SOAP W poprzedniej wersji protokołu SOAP było skrótem od Simple Object Access Protocol (prostego protokołu dostępu do obiektów). W aktualnej wersji protokołu SOAP 1.2, wykorzystywanej w środowiskach produkcyjnych, termin SOAP jest pojęciem pierwotnym i nie jest już akronimem. Protokół ten przeznaczony jest do wymiany strukturalizowanych danych w zdecentralizowanych środowiskach rozproszonych. Do zdefiniowania szkieletu danych wykorzystuje on technologię XML, dzięki czemu mogą być one wymieniane poprzez różnorodne protokoły transportowe, a sam zaprojektowany jest tak, by pozostać niezależnym od konkretnego modelu programistycznego czy też innych szczegółów właściwych dla konkretnej implementacji. Specyfikacja SOAP unika definiowania sama w sobie wszelkich niskopoziomowych terminów, takich jak niezawodność, bezpieczeństwo, korelacja, kanał wymiany informacji, czy wzorce wymiany komunikatów (ang. message exchange patterns MEP). W zamian dostarcza dosyć ogólnej charakterystyki samej wymiany danych i ich formatu tak, by wyspecyfikowanie i implementacja wcześniej wspomnianych funkcjonalności była w miarę prosta i nieinwazyjna z punktu widzenia samego protokołu. W szczególności SOAP dostarcza opisów: modelu przetwarzania komunikatów SOAP, modelu rozszerzeń dla protokołu, który definiuje koncepcje w/w modułów i dodatkowych funkcjonalności,

9 9 szkieletu wiązania, który definiuje obsługę różnych protokołów transportowych służących do przesyłu komunikatów, konstrukcji i struktury wiadomości opartej o SOAP. SOAP jest protokołem bezstanowym, opisującym operację działającą w jednym kierunku (oneway), lecz aplikacje mogą z powodzeniem rozbudowywać ten wzorzec o model wysyłania i odbioru lub jeden z wielu innych wzorców wymiany komunikatów (MEP). Jest jednokierunkowy, tzn. opisuje transmisję komunikatu w jedną stronę pomiędzy dwoma węzłami (stronami) biorącymi w niej udział od nadawcy SOAP do odbiorcy SOAP Komunikat SOAP Jak pokazano na Listingu 1, komunikat SOAP ma format dokumentu XML opisywany przez schemat XSD. Głównym elementem (korzeniem) dokumentu jest Envelope, zwany też kopertą, i z reguły zawiera dwa inne węzły - Header i Body. Pierwszy z nich jest nagłówkiem komunikatu, zawierającym metadane go opisujące, natomiast drugi jest jego ciałem, czyli zawiera konkretne dane biznesowe specyficzne dla aplikacji opartej o usługi sieciowe. Listing 1. Przykładowy komunikat SOAP <soapenv:envelope xmlns:soapenv= xmlns:spml= urn:oasis:names:tc:spml:2:0 > <soapenv:header> <wsse:security xmlns:wsse= soapenv:mustunderstand= 1 > <wsse:usernametoken xmlns:wsu= wsu:id= UsernameToken > <wsse:username>xy123456</wsse:username> <wsse:password Type= > abc123</wsse:password> <wsse:nonce>et5rrce4huaxj6z2kqt/bw==</wsse:nonce> <wsu:created> t09:01:32.872z</wsu:created> </wsse:usernametoken> </wsse:security> </soapenv:header> <soapenv:body> <spml:addrequest executionmode= synchronous profile= urn:oasis:names:tc:spml:2:0:profiles:xsd > <User> <username>789554</username> <password>abc123</password>

10 10 <firstname>piotr</firstname> <lastname>sterna</lastname> <organizationcode>sg</organizationcode> <assignedapplications> <application> <shortname>contract Composer</shortName> <version>2008.0</version> </application> </assignedapplications> </User> </spml:addrequest> </soapenv:body> </soapenv:envelope> Jak widać korzeń dokumentu jak i jego dzieci opatrzone są prefiksem soapenv, który należy do przestrzeni nazw Przestrzeń ta zastąpiła wykorzystywaną w wersji SOAP 1.1 i nadal często spotykaną w zastosowaniach produkcyjnych, zwłaszcza w systemach spadkowych. Przestrzeń nazw dla koperty SOAP wraz z elementami, które ta ostatnia może zawierać opisana jest w postaci XSD schematu rozszerzalnego języka znaczników, będących samym w sobie dokumentem XML. Nazewnictwo przestrzeni nazw dla dokumentów mających zastosowanie sieciowe najczęściej stosuje się w przybliżeniu do następującego wzorca: wanego_bytu>/<wersja_specyfikacji>, stąd też wartość W przypadku przestrzeni nazw dla definicji koperty SOAP, sama nazwa przestrzeni jest istniejącym adresem URL, pod którym można znaleźć dokument XSD opisujący wiadomość SOAP. Drugim atrybutem koperty jest zadeklarowanie prefiksu spml dla elementów należących do przestrzeni nazw urn:oasis:names:tc:spml:2:0, która będzie dalej potrzebna dla opisu ciała wiadomości. Należy zauważyć, że ta przestrzeń nazw nie posiada już formatu adresu URL, lecz jest w postaci zunifikowanego formatu nazw zasobów (ang. Uniform Resource Name). Nagłówek komunikatu SOAP Nagłówek komunikatu SOAP jest elementem opcjonalnym. Został on włączony do specyfikacji w celu umożliwienia dodawania do komunikatu informacji, które niekoniecznie stanowią dane ściśle biznesowe i mogłyby zostać umieszczone w jej ciele. Specyfikacja zakłada, że każdy element będący bezpośrednio dzieckiem nagłówka może być przedmiotem osobnego przetwarzania na różnych węzłach, przez które przechodzi wiadomość w trakcie transportu. Mogą być one dodawane, modyfikowane oraz usuwane w drodze poprzez kanał informacyjny, a ponadto są niemal całkowicie transparentne dla samej specyfikacji SOAP. Ciało komunikatu SOAP Ciało komunikatu (ang. payload), czyli jego ładunek użyteczny z czysto-biznesowego punktu widzenia może być generalnie dowolnym dokumentem w formacie XML tak długo, jak jego interpretacja przez odbiorcę jest możliwa. Sposób jego przetwarzania pod kątem biznesowym nie jest zdefiniowany przez specyfikację i pozostaje w gestii konkretnej aplikacji.

11 11 Na Listingu 2 przedstawiono jeszcze raz ciało opisywanego komunikatu. Listing 2. Ciało komunikatu z Listingu 1 <spml:addrequest executionmode= synchronous profile= urn:oasis:names:tc:spml:2:0:profiles:xsd xmlns:business= > <business:user> <business:username>789554</business:username> <business:password>abc123</business:password> <business:firstname>piotr</business:firstname> <business:lastname>sterna</business:lastname> <business:organizationcode>sg</business:organizationcode> <business:assignedapplications> <business:application> <business:shortname>contract Composer</business:shortName> <business:version>2008.0</business:version> </business:application> </ business:assignedapplications > </ business:user> </spml:addrequest> Jak można się domyśleć reprezentuje on żądanie o nazwie addrequest wysłane do pewnej usługi sieciowej w celu dodania jakiegoś użytkownika. Strukturę tego ostatniego w postaci XML opisuje schemat XSD o przestrzeni nazw reprezentowanej przez prefiks business Bezpieczeństwo W przykładzie zamieszczonym na Listingu 1 jedynym elementem nagłówka jest odpowiedzialny za kwestie bezpieczeństwa element Security. Element ten jest zgodny ze specyfikacją Web Services Security: SOAP Message Security 1.1, OASIS, która jest najbardziej znaną koncepcją zabezpieczeń w usługach sieciowych. UsernameToken jest sposobem na załączenie informacji na temat użytkownika wywołującego daną usługę sieciową poprzez wysłanie wiadomości SOAP. Poszczególne elementy-dzieci, które UsernameToken zawiera to: Username symboliczna nazwa danego użytkownika, Password hasło użytkownika w jednym z dwóch dostępnych formatów: o PasswordText może to być zarówno hasło w czystej postaci, jak i wynik jego przetworzenia przez funkcję skrótu, o PasswordDigest może to być hasło w postaci zakodowanej algorytmami takimi jak Base64, SHA lub w postaci kodowanie UTF-8. W kwestii bezpieczeństwa usług sieciowych w oparciu o hasła należy zwrócić uwagę na istotny szczegół. Mianowicie niezależnie od tego, czy typ hasła to PasswordText czy też PasswordDigest, żaden z nich nie jest bezpieczniejszy od drugiego tak długo jak wiadomość przesyłana jest niezabezpieczonym kanałem transportowym. Zawsze istnieje tu możliwość przechwycenia oryginalnej

12 12 wiadomości i podmiany np. jej ciała przy zachowaniu oryginalnej wartości elementu UsernameToken, by złamać system bezpieczeństwa i dokonać potencjalnych szkód w udostępnionym serwisie. By zapobiec takiemu scenariuszowi stosuje się dwa dodatkowe elementy: Nonce specjalny losowo-wygenerowany łańcuch, który powinien być unikatowy dla każdego wywołania usługi, przez co utrudnia ataki poprzez powtórzenie (ang. replay attacks) Created czas utworzenia wiadomości SOAP. Najpierw łączy się te dwa łańcuchy oraz pewne hasło znane w trakcie tworzenia wiadomości, po czym szyfruje się wiadomość stosując funkcję skrótu SHA, a następnie algorytm Base64. Gdy hasło w postaci PasswordDigest jest już załączone do nagłówka można dodatkowo zastosować transport w oparciu o wymianę certyfikatów i protokół Secure Socket Layer. Specyfikacja WS-Security jednoznacznie zaleca, by komunikat SOAP zawierający element UsernameToken bez podelementów Nonce oraz Created był odrzucany, podobnie jak komunikat utworzony wcześniej niż n jednostek czasu temu. Ponadto wartość elementu Nonce powinna być przetrzymywana w pamięci podręcznej systemu usługowego przynajmniej tak długo jak wartość znacznika czasowego przechowywanego w elemencie Created jeszcze nie uległa wygaśnięciu SOAP a pozostałe specyfikacje Jak już wspomniano usługi sieciowe stanowią często część bazową dla innych specyfikacji. W przypadku opisywanym w poprzednich punktach ciało komunikatu SOAP zawiera komunikat w formacie zgodnym ze specyfikacją SPML, służący do dodania pewnego użytkownika. Stąd też drugi atrybut koperty xmlns:spml, deklarujący prefiks dla wiadomości w formacie SPML. Ciało komunikatu SOAP może oczywiście zawierać dowolny dokument, a przez to opakowywać jakąkolwiek inną specyfikację.

13 13 3. Service Provisioning Markup Language Service Provisioning Markup Language (SPML) to w wolnym tłumaczeniu znacznikowy język udostępniania usług. Jest to oparty o język XML protokół wymiany danych opracowany przez konsorcjum OASIS, służący do udostępniania usług korporacyjnych do zarządzania obiektami (najczęściej użytkownikami) oraz szeroko pojętymi zasobami, z których korzystają. Pozwala on na integrację, scalanie i standaryzowanie usług korporacyjnych zarówno na poziomie pojedynczych organizacji jak i pomiędzy nimi. Ponadto wspomaga budowanie spójnych interfejsów usług sieciowych, w których konieczne jest położenie nacisku na automatyzację zarządzaniem zasobami pomiędzy różnymi systemami informatycznymi. SPML oparty jest o tzw. model domenowy, w którym głównymi częściami są: Strona Żądająca (ang. Requesting Authority), zwana dalej w skrócie klientem lub RA, Dostawca Usług (ang. Provisioning Service Provider), zwany dalej Dostawcą lub PSP, Obiekt Zarządzany (ang. Provisioning Service Object), zwany również dalej obiektem PSO, Cel Zarządzany (ang. Provisioning Service Target), zwany dalej Celem, Środowiskiem lub PST. Z racji tego, że powyższe terminy nie posiadają dobrych odpowiedników w języku polskim, dalsza część pracy będzie również, w zależności od kontekstu, korzystać z terminów angielskich oraz ich skrótów Requesting Authority Strona Żądająca to komponent oprogramowania wysyłający żądania zgodne z protokołem SPML do Dostawcy Usług. Przykładowymi stronami żądającymi mogą być: interfejs administracyjny portalu, który wysyła do Dostawcy żądanie utworzenia konta nowego użytkownika w zasobach Aktywnego Katalogu (ang. Active Directory) dla nowego pracownika dużej korporacji; zautomatyzowany serwis usługowy działający w ramach Enterprise Service Bus na serwerze firmy A, który codziennie około godziny 1:00 w nocy synchronizuje dane dotyczące pracowników tej firmy ze swoim kontrahentem firmą B, która ma za zadanie tworzyć dla nich na swoich serwerach konta funkcjonalne, aktualizować dane personalne, wygaszać ważności kont itd. Należy wspomnieć, że w przypadku integracji Business To Business (B2B) pomiędzy Stroną Żądającą a Dostawcą Usług powinna istnieć relacja zaufania. Innymi słowy Dostawca udostępnia ściśle określone usługi Żądającemu na ściśle określonych zasadach. W przypadku dużych projektów informatycznych wymaga to zwykle podpisania umów odnośnie poziomu usług (ang. Service Level Agreement SLA), utworzenia specjalnych kont funkcjonalnych dla Strony Żądającej, przydzielenia im przywilejów poziomych i pionowych, itd. Zagadnienie to jednak wykracza poza ramy niniejszego opracowania.

14 Provisioning Service Provider Provisioning Service Provider, lub też po prostu Dostawca Usług podobnie jak Strona Żądająca jest komponentem oprogramowania nasłuchującym nowych żądań (lub też komunikatów) w formacie SPML, interpretującym je, wykonującym stosowne dla nich operacje oraz zwracającym odpowiedzi do nadawcy. Przykładem Dostawcy może być instancja systemu zarządzającego tożsamościami i zasobami, jak np. Sun Identity Manager Provisioning Service Target Provisioning Service Target, zwany też Celem lub Środowiskiem, reprezentuje pewien abstrakcyjny z punktu widzenia specyfikacji SPML byt biznesowy udostępniony przez Dostawcę. Środowiskiem mogą być np. system informatyczny lub grupa systemów informatycznych. Rzadziej tę funkcję spełniają systemy bazodanowe lub usługi katalogowe takie jak LDAP czy Active Directory, chociaż, co ważne, są one tak naprawdę składnicami danych, które Dostawca wykorzystuje do tworzenia, odczytu, modyfikacji lub usuwania niskopoziomowych informacji biznesowych, takich jak numer telefonu lub adres . Różnica pomiędzy Celem a Dostawcą jest taka, że drugi z nich w ramach komunikatu wysłanego przez Żądającego wykonuje pewne operacje na tym pierwszym. Cel możemy również definiować jako kontener, którym Dostawca zarządza, czyli tak naprawdę jako grupę obiektów, na których wykonywane są pewne operacje. Paradygmatem SPML jest to, że Dostawca udostępnia przynajmniej jeden Cel, którym Żądający może zarządzać. W praktyce, jak ma to miejsce np. w Sun Identity Manager, jeden Dostawca udostępnia tylko jeden Cel. Można domniemywać, że jest to przede wszystkim związane z niechęcią do wprowadzania zbyt dużego stopnia komplikacji systemów informatycznych. Dochodzi do tego doza niejasności w samej specyfikacji SPML. Nie definiuje ona wystarczająco precyzyjnie następujących kwestii: jak powinno się grupować obiekty, by stanowiły logiczne Środowisko, jakie typy obiektów można grupować ze sobą, jakie mogą być zależności pomiędzy obiektami zarówno w jednym Środowisku jak i pomiędzy kilkoma różnymi itd. Bezpośrednio na Celach, jako abstrakcyjnych bytach nie można wykonywać żadnych operacji takich jak dodawania, modyfikacja lub usuwanie. Z punktu widzenia Żądającego Cel sam w sobie jest tylko do odczytu. Musi on mieć również unikalny identyfikator w obrębie Dostawcy, który udostępnia operacje na jego obiektach Obiekty zarządzane (PSO) Każdy Cel może zawierać dowolną liczbę obiektów zarządzanych, na których Żądający może wykonywać operacje. Obiekt Zarządzany w odróżnieniu od Celu jest konkretnym bytem (lub też encją), stanowiącym przedmiot wykonywania wszelkich działań przez Żądającego. Opisywany jest zwykle przez pewien schemat opisujący jego strukturę XML i przestrzeń nazw.

15 15 Każdy obiekt zarządzany musi mieć unikalny identyfikator w obrębie Celu, w którym się znajduje Struktura obiektów zarządzanych Schemat każdego Celu musi definiować strukturę XML obiektów, które zawiera. Nie musi on zawierać określonego formatu, chociaż najczęściej spotyka się jego deklarację w formacie XSD. Każdy schemat musi zawierać przestrzeń nazw opisującą dany obiekt zarządzany. Wskazuje ona, w jaki sposób należy interpretować zarówno sam schemat jak i obiekt zarządzany przez niego opisywany. Wszelkie zmiany danych w pojedynczym PSO nie mogą wykraczać poza przyjętą dla niego strukturę wynikającą ze schematu. Innymi słowy, jeżeli dla danego PSO wymagana jest obecność pewnego elementu, a dodatkowo element ten ma być typu X, to niedozwolone jest ani usuwanie tego elementu wskutek operacji wykonywanej przez Żądającego, ani przechowywanie w tym elemencie danych typu innego niż X. Oczywistym jest również, że sam schemat PSO z punktu widzenia Żądającego jest tylko do odczytu. Modyfikacje w nim mogą być wprowadzane przez administratorów lub programistów odpowiedzialnych za Dostawcę. Dobre praktyki projektowania jednak odradzają zmieniać istniejącą jego definicję, zwłaszcza w produkcyjnej fazie projektu. Tym bardziej jest to niezwykle ryzykowne, gdy Dostawca obsługuje Żądających należących do innych, zewnętrznych organizacji, które być może zdążyły już dostosować swoje systemy informatyczne do aktualnej struktury PSO. Doświadczenie pokazuje, że ewentualne zmiany w schemacie mogą się sprowadzać głównie do dodawania nowych elementów i atrybutów, przy czym najlepiej by były one opcjonalne Profile SPML SPML definiuje 2 tzw. profile umożliwiające wymianę danych pomiędzy Dostawcą a Żądającym. Są to: XSD, zdefiniowany w ramach specyfikacji SPMLv2 XSD Profile oraz DSML, zdefiniowany w ramach specyfikacji SPMLv2 DSMLv2 Profile. Różnią się one formatem przesyłanych danych, zakresem obsługiwanych operacji oraz docelowymi źródłami danych i środowiskami, na których operują. DSMLv2 został stworzony głównie do operacji wykonywanych na wszelkiego rodzaju usługach katalogowych opartych o LDAP, natomiast profil XSD najlepiej sprawdza się w operacjach na celach będących usługami sieciowymi. Jako że część praktyczna niniejszej pracy opiera się w znacznej mierze o usługi sieciowe oparte o architekturę zorientowaną usługowo (SOA), opis teoretyczny skupi się głównie na profilu opartym o schemat XSD. Profil DSML został wykorzystany w przykładzie integracji projektowanej autorskiej implementacji SPML z systemem Sun Identity Manager. Dokładny opis profili SPML można znaleźć w [2,3].

16 Model żądania i odpowiedzi Wspomniano już, że bazowym założeniem przepływu danych w protokole SPML jest to, że pewien Klient wysyła komunikat do Dostawcy, by ten ostatni wykonał jakąś operację. Sytuację taką przedstawiono na Diagramie 1. Diagram 1. Uproszczony model żądania i odpowiedzi w SPML Klient Dostawca RequestType ResponseType Żądający wysyła do Dostawcy żądanie zgodne z formatem SPML opisujące operację, która ma zostać wykonana. Dostawca następnie interpretuje żądanie i jeżeli jest ono poprawne z semantycznego punktu widzenia, to wykonuje wszelkie działania związane z tą operacją. Pod koniec Dostawca zwraca Żądającemu komunikat zwrotny zawierający zawsze status wykonanej operacji, opis ewentualnych napotkanych błędów oraz, w zależności od rodzaju wykonywanej operacji, jakieś dodatkowe dane biznesowe. Zarówno wszystkie rodzaje żądań jak i wszystkie rodzaje odpowiedzi w języku SPML opisane są przez schemat XSD. Mają one strukturę hierarchiczną i oparte są na dziedziczeniu z dwóch podstawowych elementów: RequestType ResponseType Deklarację typu RequestType przedstawiono na Listingu 3. Listing 3. Definicja typu RequestType <complextype name= RequestType > <complexcontent> <extension base= spml:extensibletype > <attribute name= requestid type= xsd:id use= optional /> <attribute name= executionmode type= spml:executionmodetype use= optional /> </extension> </complexcontent> </complextype> Jak widać każde żądanie może zawierać opcjonalny identyfikator requestid oraz opcjonalny tryb wykonania executionmode.

17 17 Listing 4 zawiera deklarację typu ResponseType. Listing 4. Definicja typu ResponseType <complextype name= ResponseType > <complexcontent> <extension base= spml:extensibletype > <sequence> <element name= errormessage type= xsd:string minoccurs= 0 maxoccurs= unbounded /> </sequence> <attribute name= status type= spml:statuscodetype use= required /> <attribute name= requestid type= xsd:id use= optional /> <attribute name= error type= spml:errorcode use= optional /> </extension> </complexcontent> </complextype> Odpowiedź w formacie SPML powinna zawierać status wykonanej operacji: success, czyli informacja o tym, że została ona pomyślnie wykonana failure, czyli informacja o niepomyślnej próbie wykonania operacji, pending, czyli informacja o tym, że operacja nadal jest wykonywana. Sposób informowania o niepowodzeniu operacji jest pierwszym przykładem niekonsekwencji i redundancji. Mianowicie oprócz jej statusu zwracany jest dodatkowo ewentualny kod błędu - error, jaki wystąpił po stronie dostawcy oraz opcjonalna lista szczegółowych informacji o jego przyczynach errormessage. Status operacji jest tutaj jakoby nadmiarowy w celu poinformowania o błędach lub ich braku można by skorzystać wyłącznie z kodu błędu i ewentualnie z listy szczegółowych komunikatów. W takim przypadku status pending możnaby zastąpić atrybutem o tej nazwie i ewentualnie ustawiać go na wartość logiczną true lub false. Doświadczenie pokazuje, że lista informacji o błędach bywa wykorzystywana jako lista ostrzeżeń lub dodatkowych komunikatów interpretowalnych przez człowieka, które dostawca chciał zawrzeć w ramach wykonywania danego żądania. W takiej sytuacji status odpowiedzi może być oznaczony jako pomyślny, a kod błędu wcale nie musi być ustawiony Kody błędów Błędy wykonania operacji wywołanej przez żądanie SPML opisywane są przez zestaw kodów reprezentujących ogólne, przewidziane przez specyfikację przypadki. Należą do nich: malformedrequest, oznaczający, że Dostawca nie mógł w żaden sposób zinterpretować żądania, czyli że np. wystąpił błąd w jego parsowaniu, unsupportedoperation, oznaczający, że Dostawca nie wspiera danej operacji, unsupportedidentifiertype, oznaczający, że Dostawca nie wspiera danego identyfikatora PSO, nosuchidentifier, oznaczający, że w obrębie Celu nie istnieje PSO o danym identyfikatorze,

18 18 unsupportedexecutionmode, oznaczający, że Żądający usiłuje wykonać daną operację w trybie, w którym nie jest ona wspierana, invalidcontainment, oznaczający, ze Dostawca nie może dodawać żadnych obiektów PSO do danego kontenera, resultsettoolarge, oznaczający, że Dostawca nie może zwrócić całego zestawu danych uzyskanych w ramach danej operacji, unsupportedprofile, mający zastosowanie tylko w przypadku próby pobrania listy celów obsługiwanych przez Dostawcę i oznaczający, że profil, który podał Żądający nie jest przez Dostawcę obsługiwany, invalididentifier, mający zastosowanie tylko i wyłącznie w operacji dodawania nowego PSO i oznaczający, że podany identyfikator jest niepoprawny, alreadyexists, mający zastosowanie tylko i wyłącznie w operacji dodawania nowego PSO i oznaczający, że PSO o podanym identyfikatorze już istnieje i nie może zostać utworzony, customerror, oznaczający, że dostawca napotkał na błąd niepasujący do żadnego z w/w kodów, więc zwraca tzw. błąd szczególny. Interesującym przypadkiem jest tu kod błędu unsupportedoperation. Poza tą informacją w specyfikacji brak jest jakichkolwiek danych o jego wykorzystaniu. Jednocześnie specyfikacja wymusza, by informacja o wspieraniu danej funkcjonalności pociągała za sobą konieczność implementacji wszystkich operacji, które ona zawiera. Oznacza to, że wykorzystanie kodu unsupportedoperation i wspomniany warunek nawzajem się wykluczają Tryby wykonywania operacji W protokole SPML istnieją 2 tryby wykonywania operacji synchroniczny i asynchroniczny. Tryb synchroniczny oznacza, że operacja zostanie najpierw wykonana, a dopiero później do żądającego zostanie wysłany komunikat zwrotny, czyli odpowiedź. W takim przypadku Dostawca może natychmiast po zakończeniu operacji poinformować o ewentualnych zaistniałych błędach. Z trybem asynchronicznym mamy do czynienia wtedy, gdy Dostawca tuż po odebraniu żądania odsyła odpowiedź do klienta. W takiej sytuacji oczywiście komunikat zwrotny nie będzie zawierał żadnych informacji o błędach, gdyż nie zostały one jeszcze napotkane. Będzie natomiast zawierał status o nazwie pending, czyli informację o tym, że operacja jest albo w kolejce i będzie przez pewien czas oczekiwała na wykonanie albo właśnie jest wykonywana. Dodatkowo do odpowiedzi zostanie dołączony identyfikator żądania, który będzie w przyszłości służył do sprawdzenia jego stanu za pomocą operacji z zestawu Async. W gestii Dostawcy leży przechowywanie wyników wszystkich operacji wraz z identyfikatorami żądań, których były częścią. Tryb wykonania żądania może zostać pominięty w jego ciele, wtedy decyduje o nim implementacja operacji implementowanej przez Dostawcę. Jeżeli natomiast Klient wyśle żądanie z trybem, który nie jest dla danej operacji obsługiwany, to zostanie mu zwrócona odpowiedź z błędem unsupportedexecutionmode Grupowanie żądań W przypadku, gdy dostawca określi, że wspiera zadania z grupy Bulk lub operacje z grupy Batch, klient ma możliwość wykonywania wielu operacji za pomocą pojedynczego żądania.

19 19 Gdy grupowanych jest kilka operacji w ramach zestawu Bulk można tą samą operację wykonać jednocześnie na wielu różnych obiektach zarządzanych. Jeżeli następuje zgrupowanie operacji w ramach zestawu Batch można wykonać wiele różnych operacji na wielu różnych obiektach zarządzanych. Najczęściej pojedyncze żądanie dotyczy pojedynczej operacji, lecz w przypadku, gdy chce się osiągnąć pewnego rodzaju transakcyjność lub utrzymać kolejność wywołania operacji w trybie asynchronicznym, warto pomyśleć o zaimplementowaniu operacji Bulk lub Batch Operacje Każde Środowisko może definiować obsługę jednego lub więcej zestawów operacji, zwanych również funkcjonalnościami, które można wykonać na obiektach zarządzanych. Każdy zestaw to zbiór logicznie powiązanych ze sobą akcji. Do zestawów operacji przedstawionych na Diagramie 2 należą: Core capability, czyli zestaw podstawowy udostępniający operacje takie jak: o listtargets zwracanie listy celów obsługiwanych przez Dostawcę, o lookup wyszukiwanie danego PSO, o add dodawanie nowego PSO, o modify modyfikowanie istniejącego PSO, o delete usuwanie istniejącego PSO; Password capability, czyli operacje takie jak: o setpassword ustawianie hasła dla PSO, o resetpassword resetowanie hasła dla PSO, o expirepassword wygaszanie ważności hasła dla PSO, o validatepassword walidacja, czy hasło podane dla PSO jest poprawne pod kątem strukturalnym; Suspend capability, czyli operacje takie jak: o suspend zawieszanie funkcjonowania PSO, o resume przywracanie funkcjonowania PSO, o active sprawdzanie czy PSO jest niezawieszony; Search capability, czyli operacje takie jak: o search wyszukiwanie PSO wg określonych kryteriów, o iterate iterowanie po grupie obiektów PSO zwróconych przez operację wyszukiwania, o closeiterator zamykanie iteratora; Async capability, czyli operacje takie jak: o status sprawdzenie statusu operacji aktualnie wykonywanych w trybie asynchronicznym, o cancel anulowanie aktualnie wykonywanej operacji; Bulk capability, czyli operacje takie jak: o bulkmodify wykonywanie jednej operacji modyfikacji na wielu obiektach PSO jednocześnie, o bulkdelete wykonywanie jednej operacji usuwania wielu obiektów PSO jednocześnie; Batch capability, czyli operacje takie jak: o batch wykonywanie wielu różnych operacji jednocześnie na jednym lub wielu obiektach PSO; Updates capability, czyli operacje umożliwiające: o updates pobranie listy operacji wszelkiego rodzaju modyfikacji PSO,

20 20 o iterate iterowanie na w/w liście, o closeiterator zamknięcie iteratora; Reference capability, czyli niestandardową konfigurację deklarującą relacje pomiędzy różnymi obiektami PSO. Diagram 2. Funkcjonalności i operacje SPML core password suspend search listtargets setpassword suspend search lookup resetpassword resume iterate add validatepassword active closeiterator modify expirepassword delete Operacje SPML reference async bulk updates batch status bulkmodify updates batch cancel bulkdelete iterate closeiterator

21 21 Dostawca może zadeklarować, które funkcjonalności są dostępne dla danych typów obiektów na danych Celach. Np. zwykle wygasanie hasła dla obiektu odnosi się do obiektów użytkowników, rzadziej dla organizacji czy właściwie wcale dla produktów. Funkcjonalności Core, Password i Suspend są przedmiotem części praktycznej tego opracowania, stąd też zostaną one szczegółowo opisane w dalszych sekcjach. Pozostałe funkcjonalności znacznie wykraczają poza podstawowy zakres zarządzania usługami korporacyjnymi, toteż zostaną pominięte Funkcjonalności Podstawowe - Core W skład funkcjonalności podstawowych SPML wchodzą operacje: pobierania listy Celów od Dostawcy, dodawania nowego PSO, modyfikowania istniejącego PSO, usuwania istniejącego PSO oraz wyszukiwania istniejącego PSO. Operacje te zawarte są w głównej przestrzeni nazw specyfikacji SPML - urn:oasis:names:tc:spml:2:0. W następnych sekcjach zostaną opisane ich podstawowe założenia. listtargets wypisanie listy celów Strona Żądająca dowiaduje się na jakich Środowiskach może wykonywać operacje za pośrednictwem jednego z komunikatów SPML, który żąda od Dostawcy zwrócenia listy wszystkich Celów, którymi Żądający może teoretycznie zarządzać. Razem z każdym Celem obsługiwanym przez dostawcę zwracany jest także profil protokołu, którego można używać do zarządzania Celem oraz lista funkcjonalności, które są przez ten Cel wspierane. Na Listingu 5 umieszczono deklarację typu żądania dla operacji listtargets. Listing 5. Deklaracja typu ListTargetsRequest <complextype name= ListTargetsRequestType > <complexcontent> <extension base= spml:requesttype > <attribute name= profile type= anyuri use= optional /> </extension> </complexcontent> </complextype> Powyższe żądanie może zawierać tylko jeden parametr atrybut profile, wskazujący, że mają być zwrócone tylko instancje Celów obsługiwane przez dany profil. Profile opisywane są przez następujące przestrzenie nazw: urn:oasis:names:tc:spml:2:0:profiles:xsd urn:oasis:names:tc:spml:2:0:profiles:dsml. Żądanie to nie może być asynchroniczne z dwóch powodów. Po pierwsze w chwili jego wykonania jeszcze nie wiadomo, które z Celów wspierają funkcjonalność Async, po drugie to właśnie do tej metody

22 22 należy sprawdzenie, które z Celów zawierają tę funkcjonalność. Jej asynchroniczne wywołanie nie miałoby więc sensu. Na Listingu 6 umieszczono deklarację typu odpowiedzi dla operacji listtargets. Listing 6. Deklaracja typu ListTargetsResponse <complextype name= ListTargetsResponseType > <complexcontent> <extension base= spml:responsetype > <sequence> <element name= target type= spml:targettype minoccurs= 0 maxoccurs= unbounded /> </sequence> </extension> </complexcontent> </complextype> Jak widać dziedziczy ona po ResponseType i dodatkowo składa się z sekwencji elementów opisujących Cel, typu TargetType. Jeżeli żądanie zawiera nazwę profilu, którego Dostawca nie wspiera, to zwrócony zostaje komunikat o statusie oznaczającym niepowodzenie z kodem błędu unsupportedprofile. Należy zauważyć, że listtargets jest zwykle pierwszą operację wykonywaną na systemie docelowym udostępniającym usługi oparte o SPML. Dzieje się tak nie tylko ze względu na konieczność poznania listy obsługiwanych celów. Spowodowane jest to również koniecznością wykonania jakiegoś rodzaju logowania u Dostawcy i utworzenia sesji, której identyfikator będzie następnie przesyłany w wymianie komunikatów, który później będzie miał miejsce pomiędzy Klientem a Dostawcą. W ten sposób jest to zaimplementowane w system Sun Identity Manager, przy czym jak się później okaże w tym celu wysyłane jest żądanie zgodne z profilem DSMLv2, a nie XSD. lookup wyszukiwanie danego obiektu PSO Operacja lookup umożliwia stronie żądającej pobranie dokumentu XML opisującego pewien wybrany obiekt zarządzany. Poza elementem identyfikującym wyszukiwany obiekt PSO i atrybutem returndata, określającym zakres zwracanych danych, komunikat żądania LookupRequestType dla tej operacji nie zawiera niczego szczególnego. Komunikat zwrotny LookupResponseType natomiast zawiera wyłącznie obiekt typu PSOType, opakowujący konkretny dokument reprezentujący obiekt zarządzany. Operacja ta ma swój zaawansowany odpowiednik w funkcjonalności Search. add dodawanie nowego obiektu zarządzanego Operacja dodawania umożliwia klientowi utworzenie w Środowisku nowego obiektu zarządzanego (PSO). Operacja ta może sprowadzać się np. do utworzenia nowego rekordu w bazie danych i ewentualnie powiązania go z istniejącymi rekordami jakimiś więzami integralności. Jeżeli obiektami zarządzanymi są użytkownicy to może to oznaczać dodanie dodatkowo nowego wpisu w usłudze katalogowej. Uaktualnianie kilku źródeł danych (zasobów) jednocześnie jest bardzo powszechne we wszelkiego typu systemach korporacyjnych, gdzie baza danych przechowuje szczegółowe dane użytkownika takie jak

23 23 imię, nazwisko, adres , rok urodzenia, adres, zarobki itd., a usługa katalogowa przechowuje nazwę użytkownika i hasło. Jeżeli ta ostatnia jest np. Aktywnym Katalogiem opartym o system Windows, służy ona zazwyczaj do uwierzytelniania użytkownika w momencie logowania do domeny firmowej. Użytkownik ten zazwyczaj uzyskuje wtedy dostęp do innych zasobów, takich jak zdalne napędy, drukarki, itp. W przypadku korzystania z usług innych dostawców, np. Sun Directory Server, mamy możliwość zintegrowania ich z przeróżnymi bibliotekami odpowiadającymi za bezpieczeństwo, np. Spring Security lub nawet z całymi systemami zarządzania dostępem i tożsamością, takimi jak Sun Identity Manager lub Sun Directory Server. Na Listingu 7 przedstawiono deklarację elementu żądania add. Listing 7. Deklaracja typu AddRequest <complextype name= AddRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype minoccurs= 0 /> <element name= containerid type= spml:psoidentifiertype minoccurs= 0 /> <element name= data type= spml:extensibletypecustom /> <element name= capabilitydata type= spml:capabilitydatatype minoccurs= 0 maxoccurs= unbounded /> </sequence> <attribute name= targetid type= string use= optional /> <attribute name= returndata type= spml:returndatatype use= optional default= everything /> </extension> </complexcontent> </complextype> Typowe żądanie dodania nowego obiektu PSO składa się zasadniczo z 3ch części. Należą do nich przede wszystkim: element psoid, będący identyfikatorem obiektu, który ma zostać utworzony, element containerid, reprezentujący istniejący obiekt, w którym ma zostać osadzony tworzony obiekt PSO, element data, opakowujący konkretny dokument XML reprezentujący nowy obiekt zarządzany. Najczęściej spotykany przepływ danych w przypadku wywoływania operacji add wygląda następująco. 1. Klient wysyła żądanie dodania nowego PSO w celu określonym przez identyfikator targetid 2. Dostawca odbiera żądanie, sprawdza czy identyfikator targetid istnieje, jeżeli istnieje, to przechodzi dalej. 3. Dostawca sprawdza, czy identyfikator psoid jest aktualnie przypisany do istniejącego celu. Jeżeli jest, to zostaje zwrócony kod błędu alreadyexists. Jeżeli nie jest, to przechodzi dalej.

24 24 4. Dostawca sprawdza, czy identyfikator psoid ma poprawną konstrukcję. Jeżeli nie ma, to zwracany jest kod błędu invalididentifier lub unsupportedidentifiertype. 5. Zostaje przeanalizowana zawartość elementu data. Musi on zawierać poprawny dokument XML zawierający dane nowego obiektu PSO. Dokument ten musi być zgodny ze schematem XSD wspieranym przez danych cel. Schemat ten, jeżeli jest wspierany dla danego celu, to powinien być również zwracany przez operację listtargets. Jeżeli zawartość elementu data nie jest zgodna z żadnym wspieranym schematem, to zostaje zwrócony kod błędu malformedrequest. Podobnie ma się rzecz w przypadku, gdy elementu data nie można sparsować. 6. Dokument opisujący obiekt PSO ulega deserializacji i następuje jego walidacja pod kątem poprawności danych biznesowych, np. czy imię użytkownika nie zawiera niedozwolonych znaków lub hasło jest wystarczająco bezpieczne. Jeżeli walidacja się nie powiedzie, zostaje zwrócony kod błędu customerror. 7. Następuje próba utworzenia nowego PSO we docelowych źródłach danych. Jeżeli któraś z tych operacji się nie powiedzie, to zostaje zwrócony kod błędu customerror. 8. Klient otrzymuje komunikat zwrotny, który w zależności od zawartości atrybutu returndata otrzymanego w żądaniu, może zawierać: sam identyfikator utworzonego obiektu identifier, dane podstawowe utworzonego obiektu data, dane podstawowe uzupełnione o dane o tzw. dane funkcjonalne everything. Oczywiście w przypadku, gdy któraś z powyższych faz zakończy się zwróceniem kodu błędu, to przetwarzanie żądania jest przerywane, odpowiednie zasoby są w miarę możliwości przywracane do stanu poprzedniego, a lista błędów zawiera opcjonalne szczegółowe komunikaty odnośnie przyczyn nieudanej operacji. Specyfikacja operacji add pozostawia wiele do życzenia. Po pierwsze niezrozumiałe jest to, że jako jedyna operacja w SPML dla nieprawidłowego identyfikatora psoid zwraca invalididentifier, podczas gdy wszystkie inne powinny zwracać unsupportedidentifiertype. Po drugie nie jest do końca jasne, w jaki sposób powinny być interpretowane ewentualne identyfikatory zawarte w dokumencie XML opisującym nowy obiekt PSO. Na Listingu 8 pokazano przykładową zawartość całego żądania wraz z zawartym opisem nowego obiektu zarządzanego zawartym w elemencie User. Listing 8. Przykładowy dokument opisujący obiekt PSO <urn:addrequest returndata= everything xmlns:urn= urn:oasis:names:tc:spml:2:0 > <urn:psoid ID= User/sg ></urn:psoid> <urn:data> <ns5:user xmlns:ns5= > <ns5:username>jkowal</ns5:username> <ns5:password>abc123</ns5:password> <ns5:companycode>sg</ns5:companycode> <ns5:firstname>jan</ns5:firstname> <ns5:lastname>kowalski</ns5:lastname> </ns5:user> </urn:data> </urn:addrequest>

25 25 Jak się można domyśleć, element Username zawiera nazwę użytkownika, która teoretycznie powinna być wykorzystana do stworzenia nazwy pewnego konta. Jednocześnie jednak element psoid zawiera całkiem inny identyfikator obiektu niż ten zawarty w samym dokumencie PSO. Chociaż specyfikacja tego jednoznacznie nie określa, to wszędzie gdzie to możliwe bezpieczniejsze jest korzystanie z identyfikatora psoid. Jest on jakoby niezależny od danych biznesowych i dostarcza identyfikacji obiektu na poziomie samego Celu, czyli na poziomie samego Środowiska udostępnianego przez Dostawcę. modify modyfikacja obiektu zarządzanego Z samej swojej definicji obiekt zarządzany nie jest oczywiście elementem niezmiennym i czasami istnieje konieczność uaktualnienia jego właściwości. Ma to miejsce np. wtedy, gdy jest nim użytkownik, który zmienił adres , numer telefonu lub któremu trzeba przypisać rolę administratora w systemie informatycznym X, stanowiącym część Środowiska zarządzanego przez Dostawcę. Operacja modyfikacji jest operacją najtrudniejszą do zaimplementowania ze względu na mnogość wszelkich możliwych przypadków użycia oraz odpowiedni protokół SPML, który trzeba zastosować. Na Listingu 9 umieszczono deklarację żądania modyfikacji. Listing 9. Deklaracja typu ModifyRequestType <complextype name= ModifyRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype /> <element name= modification type= spml:modificationtype maxoccurs= unbounded /> </sequence> <attribute name= returndata type= spml:returndatatype use= optional default= everything /> </extension> </complexcontent> </complextype> Pojedyncze żądanie modyfikacji może odnosić się tylko do jednego obiektu PSO. Jest on identyfikowany za pomocą elementu psoid. Żądanie modyfikacji może zawierać wiele różnych konkretnych modyfikacji danego PSO. Konkretna modyfikacja, opisywana przez element modification ma postać przedstawioną na Listingu 10. Listing 10. Deklaracja typu ModificationType <complextype name= ModificationType > <complexcontent> <extension base= spml:extensibletype > <sequence> <element name= component type= spml:selectiontype minoccurs= 0 />

26 26 <element name= data type= spml:extensibletype minoccurs= 0 /> <element name= capabilitydata type= spml:capabilitydatatype minoccurs= 0 maxoccurs= unbounded /> </sequence> <attribute name= modificationmode type= spml:modificationmodetype use= optional /> </extension> </complexcontent> </complextype> Konkretna modyfikacja składa się z: zapytania zawartego w elemencie component, będącego selekcją fragmentu dokumentu PSO, który chcemy zmodyfikować, nowej wartości elementu, który chcemy zmodyfikować, zawartej w elemencie data, opcjonalnych danych funkcjonalności wspieranych przez dany obiekt PSO, zawartych w elementach capabilitydata, oraz tzw. trybu modyfikacji, reprezentowanego przez atrybut modificationmode. Selekcja fragmentu dokumentu obiektu zarządzanego jest wyrażona w języku zapytań interpretowalnym zarówno przez Klienta jak i Dostawcę. Ponieważ przedmiotem zapytania jest istniejący obiekt PSO, a ten z reguły można pobrać ze Środowiska i przedstawić za pomocą XML, to wykorzystanym językiem zapytań w takim przypadku mogą być XPath lub XQuery. Dostępne są trzy tryby modyfikacji: add dodawanie nowego elementu do obiektu zarządzanego, replace podmiana istniejącego elementu w obiekcie zarządzanym, delete usunięcie istniejącego elementu w obiekcie zarządzanym. Nowa wartość opisywana przez element data wykorzystywana jest tylko i wyłącznie w przypadku trybów dodawania nowego elementu do obiektu zarządzanego add lub podmiany fragmentu danych tego obiektu replace. Operacje modyfikacji w trybie delete nie powinny zawierać elementu data, a jeżeli został on zawarty w jakiejś konkretnej modyfikacji tego żądania, powinny go zignorować lub zwrócić kod błędu malformedrequest lub customerror. Na Listingu 11 podano przykład żądania modyfikacji obiektu PSO, w którym selekcja wyszukuje za pomocą języka XPath element FirstName, a element data zawiera element, który powinien ów element FirstName zastąpić. Listing 11. Przykładowy komunikat modyfikacji obiektu zarządzanego <urn:modifyrequest xmlns:urn= urn:oasis:names:tc:spml:2:0 xmlns:ns5= > <urn:psoid ID= User/sg targetid= PJWSTK /> <urn:modification modificationmode= replace > <urn:component namespaceuri= path=./u:firstname > <namespaceprefixmap namespace= prefix= u />

27 27 </component> <urn:data> <ns5:firstname xmlns= >Marek </ns5:firstname> </urn:data> </urn:modification> </urn:modifyrequest> W wyniku powyższego żądania imię użytkownika o identyfikatorze User/sg123456, który jest obiektem zarządzanym w Celu o nazwie PJWSTK zostanie zmienione na Marek. Należy zwrócić uwagę na fakt, że każdy nowy element dodawany do obiektu PSO lub będący zamiennikiem dla uaktualnianego elementu powinien mieć określoną przestrzeń nazw, która jest zgodna z przestrzenią nazw dokumentu opisującego PSO. Na Listingu 12 podano przykładowy komunikat zwrotny dla żądania modyfikacji. Listing 12. Przykładowy komunikat zwrotny dla żądania modyfikacji obiektu zarządzanego <urn:modifyresponse requestid= c29cffb5-9e8c-4f0f d3ae1a067e status= success xmlns:urn= urn:oasis:names:tc:spml:2:0 xmlns:ns5= > <urn:pso> <urn:psoid ID= User/sg targetid= PJWSTK /> <urn:data> <ns5:user> <ns5:username>jkowal</ns5:username> <ns5:password>abc123</ns5:password> <ns5:companycode>sg</ns5:companycode> <ns5:firstname>marek</ns5:firstname> <ns5:lastname>kowalski</ns5:lastname> </ns5:user> </urn:data> </urn:pso> </urn:modifyresponse> Jak widać odpowiedź zawiera status success, czyli informuje o pomyślnym wykonaniu operacji. Głównym elementem odpowiedzi jest element pso oznaczony identyfikatorem User/sg Zawiera on również element data wraz z uaktualnionym dokumentem opisującym zmodyfikowany obiekt PSO. W przypadku, gdy Środowisko sprowadza się do zarządzania systemem usług katalogowych, istnieje pokusa identyfikowania obiektu PSO (czyli elementu psoid) jako ścieżki kwalifikowanej do odpowiadającego mu wpisu we wspomnianej usłudze. Dajmy na to dane użytkownika o nazwie pj123456, należącego do organizacji PJWSTK, pracującego w dziale IT przechowywane są pod adresem wskazywanym przez tzw. nazwę kwalifikowaną uid=pj123456, o=it, dc=pjwstk, dc=edu. Z założeń protokołu LDAP ścieżka ta jest unikalna, przez co sama nazwa kwalifikowana użytkownika jest unikalna. Dlaczego więc nie można by się posłużyć tą ścieżką do reprezentowania całego obiektu zarządzanego w obrębie Środowiska? Otóż specyfikacja SPML zaleca by identyfikator obiektu PSO pozostawał niezmienny tak długo jak Strona Żądająca w ramach pojedynczej sesji wymiany danych protokołem SPML korzysta z owego identyfikatora. W przypadku, gdyby użytkownik pj przeniósł się z działu

28 28 IT do działu księgowego, to jego identyfikator zmieniłby się na uid=pj123456, o=finance, dc=pjwstk, dc=edu. Jednak gdyby jakiekolwiek encje w systemie aktualnie odnosiły się do tego użytkownika poprzez identyfikator PSO o wartości uid=pj123456, o=it, dc=pjwstk, dc=edu (czyli do nieaktualnej nazwy kwalifikowanej), mogłoby teoretycznie dojść do powstania błędów, niespójności danych, a w skrajnych przypadkach nawet naruszenia systemu bezpieczeństwa. Z tego względu najlepszym rozwiązaniem w takim przypadku jest stworzenie globalnego, niezmiennego identyfikatora, który nie będzie w znikomym stopniu zależał od zmian w zarządzanych zasobach i źródłach danych. Istotną kwestią dotyczącą operacji modify jest to, że z reguły nie powinna ona umożliwiać modyfikacji elementów takich jak hasło użytkownika, gdyż logika z tym związana powinna być zawarta w operacji setpassword stanowiącej część funkcjonalności Password. W tym przypadku mówiąc o haśle użytkownika mamy na myśli to, które odnosi się do biznesowej semantyki użytkownika w samym zarządzanym Środowisku i systemach informatycznych bezpośrednio przez nie zarządzanych. Hasło zwykle w takim przypadku ma i z reguły powinno mieć tą samą wartość w obrębie wszystkich podsystemów Środowiska. delete usuwanie obiektu zarządzanego Usuwanie obiektu PSO odbywa się przy wykorzystaniu operacji delete. Jest to jednocześnie ostatnia operacja z grupy funkcjonalności podstawowych Core. Operacja ta ma za zadanie usunąć wpisy dotyczące reprezentujące obiekt PSO ze wszystkich zasobów zarządzanych w ramach danego Celu. Na Listingu 13 umieszczono deklarację typu żądania usunięcia obiektu zarządzanego. Listing 13. Deklaracja typu DeleteRequestType <complextype name= DeleteRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype /> </sequence> <attribute name= recursive type= xsd:boolean use= optional default= false /> </extension> </complexcontent> </complextype> Operacja ta ma dosyć prostą strukturę zawiera identyfikator obiektu psoid, który ma ulec usunięciu oraz atrybut recursive wskazujący czy wraz z obiektem mają zostać usunięte rekursywnie wszystkie inne obiekty, które w sobie zawiera. Struktura komunikatu zwrotnego w tym przypadku jest identyczna jak struktura podstawowego obiektu odpowiedzi w SPML i ma jedynie zawierać informację o tym, czy obiekt ten pomyślnie usunięty, czy też operacja zakończyła się błędem. Dodatkowe uwagi dotyczące usuwania obiektu PSO Operacja ta wcale nie jest tak prosta jak się wydaje. Załóżmy, że jednym z zasobów, w których obiekt PSO istnieje jest baza danych, a on sam jest reprezentowany przez rekord w tabeli. Można się spodziewać, że będą tam istniały rekordy będące z nim w jakiejś relacji. Przykładowo, jeżeli obiektem jest pewien użytkownik, który intensywnie przez długi okres czasu korzystał z systemu (np. był jego

29 29 administratorem), a wszelkie zdarzenia z jego udziałem były logowane do innej tabeli w bazie, to kaskadowe usunięcie rekordu użytkownika wraz z rekordami połączonymi z nim więzami integracji będzie skutkowało utratą tzw. danych historycznych. W systemach wysokiej dostępności (ang. high availability), w których SLA wymaga by były one dostępne dla klienta przez 99,95% czasu, a zyski generowane są na podstawie liczby transakcji, baza danych wykorzystywana jest często jako źródło dla oprogramowania wspierającego podejmowanie decyzji (ang. online analytical processing OLAP). W takich przypadkach większość danych przechowujących zdarzenia w systemie jest niezwykle cennych i ich usunięcie nie wchodzi w rachubę. Problem można rozwiązać na kilka sposobów. Można np. nie tworzyć więzów integralności dla danych, które nigdy nie powinny być z bazy usunięte. Byłoby to jednak sprzeczne z dobrymi praktykami projektowania baz danych, a na oprogramowaniu wykorzystującym bazę ciążyłby obowiązek utrzymywania wszelkich relacji pomiędzy takimi danymi i mógłby znacznie utrudnić lub wykluczyć wykorzystanie narzędzi mapowania obiektowo relacyjnego. Drugi sposób jest zdecydowanie lepszy i często wykorzystywany w rozproszonych systemach korporacyjnych. Zamiast fizycznego usuwania wpisów użytkownika dokonuje się jego dezaktywacji. W zasobie bazodanowym zwykle jest to wprowadzenie dodatkowego pola określającej jego status w tabeli reprezentującej użytkownika. Może to być kolumna przechowująca wartości takie jak: ACTIVE aktywny, INACTIVE nieaktywny, PROVISIONING w fazie przypisywania zasobów, DEPROVISIONING w fazie usuwania zasobów. Dezaktywacja użytkownika w zasobie będącym usługą katalogową zwykle sprowadza się do wykorzystania wbudowanych funkcjonalności serwera usług katalogowych i ustawienia odpowiedniej flagi true lub false w jednym z atrybutów operacyjnych odnoszących się do wpisu Funkcjonalności Hasła Password W skład funkcjonalności SPML dotyczących operacji na haśle wchodzą operacje: ustawiania hasła dla obiektu PSO wygaszania ważności hasła dla PSO resetowania hasła dla PSO walidacji, czy hasło podane dla PSO jest poprawne pod kątem strukturalnym. Funkcjonalności dotyczące hasła są funkcjonalnościami niestandardowymi, zawarte są w swojej własnej przestrzeni nazw - urn:oasis:names:tc:spml:2:0:password i przez to zgodnie ze specyfikacją SPML jeżeli są one wspierane przez Dostawcę dla danego Celu, to operacja listtargets musi je zwrócić dla tego Celu jako wspierane. setpassword ustawianie hasła dla obiektu Operacja setpassword ma za zadanie ustawienie nowego hasła dla obiektu zarządzanego. Najbardziej intuicyjnym przykładem jest tu oczywiście ustawianie hasła dla obiektu użytkownika. Na Listingu 14 przedstawiono deklarację żądania ustawienia hasła dla obiektu PSO.

30 30 Listing 14. Deklaracja typu SetPasswordRequestType <complextype name= SetPasswordRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype /> <element name= password type= string /> <element name= currentpassword type= string minoccurs= 0 /> </sequence> </extension> </complexcontent> </complextype> Żądanie ustawienia hasła musi obowiązkowo zawierać identyfikator obiektu psoid oraz nowe hasło zawarte w elemencie password. Opcjonalnym elementem żądania jest aktualne hasło zawarte w elemencie currentpassword. Wymagane jest ono jednak głównie wtedy, gdy któryś z docelowych systemów stanowiących część Środowiska wymaga podania aktualnego hasła przed jego zmianą na nowe. Należy pamiętać, że Dostawca usług SPML w ramach manipulowania obiektami PSO niekoniecznie bezpośrednio zarządza odpowiadającymi im źródłami danych. Gdyby tak było, to podawanie bieżącego hasła przy zwykłej operacji uaktualnienia rekordu użytkownika w bazie danych byłoby niepotrzebne, ponieważ operacje biznesowe dla źródła danych są transparentne, a użytkownik jest rozumiany, jako rekord w bazie. Podawanie bieżącego hasła jednak ma duże znaczenie w przypadku, gdy Dostawca propaguje je do zasobów, które same w sobie są np. usługami sieciowymi jakichś systemów informatycznych i dokonują np. sprawdzenia, czy nowe hasło przypadkiem nie jest równe staremu lub z innych trywialnych względów zapewnienia bezpieczeństwa. Struktura odpowiedzi na żądanie ustawienia hasła jest identyczna ze strukturą podstawowego typu reprezentującego podstawowy komunikat zwrotny w protokole SPML. Sprowadza się ona do poinformowania o tym, czy operacja została wykonana pomyślnie i ewentualnego zwrócenia błędów wykonania. expirepassword wygaszanie ważności hasła Względy bezpieczeństwa w rozproszonych systemach informatycznych wymagają, by oprócz polityki dotyczącej struktury hasła istniała jakaś dodatkowa logika zabezpieczeń przed jego przechwyceniem, deszyfrowaniem lub odgadnięciem. Mowa mianowicie o okresowym wygaszaniu jego ważności. Podejście to ma z reguły wymuszać na użytkownikach jego zmianę w możliwie krótkich odstępach czasu, np. jak to ma miejsce w systemach korporacyjnych co 6 miesięcy. Weźmy również pod uwagę przypadek, gdy użytkownik zapomni swojego hasła. Procedura postępowania w takich przypadkach zwykle polega na tym, że kontaktuje się on z biurem obsługi klienta, ono z kolei generuje dla niego losowe hasło, które automatycznie zostaje wysłane na jego funkcjonalną skrzynkę odbiorczą. Mając nowe hasło użytkownik loguje się do systemu i może z niego korzystać przez następne 24h. Po tym czasie, jeżeli nie zmienił swojego hasła osobiście na sobie tylko znaną wartość, jeden z automatycznych procesów działających w systemie informatycznym wygasza jego ważność i użytkownik traci dostęp do niemal wszystkich funkcjonujących tam usług i podsystemów.

31 31 Na Listingu 15 pokazano strukturę żądania wygaśnięcia ważności hasła. Listingu 15. Deklaracja typu ExpirePasswordRequestType <complextype name= ExpirePasswordRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype /> </sequence> <attribute name= remaininglogins type= int use= optional default= 1 /> </extension> </complexcontent> </complextype> Jak widać składa się ono z identyfikatora obiektu, którego ważność chcemy wygasić oraz z opcjonalnego atrybutu remaininglogins. Znaczenie tego ostatniego atrybutu jest jednak niedoprecyzowane. Specyfikacja mówi, że zawiera on liczbę udanych operacji logowania, na które system docelowy powinien pozwolić. Jest jednak niejasne czy określa on ile razy obiekt może być wykorzystany do logowania się w systemach zarządzanych w ramach Środowiska, zanim hasło zostanie wygaszone, czy też może chodzi o pozwolenie na zalogowanie się np. kilka razy zanim sama operacja wygaszania zostanie ukończona. Brak również informacji na ten temat w oficjalnej erracie do specyfikacji utworzonej przez OASIS. Podobnie jak w przypadku usuwania obiektu zarządzanego jak i operacji ustawiania dla niego hasła, odpowiedź na żądanie wygaśnięcia hasła ma strukturę podstawowego typu odpowiedzi SPML. resetpassword ustawianie hasła na wartość losową Operacja ta umożliwia Klientowi na zmianę wartości hasła dla danego obiektu PSO na nową, wygenerowaną przez usługę wartość. Ma ona zastosowanie w przypadku, gdy użytkownik zapomniał swojego hasła lub jego wartość została wygaszona. Dobrym pomysłem jest zadbanie, by ważność wygenerowanego hasła była jak najkrótsza. Umożliwia to na dyscyplinowanie użytkowników systemu, by samodzielnie dbali o jego częstą zmianę i pozwala uniknąć sytuacji, gdy po wygenerowaniu nowego hasła, jest ono zbyt skomplikowane do zapamiętania i po kilku dniach użytkownik jest zmuszony ponownie je generować. Na Listingu 16 przedstawiono deklarację żądania ustawienia hasła na wartość losową. Listingu 16. Deklaracja typu ResetPasswordRequestType <complextype name= ResetPasswordRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype /> </sequence> </extension>

32 32 </complexcontent> </complextype> Zawiera ono tylko jeden parametr, będący identyfikatorem obiektu, dla którego ma zostać wygenerowane nowe hasło. Deklaracja typu odpowiedzi na żądanie wygenerowania nowego hasła została przedstawiona na Listingu 17. Listing 17. Deklaracja typu ResetPasswordResponseType <complextype name= ResetPasswordResponseType > <complexcontent> <extension base= spml:responsetype > <sequence> <element name= password type= string minoccurs= 0 /> </sequence> </extension> </complexcontent> </complextype> Komunikat zwrotny może opcjonalnie zawierać wartość nowo wygenerowanego hasła. Istotnym jest, by w przypadku, gdy Dostawca wie, że któryś z docelowych zasobów nie pozwala na zwrócenie nowego hasła klientowi, operacja zwracała kod błędu, np. customerror wraz ze szczegółowym komunikatem o zaistniałym problemie. validatepassword sprawdzanie poprawności hasła obiektu PSO Zanim nastąpi próba zmiany hasła na nowe, możliwe jest sprawdzenie czy jest ono zgodne z polityką bezpieczeństwa samej usługi SPML. Zmiana hasła dla obiektu PSO zwykle dotyczy kilku zasobów, może być czasochłonne oraz generować niepotrzebny ruch w sieci stanowiącej Środowisko. Stąd wydajniejszym rozwiązaniem jest, gdy wstępna walidacja jego struktury jest wykonywana przez szybką logikę biznesową, udostępnianą przez operację validatepassword. W związku z powyższym wskazanym byłoby zaimplementowanie jakiegoś bazowego algorytmu dokonującego sprawdzenia poprawności hasła i wykorzystanie go przynajmniej w metodach implementujących setpassword i validatepassword. Oczywiście implementacja operacji setpassword nie powinna w żadnym wypadku wykorzystywać bezpośrednio operacji validatepassword. Po pierwsze usługi SPML powinny stanowić integralną całość implementacji, lecz nie powinny ściśle od siebie zależeć i tym bardziej siebie nawzajem wywoływać. Chociaż przykład ustawiania i walidacji hasła nie należy do szczególnie skomplikowanych, to uzależnianie od siebie bezpośrednio wyników działania jednych operacji SPML od wyników innych potencjalnie tworzyłoby warunki do powstania cyklu wywołań, który jest tzw. antywzorcem projektowym (ang. anti pattern). Drugi powód jest bardziej trywialny wywołanie operacji validatepassword zwraca obiekt typu ValidatePasswordResponseType, więc operacja setpassword musiałaby umieć go zinterpretować. Na Listingu 18 umieszczono deklarację typu żądania walidacji poprawności hasła.

33 33 Listing 18. Deklaracja typu ValidatePasswordRequestType <complextype name= ValidatePasswordRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype /> <element name= password type= string /> </sequence> </extension> </complexcontent> </complextype> Struktura żądania zawiera identyfikator obiektu PSO psoid, dla którego ma nastąpić sprawdzenie poprawności hasła przesłanego w elemencie password. Należy zaznaczyć, że logika dokonująca walidacji hasła wcale nie musi być statyczna dla wszystkich użytkowników. Powszechne jest wprowadzanie różnych reguł polityki struktury hasła (ang. password policy). Przykładowo dla bytów (obiektów), które będą posiadały role administracyjne i z racji tego będą wykonywać kluczowe operacje w systemie stosuje się bardziej restrykcyjną politykę niż dla bytów, które mają dostęp tylko do podstawowych jego funkcjonalności i są np. biernymi odbiorcami wszelkich treści czy komunikatów. Strukturę komunikatu zwrotnego dla żądania sprawdzenia poprawności hasła przedstawiona została na Listingu 19. Listing 19. Deklaracja typu ValidatePasswordResponseType <complextype name= ValidatePasswordResponseType > <complexcontent> <extension base= spml:responsetype > <attribute name= valid type= boolean use= optional /> </extension> </complexcontent> </complextype> Struktura tego komunikatu zawiera jedynie flagę zawartą w atrybucie valid, określającą czy podane hasło byłoby poprawne dla danego obiektu PSO. To, czy hasło jest poprawne dla obiektu istniejącego w danym Środowisku jest zazwyczaj iloczynem wyników sprawdzenia jego poprawności na wszystkich zasobach docelowych Funkcjonalności dezaktywacji obiektu - Suspend W skład funkcjonalności SPML dotyczących dezaktywacji obiektu PSO wchodzą operacje: zawieszania funkcjonowania obiektu PSO, przywracania funkcjonowania obiektu PSO, sprawdzania, czy dany obiekt PSO jest niezawieszony.

34 34 Funkcjonalności dotyczące dezaktywacja obiektu są funkcjonalnościami niestandardowymi, zawarte są w swojej własnej przestrzeni nazw - urn:oasis:names:tc:spml:2:0:suspend i przez to zgodnie ze specyfikacją SPML jeżeli są one wspierane przez Dostawcę dla danego Celu, to operacja listtargets musi je zwrócić dla tego Celu jako wspierane. suspend zawieszanie funkcjonowania obiektu PSO Zawieszenie funkcjonowania obiektu PSO, czyli jego dezaktywacja jest operacją mającą na celu chwilowe zablokowanie korzystania z niego w ramach Środowiska. Przykładowo, jeżeli obiektem zarządzanym jest użytkownik, to w wyniku wykonania operacji dezaktywacji najczęściej traci on możliwość korzystania z systemów wchodzących w skład zarządzanego Celu. Na Listingu 20 przedstawiono strukturę komunikatu żądania zawieszenia funkcjonowania obiektu. Listing 20. Deklaracja typu SuspendRequestType <complextype name= SuspendRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype /> </sequence> <attribute name= effectivedate type= datetime use= optional /> </extension> </complexcontent> </complextype> Oprócz elementu reprezentującego identyfikator obiektu, który ma ulec dezaktywacji, komunikat ten zawiera atrybut effectivedate opisujący dokładny czas, w którym ma to nastąpić. Wykorzystanie tego ostatniego jest opcjonalne i jeżeli nie zostanie on dołączony do żądania, to dezaktywacja obiektu następuje natychmiastowo. Dobrym rozwiązaniem jest ustalenie dla tej operacji dodatkowego kontraktu pomiędzy Klientem a Dostawcą mającego na celu dokładne doprecyzowanie której strefy czasowej dotyczy przesłana data. Odpowiedź na żądanie dezaktywacji obiektu PSO ma strukturę podstawowego typu odpowiedzi SPML. resume przywracanie funkcjonowanie obiektu PSO Przywracanie działania obiektu zarządzanego, zwane również aktywacją jest operacją odwrotną do operacji dezaktywacji. Ma również niemal identyczną strukturę, którą przedstawiono na Listingu 21. Listing 21. Deklaracja typu ResumeRequestType <complextype name= ResumeRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype /> </sequence> <attribute name= effectivedate type= datetime use= optional />

35 35 </extension> </complexcontent> </complextype> Atrybut effectivedate ma tu zastosowanie analogiczne do swojego odpowiednika w operacji dezaktywacji, a odpowiedź na żądanie aktywacji ma strukturę podstawowego typu komunikatu zwrotnego SPML. active sprawdzanie czy dany obiekt PSO jest niezawieszony Na Listingu 22 przedstawiono strukturę komunikatu sprawdzającego status aktywności danego obiektu PSO. Listing 22. Deklaracja typu ActiveRequestType <complextype name= ActiveRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype /> </sequence> </extension> </complexcontent> </complextype> Jak widać zawiera on wyłącznie element reprezentujący identyfikator obiektu PSO, którego status ma zostać sprawdzony. Na Listingu 23 przedstawiona jest struktura komunikatu zwracającego w atrybucie active informację o tym czy dany obiekt PSO jest aktywny. Listing 23. Deklaracja typu ActiveResponseType <complextype name= ActiveResponseType > <complexcontent> <extension base= spml:responsetype > <attribute name= active type= boolean use= optional /> </extension> </complexcontent> </complextype> Niestandardowe Funkcjonalności SPML pozwala na zdefiniowanie zestawu dodatkowych operacji lub funkcjonalności, jeżeli pojawi się taka potrzeba. Zestaw predefiniowanych funkcjonalności opiera się o typy elementów dziedziczących po kilku podstawowych typach takich jak bazowy dla wszystkich ExtensibleType czy bazowe dla żądań i odpowiedzi: RequestType i ResponseType. Standardowo są one dostarczane w osobnych plikach fizycznych i przestrzeniach nazw, stąd zintegrowanie dodatkowej, własnej funkcjonalności z SPMLv2 sprowadzać się będzie do stworzenia dla

36 36 niej nowej przestrzeni nazw, np.: urn:oasis:names:tc:spml:2:0:pjwstk i zadeklarowaniu w osobnym pliku, np. w pstc_spmlv2_pjwstk.xsd zestawu nowych obsługiwanych typów. Wśród nich najpewniej znajdą się deklaracje nowych typów żądań i nowych typów komunikatów zwrotnych wraz z wszelkimi obiektami pomocniczymi, jak np. typ żądania tworzący obiekt reprezentujący nowego studenta przedstawiony na Listingu 24. Listing 24. Deklaracja typu AddStudentRequestType <complextype name= AddStudentRequestType > <complexcontent> <extension base= spml:requesttype > <sequence> <element name= psoid type= spml:psoidentifiertype /> <element name= firstname type= string /> <element name= lastname type= string /> <element name= indexnumber type= string /> </sequence> </extension> </complexcontent> </complextype> Transakcyjność Specyfikacja SPML nie opisuje żadnych mechanizmów transakcyjności, jakie można wykorzystać do obsługi żądań. W szczególności nie mówi ona nic o atomowości pojedynczych operacji lub ich grup, początkach transakcji, zatwierdzaniu zmian (ang. commit) lub ich cofaniu (ang. rollback) czy też końcach transakcji. Dzieje się tak głównie dlatego, że opisanie i wprowadzenie takich funkcjonalności dla usług działających w sposób rozproszony, na wielu zasobach i źródłach danych oraz w trybach asynchronicznych po prostu byłoby niemożliwe lub zbyt skomplikowane. Należy również pamiętać, że SPML próbuje unikać opisu wszelkich rozwiązań implementacyjnych, skupiając się przede wszystkim na samym protokole komunikacyjnym pomiędzy Klientem a Dostawcą. Nie oznacza to jednak, że implementacja SPML nie może zawierać elementów transakcyjności. Wręcz przeciwnie. Po pierwsze usługi oparte o SPML zwykle nie wykonują żadnej logiki biznesowej same w sobie, lecz delegują żądania do konkretnych klas serwisowych (usługowych). One z kolei działają na konkretnych już danych, np. na encjach reprezentujących wiersze w bazie danych. Metody klas serwisowych w takich przypadkach zazwyczaj same w sobie wywoływane są w ramach transakcji zarządzanej przez kontener, na którym działają (np. Spring Framework) albo też same w sobie takie transakcje tworzą. Po drugie istnieje możliwość rozszerzenia samych definicji usług o niestandardowe funkcjonalności. W takim przypadku wystarczy, że Dostawca zaimplementuje ramy transakcyjności dla jednej lub kilku operacji i zacznie zwracać stosowną informację o wspieranym nowym zestawie możliwości w rezultacie operacji listtargets.

37 37 4. Istniejące implementacje SPML Wspomniano już, że Service Provisioning Markup Language stanowi pewien zbiór specyfikacji i jest technologią wyłącznie w teoretycznym znaczeniu tego słowa. Oznacza to, że jest teoretycznie niezależna od wykorzystanych technologii programistycznych (np. Java, Ruby, C++) i do pewnego stopnia dowolne są również protokoły transportowe dla jego komunikatów (np. HTTP, JMS). Jedyną technologią wspomnianą w specyfikacji, od której zależna jest implementacja SPML jest język XML. Wynika to oczywiście z tego, że SPML jest po prostu zestawem odpowiednio zaprojektowanych znaczników XML, które w połączeniu z protokołem wymiany komunikatów stanowią logiczną całość. Czym może być implementacja SPML? Typowym wykorzystaniem SPML jest osadzenie go w jakimś systemie informatycznym. Jego integracja może odbywać się na zasadzie bezpośredniego odwołania do komunikatów w formacie XML, parsowanie ich oraz poprawne interpretowanie. Jest to oczywiście sposób bardzo inwazyjny, skrajnie nieprzyjazny użytkownikom i skutecznie utrudniający późniejsze utrzymanie systemu. Rozwiązaniem tego problemu mogłaby być implementacja SPML, jako niezależnej od jakichkolwiek kwestii biznesowych biblioteki programistycznej. Jej podstawowym zadaniem byłoby pośrednictwo w opakowaniu żądań do postaci komunikatów zgodnych ze specyfikacją, wysyłaniu ich do dostawcy, odbieraniu odpowiedzi i zwracaniu ich w formie przyjaznej programiście. W praktyce oznaczałoby to jednak, że biblioteka taka byłaby uniwersalna niemal wyłącznie do zastosowań po stronie Klienta. W przypadku architektury zorientowanej usługowo Klient nie musi być zależny od niuansów implementacyjnych tak długo jak długo poprawnie potrafi wysyłać żądania do Dostawcy, odbierać od niego komunikaty zwrotne i odpowiednio na nie reagować. Po stronie Dostawcy, który zwykle utożsamiany jest z serwerem, implementacje logiki biznesowej nigdy nie są uniwersalne pomimo podobnego przeznaczenia, czym innym jest usługa SPML zarządzająca kontami użytkowników w dużej linii lotniczej, a czym innym jest zarządzanie użytkownikami w korporacji finansowej. W rezultacie o ile sam protokół komunikacyjny w różnych przypadkach biznesowych jest identyczny, o tyle implementacje konkretnych algorytmów, przepływów danych i procesów są różne. Z czysto technicznego punktu widzenia uniwersalna biblioteka kliencka jest w jakimś sensie implementacją języka SPML. Natomiast biorąc pod uwagę to, że biblioteka ta z w/w względów nie może zawierać części usługowej (Dostawcy) oraz generalnie nie jest bezpośrednio implementacją logiki biznesowej, należy stwierdzić, że biblioteka taka nie jest implementacją SPML w pełnym znaczeniu tego słowa, lecz jedynie służy jako pomocnicze narzędzie w komunikacji z implementacjami właściwymi OpenSPML Przykładem istniejącej narzędziowej biblioteki klienckiej ułatwiającej integrację SPML w istniejących systemach informatycznych jest projekt OpenSPML. Ma on charakter otwartego oprogramowania i utrzymywany jest aktualnie w ramach społeczności java.net pod patronatem firmy Sun Microsystems.

38 38 Biblioteka ta napisana jest w języku Java i dostarcza gotowych interfejsów programistycznych umożliwiających wykonywanie operacji SPML na dowolnym Dostawcy, obsługującym standardy języka w wersjach 1.0 i 2.0 w formacie zgodnym z profilami XSD oraz DSML. Na Listingu 25 pokazano przykładowe wykorzystanie biblioteki. Listing 25. Wykorzystanie klasy LighthouseClient LighthouseClient client = null; try { client = new LighthouseClient(); client.setuser("jnowak"); client.setpassword("abc123"); client.seturl("http://pete.pjwstk.edu.pl:8080/idm/servlet/openspml2"); client.settrace(true); catch (MalformedURLException e) { throw new Error("Error initializing URL for IDM SPML services", e); ExtendedRequest changepasswordrequest = new ExtendedRequest(); changepasswordrequest.setoperationidentifier("launchprocess"); changepasswordrequest.setattribute("accountid", "xy123456"); changepasswordrequest.setattribute("password", "xyz987"); changepasswordrequest.setattribute("process", "Change Password"); changepasswordrequest.setattribute("taskname", "Change Password"); changepasswordrequest.setattribute("viewform", "User View"); SpmlResponse spmlresponse = client.request(changepasswordrequest); System.out.println("Operation result: " + spmlresponse.getresult()); client.logout(); Powyższa operacja inicjalizuje obiekt klienta podając mu nazwę użytkownika - jnowak oraz hasło abc123. Dane tego użytkownika zostaną wykorzystane do uwierzytelnienia i autoryzacji po stronie Dostawcy, toteż muszą być one poprawne, a sam użytkownik powinien posiadać odpowiednie prawa do wykonywania danej operacji. Następnie podany jest adres URL do punktu końcowego udostępnionego przez Dostawcę - Punkt ten oczywiście powinien zawierać usługi sieciowe zgodne z SPML. W następnej kolejności tworzony jest obiekt żądania ExtendedRequest, który inicjalizowany jest atrybutami dotyczącymi m.in. nazwy operacji, którą dostawca powinien wykonać Change Password, nazwą konta, dla którego operacja powinna zostać wykonana xy oraz nową wartością parametru password xyz987. Na samym końcu na obiekcie klienta wykonana jest operacja wylogowania. Z racji tego, że warstwą transportową dla OpenSPML jest protokół HTTP, a ten z kolei jest bezstanowy (połączenie utrzymywane jest wyłącznie na czas wysłania żądania i odebrania odpowiedzi), to rzeczywiste wylogowanie i rozłączenie się z dostawcą ma miejsce w momencie zakończenia wykonywania operacji LighthouseClient.request(). Sama operacja LighthouseClient.logout() sprowadza się do ustawienia wartości parametrów klienta na domyślne. Wyczyszczony zostaje wtedy m.in. identyfikator sesji.

39 39 Po bliższym zapoznaniu z biblioteką okazuje się, że większość operacji wykonywanych za jej pomocą wygląda w ten sposób Sun Identity Manager Firma Sun Microsystems, poza konsorcjum OASIS, jest na chwilę obecną najbardziej znanym użytkownikiem, beneficjentem i promotorem rozwiązań opartych o Service Provisioning Markup Language. Jednym z jej sztandarowych produktów jest system zarządzania tożsamościami Sun Identity Manager (IDM). Głównym jego przeznaczeniem jest propagowanie informacji dotyczących użytkowników do wielu systemów jednocześnie poprzez centralizację najczęściej wykonywanych zadań administracyjnych w heterogenicznych, rozproszonych systemach informatycznych, patrz [4]. Na Diagramie 3 przedstawiono główne elementy Środowiska, w którym zwykle działa Sun Identity Manager. Diagram 3. Architektura zarządzania tożsamościami w IDM Sun Directory Server - LDAP Baza danych Środowisko Sun Identity Manager Sun Identity Manager Active Directory - LDAP System plików Repozytorium IDM Serwer aplikacji Centralną częścią systemu jest instancja aplikacji IDM, będąca aplikacją zgodną z Java 2 Enterprise Edition. Może być ona wdrożona na jeden z serwerów opartych o J2EE, tj. kontenery serwletów Apache Tomcat i Apache Jetty oraz serwery aplikacji JBoss lub Sun Application Server i wiele innych.

40 40 Każda instancja IDM musi posiadać tzw. repozytorium, które jest składnicą wszelkich zarządzanych przez niego obiektów. Repozytorium może stanowić zarówno relacyjna baza danych jak również zwykły plik XML. W zastosowaniach produkcyjnych wykorzystywane są najczęściej do tego celu bazy Oracle i MySQL. W momencie tworzenia użytkownika w IDM, jego podstawowe dane zostają zapisane w repozytorium. Jeżeli dodatkowo użytkownik ten zostanie powiązany z jakimiś zasobami, będącymi źródłami danych (jak np. serwer usług katalogowych LDAP lub baza danych), to jego dane zostaną do nich spropagowane. To, jakie to będą dane i jaki ich będzie format zależy od ustawienia odpowiedniego mapowania pomiędzy atrybutami repozytorium a źródłem danych Adaptery zasobów Łączenie z różnymi źródłami danych realizowane jest to za pomocą tzw. adapterów, które stanowią interfejsy komunikacyjne z wieloma typami źródeł danych. Są one swego rodzaju sterownikami umożliwiającymi dostęp do owych źródeł. Natomiast te ostatnie stanowią zwykle systemy docelowe do wszelkich operacji przygotowywania usług. Zaliczamy do nich w głównej mierze: bazy danych: Oracle, MySQL, PostgreSQL, DB2, Sybase, serwery usług katalogowych: Sun Directory Server, Windows Active Directory, systemy operacyjne: Solaris, Unix, Linux, systemy zabezpieczeń: Sun Access Manager i wiele innych. Dzięki temu, że architektura IDM traktuje adaptery jak tzw. wtyczki (ang. plugins), możliwe jest tworzenie i rejestrowanie własnych, np. łączących się za pośrednictwem usług sieciowych z innymi systemami docelowymi, które nie udostępniają bezpośrednio swoich źródeł danych Nazwy użytkowników a heterogeniczne systemy docelowe Zazwyczaj atrybuty jednoznacznie identyfikujące użytkownika, takie jak np. nazwa konta, które go reprezentuje, propagowane są dosłownie. Wyjątek mogą stanowić 2 przypadki. Pierwszy przypadek to taki, gdy IDM w ramach Środowiska zintegrowany jest z systemami spadkowymi, które były projektowane przy wykorzystaniu innych standardów, niż te aktualnie istniejące w danej korporacji. Zazwyczaj w starych systemach szeroko pojęta normalizacja danych była czymś unikatowym i przykładowo imię i nazwisko użytkownika przechowywane była w tym samym atrybucie, a jego nazwa dopuszczała znaki, które wg późniejszych standardów stały się niedopuszczalne. Najczęściej wtedy za pomocą odpowiednich reguł systemu IDM tworzy się statyczne, jednokrotne mapowanie nazwy z repozytorium na nazwę z podsystemu docelowego. Drugim przypadkiem, gdy nazwa użytkownika nie jest propagowana do podsystemów Środowiska dosłownie, jest sytuacja, gdy w skład środowiska wchodzą systemy utworzone przez różnych producentów. Przykładowo linia lotnicza Kraków Airlines zakupiła 2 produkty: Rezerwator Biletów i Menedżer Samolotów. Załóżmy, że każdy z nich zaimplementowany został przez innego producenta, przy czym: w pierwszym z nich nazwa użytkownika systemu składa z jego inicjałów i 6 dodatkowych cyfr, np. dla Jana Kowalskiego może to być jk456321, w drugim z nich nazwa użytkownika składa się wyłącznie z 6-ciu cyfr, np. dla Jana Kowalskiego może to być

41 41 Załóżmy też, że konto użytkownika obu tych systemów, Jana Kowalskiego, tworzone jest w Środowisku. W repozytorium IDM oraz w Menedżerze Samolotów zostaje ono utworzone pod nazwą , czyli bez inicjałów na początku, natomiast w Rezerwatorze Biletów zostaje ono utworzone pod nazwą jk456321, czyli z inicjałami na początku. Podobnie więc, jak w przypadku systemów spadkowych stosuje się tu odpowiednie reguły mapowania i w takim przypadku wszelkie późniejsze zarządzanie danymi użytkownika w tych podsystemach z punktu widzenia IDM nie stanowią żadnych problemów. Problem pojawiać się może wtedy, gdy chcemy utworzyć dla nich wspólny system zabezpieczeń oparty o Single Sign On i umożliwić automatyczną autentykację użytkowników w jednym systemie, gdy są już zalogowani w drugim. Projektuje się całe Środowisko tak, by możliwe było sprawne dynamiczne mapowanie nazw użytkowników za pomocą jakiegoś mechanizmu przekazywania tożsamości między aplikacjami, takiego jak np. Security Assertion Markup Language (SAML) Przepływy prac Wszystkie operacje w Sun Identity Manager opierają się o system przepływów prac (ang. workflows). Workflow jest logicznym, powtarzalnym procesem, w trakcie którego dokumenty, dane oraz zadania są przekazywane pomiędzy kolejnymi uczestnikami, przy czym dzieje się to w oparciu o pewną logikę biznesową, a uczestnikiem może być osoba lub maszyna. Workflow definiuje sieć sekwencji operacji i zadań, które mają zostać wykonane. Przykładem zastosowania przepływu prac jest operacja dodawania nowego użytkownika, w ramach którego zostają kolejno wykonane następujące operacje: sprawdzenie poprawności danych, np. hasła itd., wysłanie wiadomości do administratorów, którzy mają prawo zatwierdzania dostępu do poszczególnych źródeł danych w podsystemach Środowiska, zatwierdzenie dostępu do w/w źródłach danych, obliczenie i przypisanie ról i przywilejów, utworzenie kont użytkownika w źródłach danych. Ukończenie operacji w każdym z powyższych punktów stanowi osiągnięcie pojedynczego stanu, zwanego również aktywnością (ang. activity). Osiągnięcie ostatniego stanu w łańcuchu oznacza zakończenie pojedynczego przepływu prac IDM a SPML Jak już wspomniano, poprzez swoją architekturę zorientowaną na usługi IDM udostępnia zaimplementowany jako serwlet J2EE punkt końcowy dający możliwość zdalnego administrowania nim za pomocą języka SPML. Klasa tego serwletu, zwanego również routerem, stanowi część biblioteki narzędziowej OpenSPML i na chwilę obecną obsługuje standard SPML zgodny z profilem DSML w wersji 2.0. Profil ten nie stanowi przedmiotu niniejszego opracowania, toteż zostanie on krótko scharakteryzowany i przedstawiony wyłącznie w ramach przykładu integracji implementowanej biblioteki z IDM. Wspieranymi przez IDM operacjami SPML 2.0 są: add dodawanie obiektu, delete usuwanie obiektu, listtargets zwracanie listy celów, lookup wyszukiwanie pojedynczego obiektu, modify modyfikowanie atrybutów obiektu.

42 42 status zwrócenie statusu asynchronicznego wywołania operacji, cancel anulowanie asynchronicznego wywołania operacji, bulkmodify modyfikowanie grupy obiektów, bulkdelete usuwanie grupy obiektów, batch wywołanie grupy operacji na różnych obiektach, expirepassword wygaszenie ważności hasła użytkownika, resetpassword resetowanie wartości hasła użytkownika, setpassword ustawienie hasła użytkownika, validatepassword sprawdzenie poprawności hasła dla użytkownika, suspend zawieszanie działania konta użytkownika, resume reaktywowanie działania konta użytkownika. Do funkcjonalności, które nie są wspierane należą Reference, Search oraz Updates Open Content Specyfikacja określa SPML jako tzw. język otwartej zawartości (ang. open content). Oznacza to, ze poza standardowymi elementami opisanymi przez specyfikację możliwe jest dodawanie własnych, bardziej specyficznych dla własnych wymagań biznesowych. Sun Identity Manager wykorzystuje tę możliwość wprowadzając tzw. operacyjne pary nazwy i klucza (ang. operational name value pairs OperationalNVPs) oraz atrybuty operacyjne (ang. OperationalAttributes). Niemal każdy komunikat żądania wysyłany do routera i od niego odbierany zawiera przynajmniej jeden element OperationalNVP, zawierający token reprezentujący sesję użytkownika i tymczasowo przechowywany w IDM w celu zwiększenia wydajności przetwarzania żądań Istniejące implementacje IDM Sun Identity Manager został z powodzeniem wykorzystany w licznych branżach. Do jego głównych użytkowników na chwilę obecną zalicza się: Sabre Airline Solutions sektor lotniczy, University of Alabama sektor edukacyjny, Swisscom Mobile sektor telekomunikacyjny, NASA - sektor lotniczo naukowy, oraz wiele innych firm m.in. z branży medycznej Uwagi ogólne OpenSPML jako klient usług SPML ze względu na swoją uniwersalność oraz prostotę użytkowania, jest projektem bardzo dobrze rokującym na przyszłość. Jest on zarazem dojrzałym narzędziem, które bez obaw można zastosować w systemach produkcyjnych i w razie potrzeby szybko samodzielnie naprawić lub dostosować do własnych potrzeb. Jedynym zastrzeżeniem mogą być trudności w znalezieniu dokumentacji na traktującej o nim chaotycznej i zdezaktualizowanej stronie WWW. Sun Identity Manager jako system zarządzania tożsamościami pozostawia wiele do życzenia. Liczne błędy czasu wykonania aplikacji, jak i niskiej jakości dokumentacja produktu są przyczyną olbrzymich problemów przy jego wdrożeniach. Specjaliści IT, którzy chcą zastosować IDM do zaawansowanych potrzeb, zwykle zmuszeni są brać udział w niezwykle kosztownych szkoleniach prowadzonych przez firmę Sun Microsystems lub przez jednego z jej certyfikowanych partnerów. Jest on

43 jedyną aplikacją wykorzystaną w części praktycznej niniejszej pracy, która nie jest oparta na licencji otwartego oprogramowania. Wyłącznymi kodami źródłowymi, które ze względu na swoją specyfikę muszą być dołączone do dystrybucji systemu są strony Java Server Pages, stanowiące jego część wizualną. 43

44 44 5. Wykorzystane technologie W następnych punktach pokrótce przedstawiono technologie wykorzystane w implementacji biblioteki SPML stanowiącej część praktyczną niniejszego opracowania. Należy zauważyć, że ich szczegółowy opis nie stanowi tematu pracy. Szczegółowe przybliżenie ich właściwości będzie miało miejsce wyłącznie w kontekście implementowanej funkcjonalności Spring Spring jest zestawem bibliotek programistycznych, które zawierają gotowe szkielety, które programista może wykorzystać do rozwiązywania większości typowych problemów programistycznych występujących przy projektowaniu, implementacji i testowaniu aplikacji opartych o J2EE. Pierwotnie Spring miał być alternatywą dla technologii tworzenia aplikacji korporacyjnych Enterprise JavaBeans (EJB), która narzucała wiele ograniczeń i była niezwykle trudna w użytkowaniu i utrzymaniu. Dosyć szybko ewoluował jednak w kierunku zestawu lekkich (ang. lightweight) szablonów stanowiących gotowe implementacje znanych wzorców projektowych. Bibliotekę Spring stanowią m.in. takie komponenty jak: kontener Inversion Of Control, biblioteka Model-View-Controller (MVC), szablon obsługi transakcji, szablon obsługi źródeł danych, biblioteka bezpieczeństwa, szablon testów jednostkowych, biblioteka programowania aspektowego. Dzięki jej modułowości liczba innych bibliotek programistycznych, które można z nim zintegrować jest nieograniczona i zależy wyłącznie od bieżących potrzeb. Podstawowym komponentem biblioteki Spring jest tzw. kontener odwrócenia sterowania, zaimplementowany wg wzorca Inversion Of Control. Podejście to pozwala na deklaratywne budowanie aplikacji z modułów poprzez zarządzanie zależnościami pomiędzy nimi za pomocą plików XML, automatycznego wstrzykiwania zależności (ang. Dependency Injection) oraz zastosowania konwencji nad konfiguracją (ang. convention over configuration). To ostatnie pojęcie oznacza, że tam gdzie to możliwe, stosuje się wartości domyślne znacznie zmniejszając w ten sposób czas przeznaczony na konfigurację aplikacji. Biblioteka Spring będzie stanowić szkielet, na którym osadzone zostaną usługi sieciowe oparte o SOAP, stanowiące trzon biblioteki SPML. Będzie również stanowić interfejs dostępowy wysokiego poziomu do wszelkich operacji na źródłach danych takich jak baza danych czy serwer katalogowy. Zostanie również wykorzystana biblioteka Spring Security, która zapewni system autentykacji użytkowników dla aplikacji działających w ramach Środowiska, przedstawionych w przykładzie integracji z systemem Sun Identity Manager. Szczegółowe informacje nt. biblioteki Spring można znaleźć w [5].

45 Hibernate Hibernate jest aktualnie najbardziej znaną biblioteką udostępniającą mechanizmy mapowania obiektowo relacyjnego (ang. Object Relational Mapping ORM) dla aplikacji zaimplementowanych w języku Java i korzystających z relacyjnych baz danych takich jak Oracle, PostgreSQL, MySQL i innych, patrz [7]. Zapewnia ona zestaw interfejsów dostępowych do danych trwałych i stanowi ona tzw. warstwę persystencji. Pozwala ona przede wszystkim uniknąć osadzania natywnych zapytań relacyjnych baz danych w kodzie źródłowych aplikacji, przez co wspomaga przenośność pomiędzy różnymi dostawcami baz danych. Możliwe jest tworzenie zapytań na kilka sposobów: poprzez gotowy zestaw klas dostarczający zaawansowanych funkcjonalności zapytania przez przykład (ang. query by example), poprzez język Hibernate Query Language (HQL), poprzez wykorzystanie składni natywnych wersji języka SQL wielu różnych baz danych. Biblioteka Hibernate wykorzystana jest w implementowanej bibliotece za pośrednictwem dodatkowej warstwy persystencji, zwanej Java Persistence API. Ta ostatnia wprowadza dodatkowy stopień abstrakcji umożliwiający w razie potrzeby szybką i sprawną zmianę biblioteki ORM na pochodzącą od innego dostawcy, np. na TopLink firmy Oracle Apache CXF Apache CXF jest biblioteką programistyczną dostarczającą szkieletu do tworzenia usług sieciowych opartych o SOAP w języku Java. Pozwala na tworzenie usług sieciowych na 2 sposoby. Pierwszym z nich jest podejście kod najpierw (ang. code first), gdzie najpierw tworzona jest logika biznesowa usług, a następnie w trakcie wykonania (ang. runtime) w miarę potrzeb generowany jest plik definicji usług sieciowych WSDL. Drugim podejście jest wykorzystanie dostarczonych narzędzi do automatycznego generowania klas usługowych oraz opakowujących przesyłane komunikaty w oparciu o pliki - WSDL oraz schematy XSD. Ponadto CXF jest w stanie wygenerować zestaw klas, które można z powodzeniem wykorzystać do stworzenia pełnowartościowej aplikacji klienckiej. Dzięki temu uzyskuje się pewność, że zarówno zaimplementowane usługi jak i klient korzystają z tych samych standardów SOAP. Do głównych standardów usług sieciowych wspieranych przez Apache CXF należą ponadto: WS-Addressing opisujący adresowanie usług sieciowych, WS-Policy opisujący sposób ogłaszania wymagań dotyczących warunków, jakie konsumenci usług muszą spełnić, by z nich korzystać, WS-Security opisujący różne protokoły bezpieczeństwa, WS-ReliableMessaging opisujący protokół zapewniający poprawne dostarczanie komunikatów pomiędzy stronami. Po osadzeniu w szkielecie biblioteki Spring umożliwia ona zarówno osadzenie zaimplementowanych usług w serwerze opartym o J2EE jak również na uruchomienie ich w samodzielnej aplikacji. Apache CXF stanowi podstawowy mechanizm usług sieciowych, o które oparta jest implementacja biblioteki SPML stanowiącej część praktyczną niniejszego opracowania.

46 46 Więcej informacji o Apache CXF można znaleźć w [8] Apache Directory Server Apache Directory Server jest implementacją serwera usług katalogowych opartych o protokół LDAP (ang. Lightweight Directory Access Protocol). Jest on projektem otwartego oprogramowania napisanym całkowicie w języku Java, patrz [6]. Aplikacja ta została wykorzystana w przykładzie integracji implementowanej biblioteki SPML z systemem IDM jako źródło danych, do którego propagowane są dane użytkowników. Te ostatnie stanowią punkt odniesienia przy autentykacji użytkowników jednej z przykładowych aplikacji korzystających ze Środowiska PostgreSQL PostgreSQL opisywany jest przez swoich twórców, jako najbardziej zaawansowany system zarządzania relacyjnymi bazami danych na świecie, patrz [9]. W rzeczywistości prostota użytkowania, bardzo dobra dokumentacja i duża społeczność użytkowników czyni go jednym z najpopularniejszych systemów bazodanowych stworzonych na licencji otwartego oprogramowania. Do głównych funkcjonalności PostgreSQL należą: obsługa języków skryptowych, obsługa języków kompilowanych, indeksy, wyzwalacze, system kontroli współbieżnego wykonania transakcji. System dostępny jest na wiele platform, w tym UNIX, Linux, Solaris i Windows. Wykorzystanie bazy PostgreSQL w części praktycznej pracy ograniczy się do zastosowania jej jako bezpośredniego źródła danych dla implementowanej biblioteki SPML.

47 47 6. Implementacja specyfikacji SPML Specyfikacja protokołu SPML dzieli go na kilka logicznych części, które mogą być niezależnie od siebie zaimplementowane. Implementacja języka stanowiąca przedmiot niniejszej pracy opiera się na funkcjonalnościach: Core podstawowej, Password hasła, Suspend dezaktywacji. Należy podkreślić, że implementacja ta nie jest zasobem bibliotecznym w ogólnym znaczeniu tego słowa i stanowi w głównej mierze potwierdzenie pewnej koncepcji (ang. proof of concept). Z przyczyn podanych w rozdziale dotyczącym istniejących implementacji SPML, nie jest możliwe bezpośrednie osadzenie jej w istniejącym projekcie bez odpowiedniej ingerencji w jej kod źródłowy. Z tego względu powinna być ona traktowana, jako biblioteka referencyjna będąca szkieletem i punktem odniesienia dla programistów, którzy chcieliby w sprawny sposób wdrożyć SPML do swoich projektów. Implementacja w/w funkcjonalności wyczerpuje główne koncepcje, które warto jest zastosować przy tworzeniu własnego rozwiązania opartego o SPML. Stąd też implementacja pozostałych funkcjonalności byłaby nadmiarowa. Struktura projektu Na przedmiotową implementację SPML składają się duża liczba klas języka Java, pliki schematów XSD, pliki konfiguracyjne XML oraz wspomniane w poprzednim rozdziale biblioteki programistyczne Spring, Apache CXF oraz Hibernate. Wszystkie pozostałe wykorzystane technologie, a w szczególności Apache Directory Server, PostgreSQL oraz pozostałe zaimplementowane kody źródłowe stanowią wyłącznie przykłady wykorzystania biblioteki i są jakoby produktem ubocznym projektu Opis biblioteki Bibliotekę SPML zaprojektowano, jako usługę sieciową opartą o architekturę zorientowaną usługowo. Na Diagramie 4 pokazano zależności pomiędzy poszczególnymi jej klasami.

48 48 Diagram 4. Zależności pomiędzy klasami implementacji SPML «utility» UserServices «interface» SPMLRequestPortType +spmllisttargetsrequest() : ListTargetsResponseType +spmllookuprequest() : LookupResponseType +spmladdrequest() : AddResponseType +spmlmodifyrequest() : ModifyResponseType +spmldeleterequest() : ResponseType +spmlvalidatepasswordrequest() : ValidatePasswordResponseType +spmlsetpasswordrequest() : ResponseType +spmlresetpasswordrequest() : ResetPasswordResponseType +spmlexpirepasswordrequest() : ResponseType +spmlsuspendrequest() : ResponseType +spmlresumerequest() : ResponseType +spmlactiverequest() : ActiveResponseType «utility» SpmlValidationService «uses» «uses» «implementation class» SPMLServicesImpl «uses» «uses» «uses» «uses» «utility» SPMLServicesUtils «utility» SPMLValidator «utility» SPMLJobScheduler «utility» IDMServices Najwyżej w hierarchii implementacji znajduje się interfejs SPMLRequestPortType, deklarujący operacje SPML należące do funkcjonalności Core, Password i Suspend. Klasą implementującą interfejs SPMLRequestPortType i stanowiącą jednocześnie główne miejsce implementacji usług jest SPMLServicesImpl. Korzysta ona z kilku klas narzędziowych takich jak: UserServices, SPMLServicesUtils, SPMLValidator, IDMServices, SPMLJobScheduler, SPMLValidationService. W następnych sekcjach wszystkie z w/w klas zostaną szczegółowo opisane. Interfejs SPMLRequestPortType SPMLRequestPortType jest interfejsem wygenerowanym przez bibliotekę Apache CXF na podstawie pliku WSDL opisującego usługi SPML zadeklarowane tam dla potrzeb przedmiotowej implementacji. Na Listingu 26 przedstawiono fragment tego interfejsu.

49 49 Listing 26. Fragment interfejsu = name = SPMLRequestPortType oasis.names.tc.dsml._2._0.core.objectfactory.class, org.openspml.v2.util.xml.objectfactory.class, oasis.names.tc.spml._2._0.dsml.objectfactory.class, oasis.names.tc.spml._2._0.password.objectfactory.class, com.pete.pjwstk.user.v2009.objectfactory.class, oasis.names.tc.spml._2._0.objectfactory.class, = SOAPBinding.ParameterStyle.BARE) public interface SPMLRequestPortType = lookupresponse, targetnamespace = urn:oasis:names:tc:spml:2:0, partname = body = SPMLLookupRequest, action = ) public oasis.names.tc.spml._2._0.lookupresponsetype = body, name = lookuprequest, targetnamespace = urn:oasis:names:tc:spml:2:0 ) oasis.names.tc.spml._2._0.lookuprequesttype body = deleteresponse, targetnamespace = urn:oasis:names:tc:spml:2:0, partname = body = SPMLDeleteRequest, action = ) public oasis.names.tc.spml._2._0.responsetype = body, name = deleterequest, targetnamespace = urn:oasis:names:tc:spml:2:0 ) oasis.names.tc.spml._2._0.deleterequesttype body = addresponse, targetnamespace = urn:oasis:names:tc:spml:2:0, partname = body = SPMLAddRequest, action = ) public oasis.names.tc.spml._2._0.addresponsetype = body, name = addrequest, targetnamespace = urn:oasis:names:tc:spml:2:0 ) oasis.names.tc.spml._2._0.addrequesttype body );

50 50 Interfejs opatrzony jest stanowiącą część interfejsu programistycznego standaryzującego obsługę do usług sieciowych w języku Java 5. Adnotacja ta oznacza interfejs opisujący zestaw usług sieciowych lub klasę, które takie usługi implementują. Docelową przestrzenią nazw do której należą implementowane usługi jest zawarta w atrybucie targetnamespace wartość opisuje sposób, w jaki usługi sieciowe mapowane są na protokół SOAP. W tym przypadku informuje o tym, że parametry operacji powinny być reprezentowane przez cały komunikat żądania. Fragment interfejsu zawiera przykładowe definicje 3ch metod usługowych: spmllookuprequest() wyszukiwanie obiektu zarządzanego, spmladdrequest() dodawanie obiektu zarządzanego, spmldeleterequest() usuwanie obiektu zarządzanego. Każda z nich przyjmuje jako parametr obiekt reprezentujący odpowiadający jej komunikat żądania SPML, odpowiednio: ListTargetsRequestType, LookupRequestType i AddRequestType. Warto zauważyć, że operacje spmllookuprequest oraz spmladdrequest zwracają specyficzne dla siebie obiekty LookupResponseType oraz AddResponseType. Natomiast operacja spmldeleterequest zwraca obiekt, będący bezpośrednią instancją podstawowego typu reprezentującego komunikat zwrotny SPML. Spowodowane jest to faktem, że specyfikacja wymaga, by operacja usuwania obiektu zarządzanego zwracała wyłącznie status wykonania żądania i ewentualne komunikaty o błędach. Parametry te zawarte są w podstawowym typie reprezentującym komunikat zwrotny SPML, więc nie ma potrzeby tworzenia bardziej szczegółowej implementacji tego typu. Operacje wyszukiwania i dodawania obiektu zarządzanego po wykonaniu żądania muszą z kolei zwracać dane względnie niestandardowe w stosunku do podstawowego typu komunikatu zwrotnego, czyli dane obiektu zarządzanego. Każda z metod usługowych opatrzona jest dwiema adnotacjami Pierwsza z tych adnotacji opisuje, w jaki sposób zwracany obiekt języka Java ma być mapowany do elementów języka XML. Przykładowo opisująca metodę spmllookuprequest() określa, że komunikat zwrotny powinien być mapowany do elementu o nazwie lookupresponse, znajdującego się w standardowej przestrzeni nazw języka SPML - urn:oasis:names:tc:spml:2:0 i ma być mapowany na część komunikatu o nazwie body. jednoznacznie wiąże metodę języka Java z odpowiadającą mu operacją zdefiniowaną w dokumencie WSDL. Przykładowo metoda spmllookuprequest mapowana jest na operację SPMLLookupRequest, która jednocześnie opisywana jest przez akcję SOAP opisywaną przez atrybut action o wartości Oprócz adnotacji opisujących całą metodę, istnieje jeszcze jedna która odnosi się do parametrów tej ostatniej. Mapuje ona obiekty języka Java na komunikaty żądania SPML. Przykładowo w metodzie spmllookuprequest() parametrem jest obiekt typu LookupRequestType, który wiązany jest do elementu XML o nazwie addrequest znajdującego się w przestrzeni nazw urn:oasis:names:tc:spml:2:0. Klasa SPMLServicesImpl Klasa SPMLServicesImpl zawiera konkretne implementacje usług SPML. Na Listingu 27 pokazany jest jej nagłówek oraz deklaracja wszystkich wykorzystywanych przez nią właściwości i obiektów pomocniczych.

51 51 Listing 27. Deklaracja nagłówka klasy SPMLServiceImpl oraz obiektów = SPMLRequestPortType, endpointinterface = com.pete.pjwstk.spml.v2008.spmlrequestporttype, targetnamespace = ) public class SPMLServicesImpl implements SPMLRequestPortType { private static final Log log = LogFactory.getLog(SPMLServicesImpl.class); public static String DEFAULT_TARGET_ID = PJWSTK ; public static String DEFAULT_PROFILE = urn:oasis:names:tc:spml:2.0:profiles:xsd ; public static String DEFAULT_ENTITY_NAME = User ; public static String[] SUPPORTED_CAPABILITIES = { urn:oasis:names:tc:spml:2:0:password, urn:oasis:names:tc:spml:2:0:suspend SpmlValidationService UserServices SPMLServicesUtils IDMServices SPMLValidator SPMLJobScheduler spmljobscheduler; Klasa opatrzona jest posiadającą właściwości: servicename nazwa tzw. portu WSDL, który definiuje wszystkie operacje, endpointinterface tzw. kwalifikowana nazwa interfejsu, w którym zdefiniowane są operacje implementowane przez klasę SPMLServicesImpl, targetnamespace docelowa przestrzeń nazw, do której należą elementy zdefiniowane przez plik WSDL, na podstawie którego implementowane są usługi. Klasa definiuje kilka pomocniczych zmiennych statycznych: log jest referencją do obiektu zarządzającego logowaniem zdarzeń w całej klasie, DEFAULT_TARGET_ID przechowuje nazwę jedynego celu obsługiwanego przez usługę, w tym przypadku jest to cel o nazwie PJWSTK, DEFAULT_PROFILE przechowuje jedyny obsługiwany w niniejszej implementacji profil języka SPML urn:oasis:names:tc:spml:2.0:profiles:xsd

52 52 SUPPORTED_CAPABILITIES jest listą jedynych wspieranych funkcjonalności, przy czym funkcjonalność core reprezentowana jest przez przestrzeń nazw urn:oasis:names:tc:spml:2:0 i zakłada się, że jest ona wspierana domyślnie, stąd też nie jest zwracana przez operację listtargets. Następna w kolejności jest deklaracja kilku zmiennych instancji dla obiektów pomocniczych opatrzonych Po analizie kodu całej klasy widać wyraźnie, że żadna z tych zmiennych nie posiada metody, która by ją w jakikolwiek sposób inicjalizowała. Dzieje się tak, dlatego, że inicjalizacja i przypisanie ich wartości wykonywane jest w ramach wstrzykiwania zależności pomiędzy powiązanymi ze sobą obiektami, które gwarantuje wykorzystana biblioteka Spring. Operacja ta ma miejsce poza obrębem klasy SPMLServicesImpl jak również poza obrębem stworzonego kodu źródłowego, stąd też mówi się o tzw. odwróceniu sterowania, gdzie kontrolę nad zależnościami przejmuje kontener obiektów Spring. W następnych punktach omówione zostaną metody implementujące operacje SPML stanowiące część projektowanej biblioteki. Metoda SPMLServicesImpl.spmlListTargetsRequest() Na Listingu 28 pokazana jest implementacja metody implementującej operację zwracania listy obsługiwanych Celów. Listing 28. Implementacja operacji public ListTargetsResponseType spmllisttargetsrequest(listtargetsrequesttype ltrequest) { log.debug("list targets..."); ListTargetsResponseType ltresponse = servicesutils.createresponse(ltrequest, ListTargetsResponseType.class); if (spmlvalidation.hasexecutionmodeissues(ltrequest, ltresponse) spmlvalidation.hasprofileissues(ltrequest.getprofile(), ltresponse)) { return ltresponse; TargetType target = new TargetType(); target.settargetid(default_target_id); target.setprofile(default_profile); SchemaType userschema = new SchemaType(); userschema.setref("http://localhost:8050/user xsd"); SchemaEntityRefType schemaentity = new SchemaEntityRefType(); schemaentity.setentityname(default_entity_name); schemaentity.settargetid(default_target_id); schemaentity.setiscontainer(false); userschema.getsupportedschemaentity().add(schemaentity); target.getschema().add(userschema); target.setcapabilities(new CapabilitiesListType()); for (String capname : SUPPORTED_CAPABILITIES) { CapabilityType capdata = new CapabilityType();

53 53 capdata.setnamespaceuri(capname); capdata.getappliesto().add(schemaentity); target.getcapabilities().getcapability().add(capdata); ltresponse.gettarget().add(target); return ltresponse; Niemal w każdej metodzie usługowej w pierwszej kolejności tworzony jest zawsze obiekt reprezentujący komunikat zwrotny, który zostanie zwrócony po odpowiednich dalszych modyfikacjach. Obiekt ten tworzony jest już na początku wywołania metod ze względu na operacje walidacji komunikatu żądania, które mają miejsce jeszcze przed wykonaniem konkretnej logiki biznesowej. Operacje te wykonywane są przez metody narzędziowe klasy SpmlValidationService i mogą one zwrócić informację o ewentualnych błędach, które zwykle skutkują przerwaniem wykonania całej operacji SPML. Każda z operacji zawiera walidację obiektu reprezentującego żądanie pod kątem trybu wykonania. Operacja listtargets sprawdza dodatkowo, czy przesłany profil języka jest przez usługę obsługiwany. Po pomyślnej fazie walidacji tworzony jest obiekt typu TargetType, reprezentujący obsługiwany pojedynczy cel. Przekazywane są mu dwie wartości DEFAULT_TARGET_ID i DEFAULT_PROFILE, reprezentujące odpowiednio jego nazwę jak i nazwę obsługiwanego profilu języka SPML. Gdy obiektu reprezentujący Cel zostanie wstępnie utworzony, następuje inicjalizacja obiektu reprezentującego schemat opisujący obiekt zarządzany. Schematy obiektu zarządzanego utworzone na tym etapie są jedynymi obowiązującym dokumentami opisującymi strukturę obiektu. Istotnym jest, by zawierały one same w sobie konkretną definicję schematu lub by zawierały do niego referencję w formacie zunifikowanego identyfikatora zasobów (ang. Unified Resource Identifier URI). W opisywanym przykładzie URI jest reprezentowany przez popularny w zastosowaniach sieciowych adres URL (ang. Unified Resource Locator). Instancja schematu może być czasami traktowana jako kontener na inne obiekty. W tym przypadku obiekt zarządzany nie może takich przechowywać, stąd też jego atrybutowi iscontainer przypisujemy wartość false. W dalszej kolejności inicjalizowane są obiekty reprezentujące obsługiwane funkcjonalności. Zarówno one jak i w/w schemat odnoszą się do utworzonego wcześniej obiektu typu TargetType reprezentującego Cel, toteż z nim zostają powiązane. Projektowana biblioteka obsługuje wyłącznie jeden Cel, który został nazwany PJWSTK. Metoda SPMLServicesImpl.spmlLookupRequest() Implementacja operacji lookup, wyszukującej i zwracającej obiekt zarządzany o podanym identyfikatorze przedstawiona jest na Listingu 29. Listing 29. Implementacja operacji public LookupResponseType spmllookuprequest(lookuprequesttype lookuprequest) { log.debug("lookup user...");

54 54 LookupResponseType lookupresponse = servicesutils.createresponse(lookuprequest, LookupResponseType.class); if (spmlvalidation.hasexecutionmodeissues(lookuprequest, lookupresponse) spmlvalidation.haspsoidissues(lookuprequest.getpsoid(), lookuprequest, lookupresponse) spmlvalidation.hastargetissues(lookuprequest.getpsoid().gettargetid(), lookupresponse)) { return lookupresponse; String username = extractusernamefrompsoid(lookuprequest.getpsoid()); com.pete.pjwstk.spml.service.entities.user founduser = userservices.finduser(username); PSOType pso = new PSOType(); PSOIdentifierType psoid = new PSOIdentifierType(); psoid.setid("user/" + username); pso.setpsoid(psoid); lookupresponse.setpso(pso); if (lookuprequest.getreturndata()!= ReturnDataType.IDENTIFIER) { User spmluser = servicesutils.constructspmluser(founduser, false); ExtensibleTypeCustom userwrapper = new ExtensibleTypeCustom(); userwrapper.getany().add(spmluser); pso.setdata(userwrapper); return lookupresponse; Podobnie jak w implementacji operacji listtargets, w operacji lookup najpierw tworzony jest obiekt reprezentujący komunikat zwrotny, po czym dokonywana jest walidacja danych. Operacja wyszukiwania użytkownika, jako jeden ze swoich parametrów przyjmuje identyfikator wyszukiwanego obiektu, toteż on w pierwszej kolejności zostaje sprawdzony pod kątem poprawności. Najpierw następuje sprawdzenie, czy identyfikator obiektu nie jest pusty, a następnie czy jest zgodny ze wzorcem User/<username>, gdzie <username> jest konkretną nazwą użytkownika składającą się z 8-11 znaków będących małymi lub dużymi literami lub cyframi. Przykładową poprawną nazwą użytkownika dla Celu obsługiwanego przez projektowaną bibliotekę jest User/xy Jeżeli format identyfikatora jest prawidłowy, to następuje sprawdzenie, czy jest on zarządzany przez w ramach Celu. Wszelkie błędy wykryte w przesłanym komunikacie żądania spowodują przerwanie wykonania operacji i wysłanie komunikatu zwrotnego do klienta razem z opisem zaistniałych problemów. Jeżeli powyższa walidacja powiedzie się, to następuje wyodrębnienie konkretnej nazwy użytkownika z przesłanego obiektu za pomocą metody SPMLServicesUtils.extractUsernameFromPsoId() oraz wyszukanie użytkownika za pomocą metody UserServices.findUser(). Wywołanie drugiej z tych metod wykona operację wyszukiwania użytkownika o danej nazwie w bazie danych PostgreSQL, która stanowi główne źródło danych dla przedmiotowego Środowiska.

55 55 Należy zwrócić uwagę, że obiekt reprezentujący wpis dotyczący użytkownika w pojedynczym źródle danych niekoniecznie musi być jedynym zasobem, na podstawie którego tworzona jest reprezentacja obiektu zarządzanego wysyłana do klienta. Jeżeli w skład Środowiska wchodzą np. dodatkowo serwer usług katalogowych, aplikacja biznesowa czy też jakaś inna baza danych, a do tego każde z nich zawiera charakterystyczna dla siebie fragmenty danych użytkownika, to zwykle można się spodziewać, że dopiero kompilacja tych informacji będzie stanowiła kompletny obiekt zarządzany. Na tym etapie wiadomo, że użytkownik na pewno istnieje, toteż po jego pobraniu z bazy danych konstruowany jest obiekt typu PSOType, reprezentujący konkretny obiekt PSO, po czym tworzony jest dla niego odpowiedni identyfikator reprezentowany przez PSOIdentifierType. Następnie, w zależności od wartości atrybutu returndata przesłanego w komunikacie żądania, odpowiednio obiekt ten inicjalizowany jest bardziej szczegółowymi danymi użytkownika lub też w komunikacie zwrotnym odsyłany jest wyłącznie sam jego identyfikator. Metoda SPMLServicesImpl.spmlAddRequest() Implementacja operacji add, dodającej nowy obiekt zarządzany przedstawiona jest na Listingu 30. Listing 30. Implementacja operacji public AddResponseType spmladdrequest(addrequesttype adduserrequest) { log.debug("add user..."); AddResponseType adduserresponse = servicesutils.createresponse(adduserrequest, AddResponseType.class); if (spmlvalidation.hasexecutionmodeissues(adduserrequest, adduserresponse) spmlvalidation.haspsoidissues(adduserrequest.getpsoid(), adduserrequest, adduserresponse) (adduserrequest.getpsoid()!= null && spmlvalidation.hastargetissues( adduserrequest.getpsoid().gettargetid(), adduserresponse)) spmlvalidation.hascontainerissues(adduserrequest.getcontainerid(), adduserresponse)) { return adduserresponse; User usertoadd = null; try { usertoadd = (User) adduserrequest.getdata().getany().get(0); catch (Exception e) { spmlvalidation.seterror(errorcode.custom_error, adduserresponse, "New user object has not been properly attached to the request!"); return adduserresponse; List<String> uservalidationerrors = spmlvalidation.validatespmluser(usertoadd); if (uservalidationerrors.size() > 0) { spmlvalidation.seterror(errorcode.custom_error, adduserresponse, uservalidationerrors); return adduserresponse;

56 56 com.pete.pjwstk.spml.service.entities.user dbuser = servicesutils.constructdatabaseuser(usertoadd); Set<OrganizationProduct> orgprods = new HashSet<OrganizationProduct>(); dbuser = userservices.adduser(dbuser, orgprods); idmservices.adduser(dbuser.getusername(), usertoadd.getpassword(), dbuser.getfirstname(), dbuser.getlastname(), dbuser.get ()); idmservices.assignroles(dbuser.getusername(), new HashSet<String>(Arrays.asList("CoolPeterRole"))); PSOType pso = new PSOType(); PSOIdentifierType psoid = new PSOIdentifierType(); psoid.setid("user/" + dbuser.getusername()); psoid.settargetid(default_target_id); pso.setpsoid(psoid); adduserresponse.setpso(pso); if (adduserrequest.getreturndata()!= ReturnDataType.IDENTIFIER) { User spmluser = servicesutils.constructspmluser(dbuser, false); ExtensibleTypeCustom userwrapper = new ExtensibleTypeCustom(); userwrapper.getany().add(spmluser); adduserresponse.getpso().setdata(userwrapper); return adduserresponse; Po utworzeniu obiektu reprezentującego komunikat zwrotny następuje walidacja komunikatu żądania. Poza standardowym sprawdzeniem trybu wykonania, sprawdzany jest jeszcze identyfikator obiektu PSO. W tym przypadku zgłaszany jest błąd invalididentifier, jeżeli identyfikator nie ma wymaganego formatu, lub błąd alreadyexists gdy obiekt o danym identyfikatorze już istnieje w Środowisku. Ponadto, jeżeli komunikat zwrotny zawiera element containerid, to zostaje zwrócony błąd invalidcontainment, gdyż projektowana biblioteka nie zakłada osadzania tworzonych obiektów w żadnych innych obiektach, które byłyby dla nich kontenerami. W następnej kolejności poprzez wywołanie metody adduserrequest.getdata().getany() z komunikatu żądania pobierany jest obiekt opakowujący obiekt zarządzany, który zawarty jest w elemencie data typu ExtensibleTypeCustom. Ten ostatni może przechowywać jeden lub więcej elementów typu any, będące rozszerzeniem języka XSD o możliwość definiowania elementów, których typy nie są znane w momencie deklarowania schematu. Zwykle zakłada się jednak, że zawartość elementu data jest pojedynczym dokumentem XML, stąd też w powyższym przykładzie pobierany jest on przy użyciu indeksu 0, jako pierwszy element kolekcji języka Java. Jeżeli pobieranie reprezentacji nowego obiektu zarządzanego nie powiedzie się, np. z powodu wyjątków języka Java IndexOutOfBoundsException lub ClassCastException, to komunikat zwrotny zostaje zwrócony z kodem błędu customerror i krótkim opisem. Po pobraniu nowego obiektu zarządzanego z komunikatu żądania następuje faza walidacji danych biznesowych użytkownika, takich jak poprawność imienia, nazwiska, hasła czy adresu e mail. Jeżeli te dane są poprawne, to za pomocą metody SPMLServicesUtils.constructDatabaseUser() zostaje skonstruowany nowy obiekt User będący encją umożliwiającą sprawne mapowanie tworzonego

57 57 użytkownika w relacyjnej bazie danych. Wywołanie metody UserServices.addUser(), korzystając ze wspomnianej encji, utworzy odpowiedni rekord użytkownika w bazie danych. Wywołanie metod IDMServices.addUser() oraz IDMServices.assignRoles() jest w zasadzie przykładem integracji biblioteki z systemem Sun Identity Manager, toteż logika ta zostanie opisana w kolejnym rozdziale. Na zakończenie wywołania na obiekcie komunikatu zwrotnego zostaje ustawiony identyfikator nowo utworzonego obiektu zarządzanego. Jeżeli atrybut komunikatu żądania returndatatype jest różny od wartości identifier, to znaczy że strona kliencka oczekuje, że po wykonaniu operacji add zostaną jej zwrócone pełne dane obiektu zarządzanego. W takim przypadku za pomocą metody SPMLServicesUtils.constructSPMLUser() zostaje skonstruowany obiekt, który biblioteka JaxB wykorzystywana przez Apache CXF będzie mogła wykorzystać do łatwej serializacji (ang. marshalling) użytkownika do postaci XML. Obiekt ten teoretycznie powinien zostać ustawiony na elemencie pso komunikatu zwrotnego. W praktyce okazuje się, że bez opakowania obiektu użytkownika w obiekt typu ExtensibleTypeCustom, biblioteka JaxB zgłasza błędy serializacji. Metoda SPMLServicesImpl.spmlModifyRequest() Na Listingu 31 przedstawiona jest implementacja operacji modify, modyfikującej istniejący obiekt zarządzany. Listing 31. Implementacja operacji public ModifyResponseType spmlmodifyrequest(modifyrequesttype modifyrequest) { log.debug("modify user..."); ModifyResponseType modifyresponse = servicesutils.createresponse(modifyrequest, ModifyResponseType.class); if (spmlvalidation.hasexecutionmodeissues(modifyrequest, modifyresponse) spmlvalidation.haspsoidissues(modifyrequest.getpsoid(), modifyrequest, modifyresponse) spmlvalidation.hastargetissues(modifyrequest.getpsoid().gettargetid(), modifyresponse)) { return modifyresponse; if (modifyrequest.getmodification().size() == 0) { spmlvalidation.seterror(errorcode.malformed_request, modifyresponse, "Please provide at least 1 modification!"); return modifyresponse; String subjectusername = extractusernamefrompsoid(modifyrequest.getpsoid()); com.pete.pjwstk.spml.service.entities.user userent = userservices.finduser(subjectusername); User currentspmluser = servicesutils.constructspmluser(userent, true); try {

58 58 Document doc = servicesutils.applymodifications(currentspmluser, modifyrequest.getmodification(), modifyresponse); if (doc == null) { return modifyresponse; Document orderedmodifieduser = getorderedxmldocument(doc); String userdocumentxml = getuserxmldocument(orderedmodifieduser); log.info("user XML document:\n " + userdocumentxml); spmlvalidator.validateuser(userdocumentxml); User modifiedspmluser = getspmluser(orderedmodifieduser); if (spmlvalidation.hasunmodifiablepropertiesissues(userent, modifiedspmluser, modifyresponse)) { return modifyresponse; userent = servicesutils.constructdatabaseuser(modifiedspmluser); DiffUser diffuser = new SPMLServicesUtils.DiffUser(currentSPMLUser, modifiedspmluser); idmservices.updateuserroles(subjectusername, diffuser.getproductsadded(), diffuser.getproductsremoved()); userservices.modifyuser(userent); // Returning the response PSOIdentifierType psoid = new PSOIdentifierType(); psoid.setid(modifyrequest.getpsoid().getid()); psoid.settargetid(default_target_id); PSOType pso = new PSOType(); pso.setpsoid(psoid); modifyresponse.setstatus(success); modifyresponse.setpso(pso); if (modifyrequest.getreturndata()!= ReturnDataType.IDENTIFIER) { userent = userservices.finduser(subjectusername); currentspmluser = servicesutils.constructspmluser(userent, false); ExtensibleTypeCustom datawrapper = new ExtensibleTypeCustom(); datawrapper.getany().add(currentspmluser); pso.setdata(datawrapper); return modifyresponse; catch (Exception e) { log.error(e); throw new ServiceError("Error occured when processing modify request", e); return modifyresponse;

59 59 Walidacja komunikatu reprezentującego żądanie modyfikacji obiektu jest dosyć podobna do tej przeprowadzonej w operacji add. Zostaje dodatkowo rozszerzona o sprawdzenie czy liczba przesłanych elementów hermetyzujących poszczególne modyfikacje jest większa niż 0. Następnie za pomocą metody SPMLServicesUtils.extractUsernameFromPsoId() zostaje wyodrębniona właściwa nazwa modyfikowanego użytkownika, a jego dane pobrane są z bazy danych poprzez wywołanie metody UserServices.findUser(). Po pobraniu zostają one za pomocą metody SPMLServicesUtils.constructSPMLUser() przekształcone do obiektu użytkownika zgodnego ze schematem wspieranym przez projektowane umowne środowisko SPML. Zabieg ten ma to by ułatwić dalsze operacje przekształcające. Operacje dodawania, zastępowania i usuwania właściwości obiektu PSO w zakresie wynikającym ściśle z samej specyfikacji wykonywane są w metodzie SPMLServicesUtils.applyModifications(). Zostanie ona szczegółowo opisana w dalszej części działu. W tym momencie najważniejsze jest to, że przyjmuje ona trzy parametry aktualny obiekt zarządzany reprezentujący użytkownika, listę modyfikacji, które mają zostać na nim przeprowadzone oraz referencję do komunikatu zwrotnego całej operacji modify. Jeżeli w trakcie próby zaaplikowania modyfikacji zostaną napotkane jakieś błędy, to wspomniana metoda zwróci null i ustawi w komunikacie zwrotnym odpowiednie kody błędów, a wykonanie całej operacji modify zostanie wstrzymane. Jeżeli wykonanie powyższej logiki powiedzie się, to zmodyfikowany obiekt zarządzany powinien być gotowy do uaktualnienia w przechowujących go źródłach danych. Zanim jednak to nastąpi, niezbędna jest walidacja dokumentu XML reprezentującego zmodyfikowanego użytkownika w oparciu o opisujący go schemat XSD. Spowodowane jest to sposobem, w jaki metoda SPMLServicesUtils.applyModifications() dokonuje poszczególnych modyfikacji nie sprawdza ona czy np. nie nastąpiła modyfikacja polegająca na kilkukrotnym dodaniu elementu LastName do korzenia modyfikowanego dokumentu. Załóżmy, że komunikat żądania modyfikacji wygląda jak Listingu 32. Listing 32. Przykład żądania modyfikacji <urn:modifyrequest xmlns:urn= urn:oasis:names:tc:spml:2:0 xmlns:ns5= > <urn:psoid ID= User/sg targetid= pjwstk /> <urn:modification modificationmode= add > <urn:component namespaceuri= path=. > <namespaceprefixmap namespace= prefix= u /> </component> <urn:data> <ns5:lastname xmlns= > Kowalski </ns5:lastname > </urn:data> </urn:modification> <urn:modification modificationmode= add > <urn:component namespaceuri= path=. > <namespaceprefixmap namespace=

60 60 prefix= u /> </component> <urn:data> <ns5: LastName xmlns= >Nowak</ns5:LastName > </urn:data> </urn:modification> </urn:modifyrequest> Bezpośrednio po wywołaniu metody SPMLServicesUtils.applyModifications() dokument XML reprezentujący użytkownika mógłby wyglądać jak na Listingu 33. Listing 33. Przykładowy wynik działania metody SPMLServicesUtils.applyModifications() <User> <EmployeeNumber>123456</ EmployeeNumber> <Password>abc123</Password> <CompanyCode>XY</CompanyCode> <FirstName>Jan</FirstName> <LastName>Kowalski</LastName> <LastName>Nowak</LastName> <Product>Aircraft Manager</Product> </User> Jak widać element LastName reprezentujący nazwisko użytkownika został zduplikowany. Poza przypadkami, gdy Środowisko rzeczywiście pozwalałoby na przechowywanie dwóch nazwisk użytkownika (przez co musiałoby być to zgodne ze wspieranym schematem XSD), taki dokument jest błędny. Podobnie rzecz ma się w przypadku zmiany wartości któregokolwiek z istniejących atrybutów obiektu zarządzanego na niezgodny z wymaganym schematem XSD. Zarówno w tych sytuacjach jak i w podobnych chcemy mieć pewność, że nie pozwalamy na tworzenie w źródłach danych wpisów, które nie są zgodne z przyjętymi regułami. Wspomniana walidacja poprzedzona jest uporządkowaniem elementów dokumentu XML tak, by ich kolejność była akceptowalna przez biblioteki programistyczne języka Java służące do walidacji dokumentów opartych o obiektowy model dokumentu (ang. Document Object Model DOM). Uporządkowanie to ma miejsce za pomocą metody SPMLServicesUtils.getOrderedXMLDocument() przyjmującej jako parametr obiekt hermetyzujący wspomniany dokument. Po pomyślnie przeprowadzonej walidacji uporządkowany dokument przekształcany jest za pomocą metody SPMLServicesUtils.getSPMLUser() do obiektu SPML reprezentującego użytkownika, a następnie sprawdzany pod kątem próby modyfikacji atrybutów, które raz ustawione powinny być wyłącznie tylko do odczytu. Mowa o EmployeeNumber numerze użytkownika, CompanyCode kodzie organizacji. Dodatkowo sprawdza się, czy nie następuje próba zmodyfikowania hasła, gdyż operacja ta dostępna jest wyłącznie dla operacji add (w przypadku ustawienia hasła dla nowego obiektu PSO) i setpassword (w przypadku próby modyfikacji hasła dla istniejącego obiektu PSO). Po przeprowadzeniu wszystkich powyższych operacji za pomocą metody SPMLServicesUtils.constructDatabaseUser() zostaje skonstruowana encja hermetyzująca użytkownika, która dalej zostanie wykorzystana do zapisania użytkownika do bazy danych.

61 61 Do komunikatu zwrotnego, w zależności od wartości atrybutu żądania returndata, zostaje dodana pełna reprezentacja zmodyfikowanego obiektu lub też wyłącznie jego identyfikator. Metoda SPMLServicesUtils.applyModifications() Wspomniano już, że znaczna część operacji aplikowania modyfikacji w istniejącym obiekcie zarządzanym jest wykonywana przez metodę SPMLServicesUtils.applyModifications(). Ze względu na jej stopień skomplikowania nie zostanie tu umieszczony jej pełny listing, lecz zostaną opisane jej główne części. Metoda ta przyjmuje 3 parametry: public Document applymodifications(user spmluser, List<ModificationType> modifications, ModifyResponseType modifyresponse) throws Exception { Pierwszy z nich reprezentuje użytkownika pobranego z bazy danych i przekształconego do postaci zgodnej ze wspieranym schematem XSD dla obiektów zarządzanych. Drugim parametrem jest lista modyfikacji, które mają zostać zaaplikowane dla tego użytkownika. Natomiast trzecim parametrem jest referencja do obiektu reprezentującego komunikat zwrotny. Na samym początku zostaje utworzony kontekst JaxB, któremu przekazana jest nazwa klasy wygenerowanej ze wspieranego schematu XSD. Następnie na podstawie kontekstu tworzony jest obiekt typu Marshaller, służący do serializowania obiektów Java do postaci XML. JAXBContext jc = JAXBContext.newInstance(User.class); Marshaller marshaller = jc.createmarshaller(); marshaller.setproperty(marshaller.jaxb_formatted_output, true); W następnym kroku tworzony jest obiekt strumienia, który zaraz potem wykorzystany jest do wypisania serializowanego obiektu użytkownika do logów systemowych. ByteArrayOutputStream baos = new ByteArrayOutputStream(); marshaller.marshal(spmluser, baos); W kolejnych linijkach tworzona jest fabryka obiektów budujących dokumenty zgodne ze standardem org.w3c.dom oraz sam obiekt budujący dokumenty. Ten ostatni zostanie wykorzystany do utworzenia nowego, pustego dokumentu, który następnie zostanie wypełniony serializowanym obiektem zarządzanym. DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); DocumentBuilder db = dbf.newdocumentbuilder(); Document doc = db.newdocument(); marshaller.marshal(spmluser, doc); Następnie tworzona jest fabryka zapytań języka XPath. Jest on jedynym obsługiwanym przez projektowaną bibliotekę językiem służącym do wyszukiwania fragmentów obiektu zarządzanego, które następnie zostaną poddane modyfikacjom. Kolejna linijka inicjalizuje kolekcję, która będzie gromadziła

62 62 wszystkie informacje dotyczące zapytań wykonanych językiem XPath, które nie zwróciły żadnej wartości. XPathFactory xpf = XPathFactory.newInstance(); Set<String> xpatherrormsgs = new TreeSet<String>(); W tym momencie następuje początek iteracji po modyfikacjach wysłanych w komunikacie żądania. W ramach każdej iteracji zostaną przeprowadzone złożone operacje dodawania, usuwania i zastępowania elementów wchodzących w skład dokumentu reprezentującego obiekt zarządzany. Na początku zawsze tworzony jest obiekt reprezentujący zapytanie w języku XPath. Następnie na tym obiekcie ustawiany jest kontekst przestrzeni nazw, na którym zapytanie ma mieć punkt odniesienia, po czym jest on wykorzystany do kompilacji elementu path, będącego rzeczywistym zapytaniem XPath. for (ModificationType modification : modifications) { XPath xpath = xpf.newxpath(); xpath.setnamespacecontext(prefixmaptocontext(modification.getcomponent().getnamespaceprefixmap())); XPathExpression xpathexpr = xpath.compile(modification.getcomponent().getpath());. Mając skompilowane zapytanie XPath można je wykorzystać do wykonania konkretnego wyszukiwania na dokumencie hermetyzującym obiekt PSO. Jeżeli nie zostaną znalezione żadne węzły, na których należy wykonać modyfikację, to lista błędów zostaje powiększona o komunikat opisujący zapytanie jako nieprawidłowe. NodeList selectednodes = (NodeList) xpathexpr.evaluate(doc.getdocumentelement(), XPathConstants.NODESET); if (selectednodes.getlength() == 0) { xpatherrormsgs.add( Following modification is incorrect: + modification.getcomponent().getpath()); Jeżeli tryb modyfikacji jest trybem dodawania nowego elementu lub zastępowania istniejącego i w elemencie modification brak jest elementu nowego lub zastępującego, to do komunikatu zwrotnego zostaje dodany kod błędu customerror i cała metoda SPMLServicesUtils.applyModifications() zwraca null. if (modification.getmodificationmode()!= ModificationModeType.DELETE && (modification.getdata() == null modification.getdata().getany().size() == 0)) { spmlvalidation.seterror(errorcode.custom_error, modifyresponse, Data subelement is empty or not in place ); return null; Dla trybu dodawania liczba elementów nowych może być większa lub równa 1. Do tego celu tworzona jest pomocnicza tablica dokumentów zawierająca fragmenty nowych elementów wyodrębnione z aktualnej modyfikacji.

63 63 int nfrags = modification.getdata().getany().size(); Document modfrags[] = new Document[nFrags]; for (int i = 0; i < nfrags; i++) { modfrags[i] = db.newdocument(); marshaller.marshal(modification.getdata().getany().get(i),modfrags[i]); Wspomniano już wielokrotnie, że modyfikacja może mieć 3 tryby: dodawania (ang. add), usuwania (ang. delete) i zastępowania (ang. replace). Dla operacji dodawania następuje iteracja po węzłach wybranych za pomocą zapytania XPath. W zagnieżdżonej iteracji do każdego z nich zostaną dodane nowe elementy. switch (modification.getmodificationmode()) { case ADD: for (int i = 0; i < selectednodes.getlength(); i++) { for (Document frag : modfrags) { selectednodes.item(i).appendchild(doc.importnode(frag.getdocumentelement(),true)); break; Jeżeli trybem modyfikacji jest usuwanie, to następuje iteracja po wszystkich węzłach wybranych zapytaniem XPath i usunięcie ich z węzła rodzica. switch (modification.getmodificationmode()) { case DELETE: for (int i = 0; i < selectednodes.getlength(); i++) { Node node = selectednodes.item(i); node.getparentnode().removechild(node); break; W przypadku trybu modyfikacji polegającego na zamianie istniejących wartości atrybutów obiektu zarządzanego liczba zamienników musi być dokładnie równa 1. switch (modification.getmodificationmode()) { case REPLACE: if (modfrags.length!= 1) { spmlvalidation.seterror(errorcode.custom_error,modifyresponse, There should be exactly 1 replacement element! );

64 64 return null; log.trace( mod frag: + modfrags[0].getdocumentelement()); for (int i = 0; i < selectednodes.getlength(); i++) { Node node = selectednodes.item(i); node.getparentnode().replacechild( doc.importnode(modfrags[0].getdocumentelement(),true), node); break; Po zakończeniu iteracji sprawdzona jest liczba wszystkich błędnie wykonanych zapytań XPath. Jeżeli jest ona większa od 0, to całe żądanie modyfikacji uważane jest za błędne, a metoda SPMLServicesUtils.applyModifications() zwraca null. W przeciwnym wypadku, zwrócony jest obiekt zmodyfikowany przez wyżej opisane operacje. if (xpatherrormsgs.size() > 0) { spmlvalidation.seterror(errorcode.custom_error, modifyresponse, xpatherrormsgs.toarray(new String[] {)); return null; return doc; Metoda SPMLServicesImpl.spmlValidatePasswordRequest() Na Listingu 34 przedstawiono implementację operacji walidowania hasła dla obiektu zarządzanego. Listing 34. Implementacja operacji public ValidatePasswordResponseType spmlvalidatepasswordrequest( ValidatePasswordRequestType vprequest) { log.debug("validate password..."); ValidatePasswordResponseType vpresponse = servicesutils.createresponse(vprequest, ValidatePasswordResponseType.class); if (spmlvalidation.hasexecutionmodeissues(vprequest, vpresponse) spmlvalidation.haspsoidissues(vprequest.getpsoid(), vprequest, vpresponse)) { return vpresponse; vpresponse.setvalid(!spmlvalidation.haspasswordinvalidcharacters(vprequest.getpassword())); return vpresponse;

65 65 Operacja ta, jak wiadomo, służy sprawdzeniu czy hasło przesłane w komunikacie żądania posiada wartość, która byłaby prawidłowa, gdyby zostało ono ustawione dla obiektu PSO za pośrednictwem operacji add lub setpassword. Na powyższym listingu atrybutowi valid komunikatu zwrotnego przypisywana jest wartość logiczna zwrócona przez metodę SpmlValidationService.hasPasswordInvalidCharacters(). Metoda ta nie robi nic innego oprócz delegacji wywołania do metody SpmlValidationService.hasInvalidCharacters() sprawdzającej, czy podane hasło zawiera znaki inne niż małe litery alfabetu lub cyfry 0-9 i czy jego długość wynosi dokładnie 7. Implementacja powyższej metody jest dosyć prosta. W produkcyjnych zastosowaniach korporacyjnych pula dopuszczalnych znaków oraz długość hasła są dużo większe. Ponadto stosuje się sprawdzenie historii wszystkich haseł użytkownika, by wymusić stosowanie innego hasła za każdym razem. Przy wybraniu strategii walidacji i ustawiania hasła należy zawsze brać pod uwagę fakt, że podsystemy Środowiska, do których hasło jest zazwyczaj propagowane posiadają własne polityki bezpieczeństwa. Metoda SPMLServicesImpl.spmlSetPasswordRequest() Implementacja ustawiania hasła obiektu zarządzanego została przedstawiona na Listingu 35. Listing 35. Implementacja operacji public ResponseType spmlsetpasswordrequest(setpasswordrequesttype sprequest) { log.debug("set password..."); ResponseType spresponse = servicesutils.createresponse(sprequest, ResponseType.class); if (spmlvalidation.hasexecutionmodeissues(sprequest, spresponse) spmlvalidation.haspsoidissues(sprequest.getpsoid(), sprequest, spresponse)) { return spresponse; if (spmlvalidation.haspasswordissues(sprequest.getpassword(), spresponse)) { return spresponse; if (!StringUtils.isBlank(spRequest.getCurrentPassword())) { spresponse.geterrormessage().add( "Warning: the currentpassword attribute is not supported"); String username = extractusernamefrompsoid(sprequest.getpsoid()); userservices.updateuserpassword(username, sprequest.getpassword()); idmservices.setpassword(username, sprequest.getpassword()); return spresponse; Po uprzednim utworzeniu obiektu reprezentującego komunikat zwrotny oraz wstępnej walidacji znanej z wcześniej opisanych metod, następuje sprawdzenie wartości elementu currentpassword. Ten

66 66 opcjonalny element, który może reprezentować aktualne hasło użytkownika nie jest w tym przypadku wspierany. Gdyby jednak został przesłany w żądaniu, generowane jest odpowiednie ostrzeżenie, które zostaje dołączone do komunikatu zwrotnego, lecz cała operacja ustawiania hasła jest kontynuowana. Hasło zostaje najpierw ustawione w bazie danych za pomocą metody UserServices.updateUserPassword(), a następnie zostaje ono propagowane do systemu Sun Identity Manager za pomocą metody IDMServices.setPassword(). Metoda SPMLServicesImpl.spmlResetPassword() Na Listingu 36 przedstawiona jest implementacja metody ustawiania hasła na wartość losową. Listing 36. Implementacja operacji public ResetPasswordResponseType spmlresetpasswordrequest( ResetPasswordRequestType rprequest) { log.debug("reset password..."); ResetPasswordResponseType rpresponse = servicesutils.createresponse(rprequest, ResetPasswordResponseType.class); if (spmlvalidation.hasexecutionmodeissues(rprequest, rpresponse) spmlvalidation.haspsoidissues(rprequest.getpsoid(), rprequest, rpresponse)) { return rpresponse; String generatedpassword = UUID.randomUUID().toString().replaceAll("-", "").substring(0, 7); String username = extractusernamefrompsoid(rprequest.getpsoid()); userservices.updateuserpassword(username, generatedpassword); idmservices.setpassword(username, generatedpassword); rpresponse.setpassword(generatedpassword); return rpresponse; Generowanie losowego hasła ma miejsce w metodzie UUID.randomUUID(). Jest to standardowa metoda języka Java do generowania tzw. unikatowych identyfikatorów uniwersalnych (ang. Universally Unique Identifier UUID). Założeniem generowania tej 128-bitowej wartości jest przydzielanie identyfikatorów, które nawet po utworzeniu w heterogenicznych środowiskach będą globalnie niepowtarzalne. Wygenerowany łańcuch zostaje skrócony do 7 znaków, a następnie zapisany w rekordzie modyfikowanego użytkownika w bazie danych oraz propagowany do odpowiadającej mu pozycji w instancji systemu Sun Identity Manager. Po wykonaniu tych operacji hasło umieszczane jest w elemencie password komunikatu zwrotnego. Metoda SPMLServicesImpl.spmlExpirePasswordRequest() Operacja wygaszania ważności hasła przedstawiona jest na Listingu 37.

67 67 Listing 37. Implementacja operacji public ResponseType spmlexpirepasswordrequest(expirepasswordrequesttype eprequest) { log.debug("expire password..."); ResponseType epresponse = servicesutils.createresponse(eprequest, ResponseType.class); if (spmlvalidation.hasexecutionmodeissues(eprequest, epresponse) spmlvalidation.haspsoidissues(eprequest.getpsoid(), eprequest, epresponse)) { return epresponse; if (eprequest.getremaininglogins() > 1) { spmlvalidation.seterror(errorcode.custom_error, epresponse, "The remaininglogins attribute is not supported."); return epresponse; String username = extractusernamefrompsoid(eprequest.getpsoid()); idmservices.expirepassword(username); return epresponse; Wyżej przedstawiona operacja w gruncie rzeczy nie wspiera atrybutu remaininglogins, gdyż specyfikacja SPML nie opisuje, jakie jest jego zastosowanie. Dla celów niniejszej implementacji przyjęto, że jego wartość równa mniejsza niż 2 jest dopuszczalna. Wartość większa powoduje zwrócenie komunikatu zwrotnego z kodem błędu customerror. Należy zwrócić uwagę, że ze względu na prostotę przedmiotowego Środowiska wygaszanie hasła ograniczone jest wyłącznie do propagowania tego żądania do instancji systemu Sun Identity Manager. Metoda SPMLServicesImpl.spmlSuspendRequest() Na Listingu 38 przedstawiona jest operacja zawieszania funkcjonowania obiektu zarządzanego. Listing 38. Implementacja operacji public ResponseType spmlsuspendrequest(suspendrequesttype susrequest) { log.debug("suspend user..."); ResponseType susresponse = servicesutils.createresponse(susrequest, ResponseType.class); if (spmlvalidation.hasexecutionmodeissues(susrequest, susresponse) spmlvalidation.haspsoidissues(susrequest.getpsoid(), susrequest, susresponse)) { return susresponse; String username = extractusernamefrompsoid(susrequest.getpsoid()); XMLGregorianCalendar xmlgregcalendar = susrequest.geteffectivedate();

68 68 Date now = Calendar.getInstance().getTime(); if (xmlgregcalendar == null xmlgregcalendar.togregoriancalendar().before(now) xmlgregcalendar.togregoriancalendar().equals(now)) { idmservices.suspend(username); else { spmljobscheduler.schedulesuspendjob(username, xmlgregcalendar.togregoriancalendar().gettime()); return susresponse; Zawieszanie funkcjonowania obiektu PSO na przykładzie powyższej metody sprowadza się do zawieszenia go w systemie IDM. Po wykonaniu wstępnej walidacji danych pobierana jest wartość opcjonalnego atrybutu effectivedate. Jeżeli nie jest on ustawiony lub data, na którą wskazuje jest datą aktualną lub minioną, to żądanie zostaje spropagowane do instancji IDM. W przeciwnym wypadku zostaje wywołana metoda SPMLJobScheduler.scheduleSuspendJob(), która korzystając z zaimplementowanego w przedmiotowej bibliotece mechanizmu planowania zadań tworzy zadanie zawieszania obiektu PSO. Zostanie ono uruchomione w czasie opisanym przez atrybut effectivedate. Metoda SPMLServicesImpl.spmlResumeRequest() Na Listingu 39 przedstawiono implementację operacji wznawiania funkcjonowania obiektu PSO. Listing 39. Implementacja operacji public ResponseType spmlresumerequest(resumerequesttype resrequest) { log.debug("resume user..."); ResponseType susresponse = servicesutils.createresponse(resrequest, ResponseType.class); if (spmlvalidation.hasexecutionmodeissues(resrequest, susresponse) spmlvalidation.haspsoidissues(resrequest.getpsoid(), resrequest, susresponse)) { return susresponse; String username = extractusernamefrompsoid(resrequest.getpsoid()); XMLGregorianCalendar xmlgregcalendar = resrequest.geteffectivedate(); Date now = Calendar.getInstance().getTime(); if (xmlgregcalendar == null xmlgregcalendar.togregoriancalendar().before(now) xmlgregcalendar.togregoriancalendar().equals(now)) { idmservices.resume(username); else { spmljobscheduler.scheduleresumejob(username, xmlgregcalendar.togregoriancalendar().gettime()); return susresponse;

69 69 Jak widać implementacja tej operacji jest niemal identyczna z operacją zawieszania funkcjonowania obiektu PSO. Jedyną różnicą jest tutaj warunkowe delegowanie żądań do odpowiednich metod wznawiających funkcjonowanie PSO IDMServices.resume() oraz SPMLJobScheduler.scheduleResumeJob(). Metoda SPMLServicesImpl.spmlActiveRequest() Na Listingu 40 opisano metodę sprawdzającą czy obiekt PSO jest niezawieszony. Listing 40. Implementacja operacji public ActiveResponseType spmlactiverequest(activerequesttype activerequest) { log.debug("check user active..."); ActiveResponseType activeresponse = servicesutils.createresponse(activerequest, ActiveResponseType.class); if (spmlvalidation.hasexecutionmodeissues(activerequest, activeresponse) spmlvalidation.haspsoidissues(activerequest.getpsoid(), activerequest, activeresponse)) { return activeresponse; boolean isactive = idmservices.isactive(extractusernamefrompsoid(activerequest.getpsoid())); activeresponse.setactive(isactive); return activeresponse; Jedynym wyznacznikiem funkcjonowania obiektu PSO jest sprawdzenie jego statusu w systemie Sun Identity Manager za pomocą metody IDMServices.isActive(). Wartość logiczna zwrócona przez tę metodę przekazywana jest do atrybutu active komunikatu zwrotnego Obsługa błędów W przypadku wystąpienia błędu, który nie zostanie obsłużony w samej implementacji metod usługowych specyfikacja SOAP rekomenduje zwrócenie komunikatu błędu podobnego do przedstawionego na Listingu 41. Listing 41. Przykład standardowego komunikatu błędu SOAP <soap:fault xmlns:soap= > <faultcode>processingerror</faultcode> <faultstring>an undefined error occurred</faultstring> <detail> <GenericFault xmlns= > <detailmessage>more details here...</detailmessage> <code>code9</code> </GenericFault> </detail>

70 70 </soap:fault> Okazuje się jednak, że specyfikacja SPML całkowicie wyklucza zwracanie powyższego elementu Fault. Poza tym, że do reprezentacji błędów walidacji i wszelkich nieoczekiwanych wyjątków czasu wykonania wymusza stosowanie zdefiniowanych przez nią kodów błędów, nie określa ona wprost jaki konkretnie element ma zostać zwrócony stronie klienckiej. Stąd też przedmiotowa biblioteka wykorzystuje element responsetype, będący bezpośrednią instancją typu ResponseType, czyli bazowego elementu dla komunikatów zwrotnych. Zwrócenie elementu Fault zamiast responsetype możliwe jest dzięki mechanizmowi tzw. obiektów przechwytujących (ang. interceptors) wbudowanych w bibliotekę Apache CXF. W razie wystąpienia wyjątku następuje jego propagacja do obiektu klasy SPMLOutFaultInterceptor. Z łańcucha wywołań dla pojedynczego żądania usuwa on obiekt przechwytujący służący do tworzenia standardowych komunikatów błędów. Metodę odpowiedzialną za tę operację przedstawiono na Listingu 42. Listing 42. Metoda SPMLOutFaultInterceptor.removeSoap11InterceptorFromChain() usuwanie obiektu tworzącego standardowe komunikaty błędów SOAP private void removesoap11interceptorfromchain(soapmessage msg) { ListIterator itr = msg.getinterceptorchain().getiterator(); Interceptor soap11fault = null; while (itr.hasnext()) { Interceptor interceptor = (Interceptor) itr.next(); if (interceptor instanceof Soap11FaultOutInterceptor interceptor.getclass().getname().equals(soap11_fault_interceptor)) { soap11fault = interceptor; msg.getinterceptorchain().remove(soap11fault); Pełna postać przykładowego zwracanego komunikatu zwrotnego, opisującego generyczny błąd czasu wykonania w przedmiotowej bibliotece przedstawiona jest na Listingu 43. Listing 43. Generyczny komunikat zwrotny błędu SPML <responsetype xmlns= urn:oasis:names:tc:spml:2:0 error= customerror status= failure > <errormessage>unexpected error occurred when processing request abc</errormessage> </responsetype> Należy zwrócić uwagę, że brak jest w nim identyfikatora komunikatu żądania requestid, który zgodnie ze specyfikacją SPML powinien zostać zwrócony stronie klienckiej. Spowodowane jest to faktem, że niekiedy nieobsłużone błędy są np. wynikiem problemów z parsowaniem żądania, przez co wyodrębnienie z niego jego identyfikatora jest niemożliwe.

71 Niskopoziomowa walidacja komunikatów Specyfikacja SPML jest bardzo szczegółowa w kwestii szeroko pojętej walidację komunikatów żądań. Ogólnie rzecz biorąc każdy z opisanych kodów błędów odnosi się w mniejszym lub większym stopniu do nieprawidłowego formatu lub wartości danych odebranych od strony klienckiej. Przedmiotowa biblioteka implementuje jednowarstwową walidację żądań. W systemach produkcyjnych odpowiada ona za sprawdzanie komunikatów pod kątem biznesowym, np. czy dany obiekt już istnieje w Środowisku, czy podany adres należy do domeny będącej w puli dopuszczalnej dla danej organizacji itd. Brakuje w niej natomiast niskopoziomowej walidacji, która w wielu przypadkach okazuje się być nieodzowna. Większość szkieletów programistycznych zaimplementowanych w języku Java, które służą do tworzenia usług sieciowych dokonuje transformacji komunikatów przychodzących i wychodzących z języka XML na obiekty Java i na odwrót. Transformacje takie nazywają się odpowiednio deserializacją i serializacją. Przy wstępnym sprawdzaniu komunikatu przychodzącego można napotkać na 2 problemy. Po pierwsze może się okazać, że wcale nie jest on poprawnym dokumentem XML. Po drugie nawet, jeżeli jest on w formacie XML, to może mieć strukturę niezgodną z licznymi schematami XSD dostarczonymi wraz ze specyfikacją lub schematem odpowiadającym za opis struktury dokumentu reprezentującego obiekt PSO. W obydwu przypadkach jakakolwiek dalsza jego deserializacja do postaci Java oraz przetwarzanie pod kątem biznesowym jest niemożliwe. Żadna konkretna operacja SPML nie zostanie wywołana, a przez to walidacja biznesowa nie będzie miała miejsca. W takiej sytuacji najczęściej nie można jednoznacznie zweryfikować, jakie były intencje strony klienckiej odnośnie wywoływanej operacji SPML, przez co utworzenie komunikatu zwrotnego specyficznego dla określonej operacji jest niemożliwe. Z tego względu, podobnie jak to ma miejsce w przypadku obsługi błędów nieprzechwyconych w warstwie logiki biznesowej, konieczne jest zwracanie generycznego komunikatu zwrotnego w postaci elementu responsetype opatrzonego kodem błędu malformedrequest.

72 72 7. Przykład użycia biblioteki integracja z Sun Identity Manager Niniejszy rozdział pokrótce przedstawi przykładowe wykorzystanie przedmiotowej biblioteki SPML w integracji z istniejącym systemem Sun Identity Manager. W tym celu zaprojektowano proste Środowisko przedstawione na Diagramie 5. Diagram 5. Architektura przykładowego Środowiska Środowisko IDM Repozytorium IDM IDM Apache Directory Server (LDAP) Baza PostgreSQL Serwer Jetty (usługi SPML) Serwer Tomcat (Content Center) Serwer Tomcat (Admin Panel) Jak już wspomniano przedmiotowa biblioteka SPML została oparta o bibliotekę Apache CXF. Niskopoziomowa warstwa transportowa oparta jest o serwer Apache Jetty osadzony w kontenerze biblioteki Spring. Bezpośrednim źródłem danych dla niej jest baza PostgreSQL. Stanowi ona podstawowe

73 73 źródło danych dla samej biblioteki SPML i nie jest wykorzystywana przez inne podsystemy Środowiska. Usługi uruchamiane są ramach samodzielnej aplikacji, jak przedstawiono na Rys. 1. Rysunek 1. Dziennik zdarzeń głównej aplikacji usługowej SPML Usługi wywoływane są poprzez prosty panel administracyjny będący aplikacją J2EE osadzoną w kontenerze serwletów Apache Tomcat. Chroniona jest ona mechanizmem bezpieczeństwa Spring Security, który dokonuje uwierzytelnienia użytkowników w oparciu o usługę LDAP. Na Rys. 2 pokazano próbę zalogowania przy wyłącznej usłudze Apache Directory Server. Rysunek 2. Strona logowania do panelu administracyjnego

74 74 Wystartowanie uprzednio skonfigurowanego serwera Apache Directory Server pod systemem Windows jest kwestią uruchomienia odpowiedniej usługi, jak to pokazano na Rys. 3. Rysunek 3. Panel administracyjny serwera usług katalogowych Apache Directory Server Wywoływanie operacji add, modify, delete, setpassword, resetpassword, expirepassword, suspend oraz resume poza wykonywaniem logiki zawartej w samej bibliotece SPML, zawiera w sobie delegacje odpowiednich żądań do systemu Sun Identity Manager. Ten ostatni z kolei propaguje wyniki żądań do swojego repozytorium (opartego w tym przypadku o pliki tekstowe) oraz do systemu Apache Directory Server. Wyniki zapytań w postaci danych wygenerowanych w w/w zasobach wykorzystywane są następnie przez wspomnianą wyżej aplikację administracyjną oraz przez prostą aplikację Content Center, której jedyną funkcją jest wywoływanie operacji lookup na aktualnie zalogowanym użytkowniku. Zarówno do korzystania z Admin Panel jak i Content Center konieczne jest bowiem uwierzytelnienie w oparciu o wpisy na serwerze LDAP tworzone i modyfikowane przez system IDM w odpowiedzi na żądania wysyłane z przedmiotowej biblioteki klienckiej. Operacje te zaimplementowane są w klasie IDMServices i zgodne z profilem DSML. Na Rys. 4 pokazano fragment panelu służącego do dodawania nowego użytkownika.

75 75 Rysunek 4. Dodawanie nowego użytkownika za pomocą panelu administracyjnego Jeżeli dany użytkownik już istnieje w Środowisku lub jeżeli któreś z jego właściwości zawiera nieprawidłowe wartości, to zostanie wyświetlony odpowiedni komunikat jak na Rys. 5. Rysunek 5. Komunikaty błędów SPML zwrócone w panelu administracyjnym

76 76 Na Rys. 6 pokazano z kolei fragment dziennika zdarzeń aplikacji udostępniającej usługi SPML. Rysunek 6. Podgląd komunikatów w formacie SPML w dzienniku zdarzeń aplikacji udostępniającej usługi SPML Jeżeli komunikat żądania przejdzie pomyślnie wstępną walidację, to zostaje dodany do lokalnej bazy danych, a samo żądanie w postaci zgodnej z profilem DSML języka jest propagowane do systemu IDM. Na Rys. 7 przedstawiono fragment dziennika zdarzeń aplikacji SwingRPCRouterMonitor, monitorującej przychodzące i wychodzące komunikaty SPML i stanowiącej część biblioteki OpenSPML wbudowanej w IDM. Rysunek 7. Pogląd komunikatów SPML w aplikacji Sun Identity Manager

77 77 Utworzonego użytkownika można następnie wyszukać w Środowisku za pomocą prostej wyszukiwarki, co przedstawiono na Rys. 8. Rysunek 8. Wyszukiwanie użytkowników w panelu administracyjnym Gdy konto użytkownika zostało utworzone w Środowisku, może on zalogować się do aplikacji będącej przykładowym serwisem korporacyjnym, co przedstawiono na Rys. 9. Rysunek 9. Strona logowania do jednego z podsystemów zaprojektowanego Środowiska

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...

Bardziej szczegółowo

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7 I Wprowadzenie (wersja 0906) Kurs OPC S7 Spis treści Dzień 1 I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami automatyki I-6 Cechy podejścia dedykowanego

Bardziej szczegółowo

(Pluggable Authentication Modules). Wyjaśnienie technologii.

(Pluggable Authentication Modules). Wyjaśnienie technologii. Bezpieczeństwo systemów komputerowych. Temat seminarium: Moduły PAM (Pluggable Authentication Modules). Wyjaśnienie technologii Autor: Bartosz Hetmański Moduły PAM (Pluggable Authentication Modules). Wyjaśnienie

Bardziej szczegółowo

Komunikacja i wymiana danych

Komunikacja i wymiana danych Budowa i oprogramowanie komputerowych systemów sterowania Wykład 10 Komunikacja i wymiana danych Metody wymiany danych Lokalne Pliki txt, csv, xls, xml Biblioteki LIB / DLL DDE, FastDDE OLE, COM, ActiveX

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Simple Object Access Protocol

Simple Object Access Protocol Simple Object Access Protocol Bartłomiej Świercz Katedra Mikroelektroniki i Technik Informatycznych Łódź, 11 grudnia 2005 roku Czym jest SOAP? Akronim SOAP oznacza Simple Object Access Protocol. SOAP jest

Bardziej szczegółowo

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. Warstwa integracji wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. 1. Ukrycie logiki dostępu do danych w osobnej warstwie 2. Oddzielenie mechanizmów trwałości od modelu obiektowego Pięciowarstwowy

Bardziej szczegółowo

Bazy danych 2. Wykład 1

Bazy danych 2. Wykład 1 Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu

Bardziej szczegółowo

Web Services. Wojciech Mazur. 17 marca 2009. Politechnika Wrocławska Wydział Informatyki i Zarządzania

Web Services. Wojciech Mazur. 17 marca 2009. Politechnika Wrocławska Wydział Informatyki i Zarządzania Standardy w Rodzaje Przykłady Politechnika Wrocławska Wydział Informatyki i Zarządzania 17 marca 2009 Standardy w Rodzaje Przykłady Plan prezentacji 1 Wstęp 2 Standardy w 3 4 Rodzaje 5 Przykłady 6 Standardy

Bardziej szczegółowo

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Bardziej szczegółowo

Serwery LDAP w środowisku produktów w Oracle

Serwery LDAP w środowisku produktów w Oracle Serwery LDAP w środowisku produktów w Oracle 1 Mariusz Przybyszewski Uwierzytelnianie i autoryzacja Uwierzytelnienie to proces potwierdzania tożsamości, np. przez: Użytkownik/hasło certyfikat SSL inne

Bardziej szczegółowo

Specyfikacja techniczna. mprofi Interfejs API

Specyfikacja techniczna. mprofi Interfejs API Warszawa 09.04.2015. Specyfikacja techniczna mprofi Interfejs API wersja 1.0.2 1 Specyfikacja techniczna mprofi Interfejs API wersja 1.0.2 WERSJA DATA STATUTS AUTOR 1.0.0 10.03.2015 UTWORZENIE DOKUMENTU

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

System DiLO. Opis interfejsu dostępowego v. 2.0

System DiLO. Opis interfejsu dostępowego v. 2.0 System DiLO Opis interfejsu dostępowego v. 2.0 Warszawa 2015 1 Wprowadzone zmiany Wersja Opis 1.0 Wersja bazowa 1.1 Dodanie możliwości przejścia z wydania karty w POZ (WK-POZ) do zabiegu operacyjnego (ZAB-OPER)

Bardziej szczegółowo

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium

Bardziej szczegółowo

Zaawansowane narzędzia programowania rozproszonego

Zaawansowane narzędzia programowania rozproszonego Zaawansowane narzędzia programowania rozproszonego Karol Gołąb karol.golab@tls-technologies.com 28 listopada 2001 1 Streszczenie Omówienie i porównanie popularnych standardów mechanizmów komunikacyjnych:

Bardziej szczegółowo

Instrukcja integratora - obsługa dużych plików w epuap2

Instrukcja integratora - obsługa dużych plików w epuap2 Instrukcja integratora - obsługa dużych plików w epuap2 Wersja: 1.1 Strona 1 z 18 Spis treści SPIS TREŚCI... 2 WPROWADZENIE ORAZ INFORMACJE OGÓLNE... 3 1.1 WSTĘP... 3 1.2 WARUNKI KONIECZNE DO SPEŁNIENIA

Bardziej szczegółowo

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU Projekt Rozwój elektronicznej administracji w samorządach województwa mazowieckiego wspomagającej niwelowanie dwudzielności potencjału województwa ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

Typy przetwarzania. Przetwarzanie zcentralizowane. Przetwarzanie rozproszone

Typy przetwarzania. Przetwarzanie zcentralizowane. Przetwarzanie rozproszone Typy przetwarzania Przetwarzanie zcentralizowane Systemy typu mainfame Przetwarzanie rozproszone Architektura klient serwer Architektura jednowarstwowa Architektura dwuwarstwowa Architektura trójwarstwowa

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne

Bardziej szczegółowo

Procedura Walidacyjna Interfejs

Procedura Walidacyjna Interfejs Strona: 1 Stron: 7 SPIS TREŚCI: 1. CEL 2. ZAKRES 3. DEFINICJE 4. ODPOWIEDZIALNOŚĆ I UPRAWNIENIA 5. TRYB POSTĘPOWANIA 6. ZAŁĄCZNIKI Podlega aktualizacji X Nie podlega aktualizacji Strona: 2 Stron: 7 1.

Bardziej szczegółowo

Serwery. Autorzy: Karol Czosnowski Mateusz Kaźmierczak

Serwery. Autorzy: Karol Czosnowski Mateusz Kaźmierczak Serwery Autorzy: Karol Czosnowski Mateusz Kaźmierczak Czym jest XMPP? XMPP (Extensible Messaging and Presence Protocol), zbiór otwartych technologii do komunikacji, czatu wieloosobowego, rozmów wideo i

Bardziej szczegółowo

1 Wprowadzenie do J2EE

1 Wprowadzenie do J2EE Wprowadzenie do J2EE 1 Plan prezentacji 2 Wprowadzenie do Java 2 Enterprise Edition Aplikacje J2EE Serwer aplikacji J2EE Główne cele V Szkoły PLOUG - nowe podejścia do konstrukcji aplikacji J2EE Java 2

Bardziej szczegółowo

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI Instrukcja użytkownika Narzędzie do modelowania procesów BPEL Warszawa, lipiec 2009 r. UNIA EUROPEJSKA EUROPEJSKI FUNDUSZ

Bardziej szczegółowo

Deduplikacja danych. Zarządzanie jakością danych podstawowych

Deduplikacja danych. Zarządzanie jakością danych podstawowych Deduplikacja danych Zarządzanie jakością danych podstawowych normalizacja i standaryzacja adresów standaryzacja i walidacja identyfikatorów podstawowa standaryzacja nazw firm deduplikacja danych Deduplication

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Załącznik Nr 3 KDPW_CCP Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Wersja 1.0 Warszawa, czerwiec 2012 Spis treści Wstęp... 3 Budowa komunikatów XML... 3 Przestrzenie

Bardziej szczegółowo

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak Wykład 3 / Wykład 4 Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak 1 Wprowadzenie do Modułu 3 CCNA-E Funkcje trzech wyższych warstw modelu OSI W jaki sposób ludzie wykorzystują

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Warszawa, 09 grudnia 2014 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.3 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...

Bardziej szczegółowo

Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online)

Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online) Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online) Spis treści Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online)...1

Bardziej szczegółowo

Paweł Kurzawa, Delfina Kongo

Paweł Kurzawa, Delfina Kongo Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management

Bardziej szczegółowo

Ełk, dn. 15.10.2013 r. DOMSET Marcin Brochacki. ul. Wojska Polskiego 43 lok. 3, 19-300 Ełk. Nip 848-172-84-22 ZAPYTANIE OFERTOWE

Ełk, dn. 15.10.2013 r. DOMSET Marcin Brochacki. ul. Wojska Polskiego 43 lok. 3, 19-300 Ełk. Nip 848-172-84-22 ZAPYTANIE OFERTOWE Ełk, dn. 15.10.2013 r. DOMSET Marcin Brochacki ul. Wojska Polskiego 43 lok. 3, 19-300 Ełk Nip 848-172-84-22 ZAPYTANIE OFERTOWE Firma DOMSET Marcin Brochacki zwraca się z prośbą o przesłanie oferty cenowej

Bardziej szczegółowo

Dokumentacja smsapi wersja 1.4

Dokumentacja smsapi wersja 1.4 Dokumentacja smsapi wersja 1.4 1. Wprowadzenie Platforma smsapi została skierowana do użytkowników chcących rozbudować swoje aplikacje o system wysyłania smsów. Aplikacja ta w prosty sposób umożliwia integrację

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

Bardziej szczegółowo

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI ul. Wspólna 1/3 00-529 Warszawa URZĘDOWE POŚWIADCZENIA ODBIORU UPP ORAZ UPD Projekt współfinansowany Przez Unię Europejską Europejski

Bardziej szczegółowo

UNIX: architektura i implementacja mechanizmów bezpieczeństwa. Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci

UNIX: architektura i implementacja mechanizmów bezpieczeństwa. Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci UNIX: architektura i implementacja mechanizmów bezpieczeństwa Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci Plan prezentacji: Wprowadzenie do struktury systemów rodziny UNIX

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Warszawa, 07 lutego 2013 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.2 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...

Bardziej szczegółowo

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus Automatyzacja procesów biznesowych Andrzej Sobecki ESB Enterprise service bus Plan prezentacji Zdefiniowanie problemu Możliwe rozwiązania Cechy ESB JBI Normalizacja wiadomości w JBI Agile ESB Apache ServiceMix

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Integracja Obieg Dokumentów - GiS Spis treści

Integracja Obieg Dokumentów - GiS Spis treści Integracja Obieg Dokumentów - GiS Spis treści 1.Opis integracji.... 2 2.Interfejs po stronie Obiegu Dokumentów... 4 3.Interfejs po stronie Gis-u.... 7 4.Schematy przesyłanych plików xml.... 8 1 1. Opis

Bardziej szczegółowo

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Laboratorium Systemów Operacyjnych

Laboratorium Systemów Operacyjnych Laboratorium Systemów Operacyjnych Użytkownicy, Grupy, Prawa Tworzenie kont użytkowników Lokalne konto pozwala użytkownikowi na uzyskanie dostępu do zasobów lokalnego komputera. Konto domenowe pozwala

Bardziej szczegółowo

Gatesms.eu Mobilne Rozwiązania dla biznesu

Gatesms.eu Mobilne Rozwiązania dla biznesu Mobilne Rozwiązania dla biznesu SPECYFIKACJA TECHNICZNA WEB API-USSD GATESMS.EU wersja 0.9 Opracował: Gatesms.eu Spis Historia wersji dokumentu...3 Bezpieczeństwo...3 Wymagania ogólne...3 Mechanizm zabezpieczenia

Bardziej szczegółowo

Dotacje na innowacje - Inwestujemy w Waszą przyszłość ZAPYTANIE OFERTOWE

Dotacje na innowacje - Inwestujemy w Waszą przyszłość ZAPYTANIE OFERTOWE Warszawa, 16.07.2013r. Nabywca: Rezerweo Sp. z o.o. Ul. Tamka38 00-355 Warszawa Tel./fax 22 556 23 42 e-mail: dariusz.urbanski@rezerweo.com Dane oferenta: ZAPYTANIE OFERTOWE W zawiązku z realizacją projektu

Bardziej szczegółowo

Wykład I. Wprowadzenie do baz danych

Wykład I. Wprowadzenie do baz danych Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles

Bardziej szczegółowo

System Rozproszone Komunikator Dokumentacja. Maciej Muszkowski Jakub Narloch

System Rozproszone Komunikator Dokumentacja. Maciej Muszkowski Jakub Narloch System Rozproszone Komunikator Dokumentacja Maciej Muszkowski Jakub Narloch Wymagania Zgodnie ze wstępnymi założeniami komunikator musi, realizowad następujące funkcje: 1. Jest oparty o model Peer2Peer,

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne przedmioty.

Bardziej szczegółowo

Kielce, dnia 27.02.2012 roku. HB Technology Hubert Szczukiewicz. ul. Kujawska 26 / 39 25-344 Kielce

Kielce, dnia 27.02.2012 roku. HB Technology Hubert Szczukiewicz. ul. Kujawska 26 / 39 25-344 Kielce Kielce, dnia 27.02.2012 roku HB Technology Hubert Szczukiewicz ul. Kujawska 26 / 39 25-344 Kielce Tytuł Projektu: Wdrożenie innowacyjnego systemu dystrybucji usług cyfrowych, poszerzenie kanałów sprzedaży

Bardziej szczegółowo

Jednolite zarządzanie użytkownikami systemów Windows i Linux

Jednolite zarządzanie użytkownikami systemów Windows i Linux Uniwersytet Mikołaja Kopernika Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Paweł Gliwiński Nr albumu: 168470 Praca magisterska na kierunku Informatyka Jednolite

Bardziej szczegółowo

Elektroniczna Skrzynka Podawcza

Elektroniczna Skrzynka Podawcza Elektroniczna Skrzynka Podawcza Instrukcja dla administratora Wersja 1.6.0 Przewodnik przeznaczony jest dla użytkowników, którzy administrują kontem urzędu w systemie Elektronicznej Skrzynki Podawczej.

Bardziej szczegółowo

DOKUMENTACJA TECHNICZNA SMS API MT

DOKUMENTACJA TECHNICZNA SMS API MT DOKUMENTACJA TECHNICZNA SMS API MT Mobitex Telecom Sp.j., ul. Warszawska 10b, 05-119 Legionowo Strona 1 z 5 Ten dokument zawiera szczegółowe informacje odnośnie sposobu przesyłania requestów do serwerów

Bardziej szczegółowo

Koncepcja systemu informatycznego realizującego w środowisku Oracle Spatial proces generalizacji modelu BDOT10 do postaci BDOT50

Koncepcja systemu informatycznego realizującego w środowisku Oracle Spatial proces generalizacji modelu BDOT10 do postaci BDOT50 Koncepcja systemu informatycznego realizującego w środowisku Oracle Spatial proces generalizacji modelu BDOT10 do postaci BDOT50 Architektura systemu Architektura systemu System udostępnia dwa kanały dostępu,

Bardziej szczegółowo

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz Część I -ebxml Po zrealizowaniu materiału student będzie w stanie omówić potrzeby rynku B2B w zakresie przeprowadzania transakcji przez Internet zaprezentować architekturę ebxml wskazać na wady i zalety

Bardziej szczegółowo

Standard HL7 (cel, protokoły, zastosowanie) Piotr Dybski Jan Flik

Standard HL7 (cel, protokoły, zastosowanie) Piotr Dybski Jan Flik Standard HL7 (cel, protokoły, zastosowanie) Piotr Dybski Jan Flik Plan prezentacji Definicja HL7 HL7 jako standard uniwersalny Wymiana informacji w HL7 Wersje HL7 HL7 - definicja HL7 (ang. Health Level

Bardziej szczegółowo

World Wide Web? rkijanka

World Wide Web? rkijanka World Wide Web? rkijanka World Wide Web? globalny, interaktywny, dynamiczny, wieloplatformowy, rozproszony, graficzny, hipertekstowy - system informacyjny, działający na bazie Internetu. 1.Sieć WWW jest

Bardziej szczegółowo

Programowanie Urządzeń Mobilnych. Część II: Android. Wykład 2

Programowanie Urządzeń Mobilnych. Część II: Android. Wykład 2 Programowanie Urządzeń Mobilnych Część II: Android Wykład 2 1 Aplikacje w systemie Android Aplikacje tworzone są w języku Java: Skompilowane pliki programów ( dex ) wraz z plikami danych umieszczane w

Bardziej szczegółowo

2 Podstawy tworzenia stron internetowych

2 Podstawy tworzenia stron internetowych 2 Podstawy tworzenia stron internetowych 2.1. HTML5 i struktura dokumentu Podstawą działania wszystkich stron internetowych jest język HTML (Hypertext Markup Language) hipertekstowy język znaczników. Dokument

Bardziej szczegółowo

Analiza i projektowanie aplikacji Java

Analiza i projektowanie aplikacji Java Analiza i projektowanie aplikacji Java Modele analityczne a projektowe Modele analityczne (konceptualne) pokazują dziedzinę problemu. Modele projektowe (fizyczne) pokazują system informatyczny. Utrzymanie

Bardziej szczegółowo

1 Moduł E-mail. 1.1 Konfigurowanie Modułu E-mail

1 Moduł E-mail. 1.1 Konfigurowanie Modułu E-mail 1 Moduł E-mail Moduł E-mail daje użytkownikowi Systemu możliwość wysyłania wiadomości e-mail poprzez istniejące konto SMTP. System Vision może używać go do wysyłania informacji o zdefiniowanych w jednostce

Bardziej szczegółowo

SIMON SAYS ARCHITECTURE! Usługi zdalne. Technologie, techniki i praktyki implementacji

SIMON SAYS ARCHITECTURE! Usługi zdalne. Technologie, techniki i praktyki implementacji SIMON SAYS ARCHITECTURE! Usługi zdalne Technologie, techniki i praktyki implementacji O mnie Bloguję: SIMON-SAYS-ARCHITECTURE.COM Twittuję: www.twitter.com/szymonpobiega Koduję: DDDSample.Net, NetMX, WS-Man.Net

Bardziej szczegółowo

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Warszawa, lipiec 2012 Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Wersja 1.1 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw

Bardziej szczegółowo

Rozproszone systemy Internetowe

Rozproszone systemy Internetowe Rozproszone systemy Internetowe Transport komunikatów WS: protokół SOAP RSI Oskar Świda 1 Simple Object Access Protocol Bezstanowy protokół komunikacyjny, oparty na standardzie XML Prosty i elastyczny,

Bardziej szczegółowo

Płatności CashBill - SOAP

Płatności CashBill - SOAP Dokumentacja techniczna 1.0 Płatności CashBill - SOAP Dokumentacja wdrożenia systemu Płatności CashBill w oparciu o komunikację według protokołu SOAP CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa

Bardziej szczegółowo

EJB 3.0 (Enterprise JavaBeans 3.0)

EJB 3.0 (Enterprise JavaBeans 3.0) EJB 3.0 (Enterprise JavaBeans 3.0) Adrian Dudek Wirtualne Przedsiębiorstwo 2 Wrocław, 1 czerwca 2010 Plan prezentacji 1 Wprowadzenie Cel prezentacji Czym jest EJB 3.0? Historia 2 3 Cel prezentacji Wprowadzenie

Bardziej szczegółowo

Zagadnienia projektowania aplikacji J2EE

Zagadnienia projektowania aplikacji J2EE 211 Zagadnienia projektowania aplikacji J2EE Maciej Zakrzewicz Maciej.Zakrzewicz@cs.put.poznan.pl http://www.cs.put.poznan.pl/mzakrzewicz/ Plan rozdziału 212 Wstęp Techniki projektowe: Wprowadzenie modułu

Bardziej szczegółowo

Funkcje dodatkowe. Wersja 1.2.1

Funkcje dodatkowe. Wersja 1.2.1 Funkcje dodatkowe Wersja 1..1 Dokumentacja SMSAPI (https) FUNKCJE DODATKOWE z dnia 1.06.01 Wersja 1..1 SPIS TREŚCI 1.Wprowadzenie 1.1 Adresy URL do połączenia z aplikacją dla funkcji zarządzania kontem

Bardziej szczegółowo

Rozdział ten zawiera informacje o sposobie konfiguracji i działania Modułu OPC.

Rozdział ten zawiera informacje o sposobie konfiguracji i działania Modułu OPC. 1 Moduł OPC Moduł OPC pozwala na komunikację z serwerami OPC pracującymi w oparciu o model DA (Data Access). Dzięki niemu można odczytać stan obiektów OPC (zmiennych zdefiniowanych w programie PLC), a

Bardziej szczegółowo

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

Bardziej szczegółowo

Praca w sieci z serwerem

Praca w sieci z serwerem 11 Praca w sieci z serwerem Systemy Windows zostały zaprojektowane do pracy zarówno w sieci równoprawnej, jak i w sieci z serwerem. Sieć klient-serwer oznacza podłączenie pojedynczego użytkownika z pojedynczej

Bardziej szczegółowo

Baza numerów Wersja 1.1

Baza numerów Wersja 1.1 Baza numerów Wersja 1.1 SPIS TREŚCI 1. Wprowadzenie 1.1 Adresy URL do połączenia z aplikacją 1.2 Informacje zwrotne wysyłane z API w odpowiedzi na odebrane odwołania I. Zarządzanie grupami Bazy Numerów

Bardziej szczegółowo

Modelowanie i Programowanie Obiektowe

Modelowanie i Programowanie Obiektowe Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do

Bardziej szczegółowo

Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science

Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science Systemy internetowe Wykład 5 Architektura WWW Architektura WWW Serwer to program, który: Obsługuje repozytorium dokumentów Udostępnia dokumenty klientom Komunikacja: protokół HTTP Warstwa klienta HTTP

Bardziej szczegółowo

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne Jarosław Kuchta Internetowe Usługi Informacyjne Komponenty IIS HTTP.SYS serwer HTTP zarządzanie połączeniami TCP/IP buforowanie odpowiedzi obsługa QoS (Quality of Service) obsługa plików dziennika IIS

Bardziej szczegółowo

ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A.

ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. 1 Załącznik Nr 2 do Część II SIWZ Wyciąg ze standardów, zasad i wzorców integracyjnych obowiązujących

Bardziej szczegółowo

Microsoft Exchange Server 2013

Microsoft Exchange Server 2013 William R. Stanek Vademecum Administratora Microsoft Exchange Server 2013 Konfiguracja i klienci systemu Przekład: Leszek Biolik APN Promise 2013 Spis treści Wstęp..........................................

Bardziej szczegółowo

Dotacje na innowacje - Inwestujemy w Waszą przyszłość ZAPYTANIE OFERTOWE

Dotacje na innowacje - Inwestujemy w Waszą przyszłość ZAPYTANIE OFERTOWE Warszawa, 13.09.2013 Nabywca: Rabateo Sp. z o.o. Ul. Tamka38 00-355 Warszawa Tel./fax 22 556 23 45 e-mail: dariusz.urbanski@rabateo.coml Dane oferenta: ZAPYTANIE OFERTOWE W zawiązku z realizacją projektu

Bardziej szczegółowo

Instrukcja do panelu administracyjnego. do zarządzania kontem FTP WebAs. www.poczta.greenlemon.pl

Instrukcja do panelu administracyjnego. do zarządzania kontem FTP WebAs. www.poczta.greenlemon.pl Instrukcja do panelu administracyjnego do zarządzania kontem FTP WebAs www.poczta.greenlemon.pl Opracowanie: Agencja Mediów Interaktywnych GREEN LEMON Spis treści 1.Wstęp 2.Konfiguracja 3.Konto FTP 4.Domeny

Bardziej szczegółowo

Zalety projektowania obiektowego

Zalety projektowania obiektowego Zalety projektowania obiektowego Łatwe zarządzanie Możliwość powtórnego użycia klas obiektów projektowanie/programowanie komponentowe W wielu przypadkach występuje stosunkowo proste mapowanie pomiędzy

Bardziej szczegółowo

Spis treci. Dzie 1. I Wprowadzenie (wersja 0911) II Dostp do danych biecych specyfikacja OPC Data Access (wersja 0911)

Spis treci. Dzie 1. I Wprowadzenie (wersja 0911) II Dostp do danych biecych specyfikacja OPC Data Access (wersja 0911) I Wprowadzenie (wersja 0911) Kurs OPC Integracja i Diagnostyka Spis treci Dzie 1 I-3 O czym bdziemy mówi? I-4 Typowe sytuacje I-5 Klasyczne podejcie do komunikacji z urzdzeniami automatyki I-6 Cechy podejcia

Bardziej szczegółowo

Protokół wymiany sentencji, wersja 1

Protokół wymiany sentencji, wersja 1 Protokół wymiany sentencji, wersja 1 Sieci komputerowe 2011@ MIM UW Osowski Marcin 28 kwietnia 2011 1 Streszczenie Dokument ten opisuje protokół przesyłania sentencji w modelu klientserwer. W założeniu

Bardziej szczegółowo

11. Autoryzacja użytkowników

11. Autoryzacja użytkowników 11. Autoryzacja użytkowników Rozwiązanie NETASQ UTM pozwala na wykorzystanie trzech typów baz użytkowników: Zewnętrzna baza zgodna z LDAP OpenLDAP, Novell edirectory; Microsoft Active Direcotry; Wewnętrzna

Bardziej szczegółowo

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI ul. Wspólna 1/3 00-529 Warszawa ZESTAW SCHEMATÓW PODSTAWOWYCH Projekt współfinansowany Przez Unię Europejską Europejski Fundusz

Bardziej szczegółowo

Wykład 3 Inżynieria oprogramowania. Przykład 1 Bezpieczeństwo(2) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz

Wykład 3 Inżynieria oprogramowania. Przykład 1 Bezpieczeństwo(2) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz Wykład 3 Inżynieria oprogramowania Przykład 1 Bezpieczeństwo(2) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz Struktura wykładu 1. Utworzenie użytkowników i ról na serwerze aplikacji Sun Java System

Bardziej szczegółowo

SOA Web Services in Java

SOA Web Services in Java Wydział Informatyki i Zarządzania Wrocław,16 marca 2009 Plan prezentacji SOA 1 SOA 2 Usługi Przykłady Jak zacząć SOA Wycinek rzeczywistości Problemy zintegrowanych serwisów : Wycinek Rzeczywistości Zacznijmy

Bardziej szczegółowo

Część I Rozpoczęcie pracy z usługami Reporting Services

Część I Rozpoczęcie pracy z usługami Reporting Services Spis treści Podziękowania... xi Wprowadzenie... xiii Część I Rozpoczęcie pracy z usługami Reporting Services 1 Wprowadzenie do usług Reporting Services... 3 Platforma raportowania... 3 Cykl życia raportu...

Bardziej szczegółowo

Wykonać Ćwiczenie: Active Directory, konfiguracja Podstawowa

Wykonać Ćwiczenie: Active Directory, konfiguracja Podstawowa Wykonać Ćwiczenie: Active Directory, konfiguracja Podstawowa Instalacja roli kontrolera domeny, Aby zainstalować rolę kontrolera domeny, należy uruchomić Zarządzenie tym serwerem, po czym wybrać przycisk

Bardziej szczegółowo

Monitorowanie i zarządzanie urządzeniami sieciowymi przy pomocy narzędzi Net-SNMP

Monitorowanie i zarządzanie urządzeniami sieciowymi przy pomocy narzędzi Net-SNMP Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Szymon Klimuk Nr albumu: 187408 Praca magisterska na kierunku Informatyka Monitorowanie

Bardziej szczegółowo

4 Web Forms i ASP.NET...149 Web Forms...150 Programowanie Web Forms...150 Możliwości Web Forms...151 Przetwarzanie Web Forms...152

4 Web Forms i ASP.NET...149 Web Forms...150 Programowanie Web Forms...150 Możliwości Web Forms...151 Przetwarzanie Web Forms...152 Wstęp...xv 1 Rozpoczynamy...1 Co to jest ASP.NET?...3 W jaki sposób ASP.NET pasuje do.net Framework...4 Co to jest.net Framework?...4 Czym są Active Server Pages (ASP)?...5 Ustawienia dla ASP.NET...7 Systemy

Bardziej szczegółowo

Wstęp... ix. 1 Omówienie systemu Microsoft Windows Small Business Server 2008... 1

Wstęp... ix. 1 Omówienie systemu Microsoft Windows Small Business Server 2008... 1 Spis treści Wstęp... ix 1 Omówienie systemu Microsoft Windows Small Business Server 2008... 1 Składniki systemu Windows SBS 2008... 1 Windows Server 2008 Standard... 2 Exchange Server 2007 Standard...

Bardziej szczegółowo

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja ZPKSoft WDoradca 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja 1. Wstęp ZPKSoft WDoradca jest technologią dostępu przeglądarkowego do zasobów systemu ZPKSoft Doradca.

Bardziej szczegółowo

T: Wbudowane i predefiniowane domenowe grupy lokalne i globalne.

T: Wbudowane i predefiniowane domenowe grupy lokalne i globalne. T: Wbudowane i predefiniowane domenowe grupy lokalne i globalne. Zadanie1: Zapoznaj się z zawartością witryny http://technet.microsoft.com/pl-pl/library/cc756898%28ws.10%29.aspx. Grupy domyślne kontrolera

Bardziej szczegółowo

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI ul. Wspólna 1/3 00-529 Warszawa ZASADY NAZEWNICTWA DOKUMENTÓW XML Projekt współfinansowany Przez Unię Europejską Europejski Fundusz

Bardziej szczegółowo

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa?

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? Koszalin, 15-16.05.2006 III Zawodowa Konferencja Zawód kartografa 200910151500 Agenda 1. Koncepcja SKBDT 2. Podstawowe założenia koncepcji

Bardziej szczegółowo

P.2.1 WSTĘPNA METODA OPISU I

P.2.1 WSTĘPNA METODA OPISU I 1 S t r o n a P.2.1 WSTĘPNA METODA OPISU I ZNAKOWANIA DOKUMENTACJI MEDYCZNEJ W POSTACI ELEKTRONICZNEJ P.2. REKOMENDACJA OPISU I OZNAKOWANIA DOKUMENTACJI MEDYCZNEJ W POSTACI ELEKTRONICZNEJ 2 S t r o n a

Bardziej szczegółowo

Oracle COREid Federation Przegląd

Oracle COREid Federation Przegląd Oracle COREid Federation Przegląd Dokument techniczny Oracle Listopad 2005 ORACLE FUSION MIDDLEWARE Oracle COREid Federation Wprowadzenie COREid Federation to jedyny w branży serwer federacji tożsamości,

Bardziej szczegółowo

edziennik Ustaw Opis architektury

edziennik Ustaw Opis architektury edziennik Ustaw Opis architektury Spis treści 1 Wstęp...3 2 Architektura systemu...3 2.1 Schemat poglądowy rozwiązania...3 2.2 Architektura logiczna...4 2.3 Opis elementów systemu...5 2.3.1 Moduł Udostępniający...5

Bardziej szczegółowo