Dokumentacja Usług Sieciowych Uwierzytelniania i Autoryzacji. Wersja: 1.00

Dokumentacja Usług Sieciowych Uwierzytelniania i Autoryzacji Wersja: 1.00

Spis treści 1. Wprowadzenie... 4 1.1 Identyfikacja i opis dokumentu... 4 1.2 Cel... 4 1.3 Odnośniki... 4 1.4 Notacja... 4 2. Usługa Sieciowa: Uwierzytelnianie żądań wewnętrznych... 6 2.1 Opis... 6 2.2 Adres usług sieciowych... 8 2.3 Uwierzytelnianie i autoryzacja... 8 3. Usługa Sieciowa: Uwierzytelnianie żądań zewnętrznych... 11 3.1 Opis... 11 3.2 Adres... 12 3.3 Uwierzytelnianie i autoryzacja... 12 4. Usługa Sieciowa: FSSO... 16 4.1 Opis... 16 4.2 Uwierzytelnienie i Autoryzacja... 16 4.3 Adres i wymiana danych pomiędzy IdP a SP... 18 4.4 Federacja konta użytkownika pomiędzy IdP a SP... 22 4.5 Synchronizacja czasu pomiędzy IdP a SP... 23 5. Usługa Sieciowa: Autoryzacja Zewnętrzna JACC... 25 5.1 Opis... 25 5.2 Adresy JACC... 25

1. Wprowadzenie 1.1 Identyfikacja i opis dokumentu Niniejszy dokument stanowi dokumentację Usług Sieciowych wystawionych na potrzeby Uwierzytelniania i Autoryzacji w systemie PESEL2. 1.2 Cel Celem niniejszego dokumentu jest udokumentowanie dostarczonych Usług Uwierzytelniania i Autoryzacji (UA), tj. ich opisu, konfiguracji i zasad działania. Dokument ten omówi każdą z usług i opisze jej interfejsy. Wszelkie aspekty administracyjne Usługami UA ujęte są w osobnym dokumencie dotyczącym administracji Usług UA. Dokument nie skupia się także na opisie wykorzystanych standardów bezpieczeństwa. 1.3 Odnośniki Tematy objęte dokumentacją wymagają wiedzy o wielu standardach takich jak WS-Security, WS-Trust, Security Token Service, tokenach SAML 2.0 czy wreszcie FSSO. W tym celu w dokumencie zostaną użyte odnośniki (hiperłącza) internetowe, które szczegółowo opisują dany standard, sposób jego działania i wzorce zastosowania w systemach informatycznych. 1.4 Notacja W dokumencie przyjęta została notacja opisu tekstowego z ewentualnymi rysunkami ułatwiającymi zrozumienie danego komponentu. Autorzy dodatkowo w wielu przypadkach odsyłają do zasobów internetowych, które uzupełniają opis usług. Użyte skróty: Nazwa UA Opis Usługi Uwierzytelnienia i Autoryzacji

UŚ WAS WPS WMB WSGW IdP FSSO SP GUI JACC Endpoint Usługi Sieciowe do danych systemu Pesel2 Serwer aplikacyjny WebSphere Application Server Serwer aplikacyjny WebSphere Process Server Serwer WebSphere Message Broker WebSphere WebService Gateway (Brama XML) Identity Provider (Dostawca Tożsamości) Federated Single Sign On, usługa zdalnego uwierzytelnienia Service Provider (Dostawca Usługi) Aplikacja JEE, klient UŚ Java Authorization Contract for Container, usługa zewnętrznej autoryzacji Adres, który przyjmuje lub wystawia żądania SOAP (webservices) W dokumencie używane będą następujące nazwy hostów: Adres IP Nazwa hosta MSWIA test-linux-tam 172.17.32.40 test-linux-wsgw 172.17.10.54

2. Usługa Sieciowa: Uwierzytelnianie żądań wewnętrznych 2.1 Opis Usługa Uwierzytelniania żądań wewnętrznych jest wykorzystywana przez serwery wystawiające Usługi Sieciowe Pesel2 w celu zachowania ich bezpieczeństwa i integralności (żądania przesyłane z użyciem SOAP over HTTP). W celu osiągnięcia bezpieczeństwa zastosowany został standard WS-Security i tokeny bezpieczeństwa IDAssertion oraz LTPA zawierające tożsamość nadawcy komunikatu. Poniższy rysunek przedstawia model koncepcyjny komunikacji pomiędzy poszczególnymi komponentami w modelu uwierzytelnień żądań wewnętrznych.

Rysunek 1: Schemat komunikacji pomiędzy komponentami dla uwierzytelnień wewnętrznych Zgodnie z rysunkiem 1, aby komponent aplikacji GUI mógł odwołać się do usług sieciowych, musi on zwrócić się do odpowiedniego endpointa wystawionego przez Bramę XML. Musi to być prawidłowe żądanie SOAP zabezpieczone mechanizmami WS-Security (prawidłowa definicja polityk WS-Security). Brama XML na podstawie przysłanego żądania przekierowuje je na odpowiednią usługę wystawianą za pomocą serwerów WAS, WMB lub WPS. Zanim jednak to zrobi, autoryzuje żądania w oparciu o serwer TAM Policy Server. Usługa Bramy XML zamienia następnie token WS-Security żądania SOAP i przesyła je do odpowiedniej usługi, aby ta je poprawnie zaakceptowała. Dokładny opis przebiegu uwierzytelnienia i autoryzacji żądań omówiony jest w podrozdziale 2.3.

2.2 Adres usług sieciowych Usługa uwierzytelniania żądań wewnętrznych jest dostępna w części bezpiecznej, wewnętrznej sieci MSWIA i osadzona jest na serwerze WAS wykorzystującym komponent WebSphere WebServices Gateway, który wystawia endpoint: - endpoint LTPA <host bramy XML>:<port HTTP bramy XML>/wsgwsoaphttp1/soaphttpengine/wsgwBus/<Nazwa usługi>_inboundportltpa_<profil serwera z UŚ> Przykład wystawionej usługi (SlownikiUdostepnianie) to: http://test-linuxwsgw:9081/wsgwsoaphttp1/soaphttpengine/wsgwbus/slownikiudostepnianie/slowniki Udostepnianie_InboundPortLTPA_CUBE2Run01 2.3 Uwierzytelnianie i autoryzacja Aplikacja GUI wysyła żądanie dostępu do UŚ do komponentu Bramy XML. Jeśli nie zawiera ono odpowiedniego tokenu WS-Security zostaje odrzucone i nie podlega dalszemu przetwarzaniu. Jeśli natomiast żądanie zawiera poprawny token WS-Security, zostaje ono dalej przetwarzane w celu weryfikacji przekazanej tożsamości oraz jej autoryzacji do żądanego zasobu. Autoryzacja wykonywana jest w oparciu o serwer TAM Policy Server, który decyduje czy przyznać dostęp do danego zasobu. W przypadku braku odpowiednich uprawnień lub przynależności do wymaganych grup zwracany jest błąd 403 Unauthorized. W przeciwnym przypadku tożsamość uzyskuje dostęp do zasobu. Serwery Usług Sieciowych są skonfigurowane w taki sposób, że przyjmują tylko podpisane przez Bramę XML żądania. Weryfikacja ta odbywa się na politykach chroniących poszczególne usługi WebService. W tym celu stworzone zostały specjalne polityki WSSecurityPolicies oraz WSSecurityBindings umieszczone na serwerach po obu stronach. Poniższy diagram sekwencji szczegółowo omawia przypadek komunikacji komponentów wewnętrznych z Usługami Sieciowymi (tokeny WS-Security LTPA i IDAssertion).

Rysunek 2: Komunikacja wewnętrzna z użyciem tokenów WSS IDAssertion Rysunek 1 przedstawia sekwencje operacji wykonywanych podczas komunikacji wewnętrznej z użyciem tokenów WS-Security IDAssertion 1. System wewnętrzny GUI podpisuje wiadomość SOAP z tokenem IDAssertion 1.1. System wewnętrzny GUI wysyła żądanie do Usługi Sieciowej 1.1.1. Brama XML weryfikuje otrzymane żądanie 1.1.2. Jeśli żądanie jest poprawne i spełnione są warunki uwierzytelnienia i autoryzacji przekazanej tożsamości, Brama XML przygotowuje nowy komunikat zawierający tym razem token WSS IDAssertion podpisując go. 1.1.3. Brama XML wywołuje docelową Usługę Sieciową

1.1.3.1 Serwer Usług Sieciowych weryfikuje integralność (podpis) wiadomości i jeśli jest prawidłowy przygotowuje wynik 1.1.3.2 Serwer UŚ podpisuje żądanie z wynikiem 1.1.4. Brama XML odbiera odpowiedź UŚ 1.1.5. Brama XML weryfikuje integralność otrzymanej wiadomości 1.1.6. Brama XML podpisuje nowe żądanie dla aplikacji GUI zawierające wynik. 1.2. Aplikacja GUI otrzymuje żądanie z wynikiem 1.3. Serwer systemu wewnętrznego GUI weryfikuje podpis (polityki i bindings) i jeśli jest prawidłowy przyjmuje komunikat i prezentuje użytkownikowi wynik.

3. Usługa Sieciowa: Uwierzytelnianie żądań zewnętrznych 3.1 Opis Usługa Uwierzytelniania żądań zewnętrznych jest wykorzystywana przez systemy zewnętrzne względem Usług Sieciowych Pesel2 w celu zachowania bezpieczeństwa i integralności przesyłanych żądań SOAP over HTTP. W celu osiągnięcia bezpieczeństwa zastosowany został standard WS-Security i tokeny bezpieczeństwa SAML2.0 lub X.509, zawierające tożsamość nadawcy komunikatu. Dodatkowo, żądania pomiędzy systemami zewnętrznymi a systemem Pesel2 przesyłane są w zabezpieczonym kanale SSL zestawionym przy użyciu odpowiednich certyfikatów wydanych przez MSWIA. Ruch zewnętrzny SSL jest terminowany w strefie DMZ systemu Pesel2 i przetwarzany dalej z wykorzystaniem zabezpieczeń WS-Security po kanale HTTP. Rysunek 3: Schemat koncepcyjny działania uwierzytelnienia żądań zewnętrznych Rysunek 3 przedstawia schemat komunikacji w przypadku uwierzytelnienia i autoryzacji żądania zewnętrznego. Żądanie takie, najpierw w kanale SSL jest przekazywane do serwera HTTP IHS. Jeśli certyfikat, jakim przedstawił się system zewnętrzny jest prawidłowy, żądanie w kanale HTTP przekazywane jest do komponentu Bramy XML Brama identyfikuje żądanie od systemu po przekazanym tokenie SAML2.0, następnie uwierzytelnia autoryzuje przekazaną w

niej tożsamość. Jeśli przekazane dane są prawidłowe, generowany jest odpowiedni token dla żądanej usługi (w tym przypadku IDAsserton) i zwracany jest wynik. W przypadku komunikacji zewnętrznej z tokenem SAML2.0 komunikaty są podpisywane i szyfrowane. W komunikacji wewnętrznej, komunikaty są tylko podpisywane. 3.2 Adres Usługa uwierzytelniania żądań zewnętrznych jest wystawiona przez serwery HTTP znajdujące się w strefie DMZ sieci MSWIA. Serwer HTTP kieruje następnie żądania bezpośrednio do serwera WAS wykorzystującego komponent WebSphere WebServices Gateway, który świadczy poszczególne endpointy dla systemów zewnętrznych: - endpoint SAML2.0 <Nazwa usługi>_inboundportsaml20<dodatkowy, opcjonalny parametr> - endpoint X.509 <Nazwa usługi>_inboundportx509<dodatkowy, opcjonalny parametr> Przykład wystawionej usługi przez Bramę XML (PeselUdostepnianie dla klientów zewnętrznych) to: http://test-linuxwsgw:9081/wsgwsoaphttp1/soaphttpengine/wsgwbus/peseludostepnianie/peseludostepnianie _InboundPortSAML20_CUBE2TEST 3.3 Uwierzytelnianie i autoryzacja Każde żądanie z systemu Zewnętrznego musi zostać nawiązane z użyciem połączenia SSL, w którym system zewnętrzny przedstawia się certyfikatem wystawionym przez MSWIA. Jeśli certyfikat nie znajduje się na liście certyfikatów odwołanych lub nieważnych (sprawdzenie protokołem, OCSP wskazanego serwera MSWIA), takie żądanie kierowane jest dalej do serwera WAS z komponentem Bramy XML. Jeśli wysłane żądanie trafiające do Bramy XML nie zawiera odpowiedniego tokenu bezpieczeństwa WS-Security oraz uzgodnionych zabezpieczeń na poziomie polityk i bindings WS, zostaje odrzucone i nie podlega dalszemu przetwarzaniu.

Jeśli natomiast żądanie zawiera wymaganą treść WS-Security, zostaje ono dalej przetwarzane w celu weryfikacji przekazanej tożsamości oraz jej autoryzacji do żądanego zasobu. Autoryzacja wykonywana jest w oparciu o serwer TAM Policy Server, który decyduje czy przyznać dostęp do danego zasobu. W przypadku braku odpowiednich uprawnień lub przynależności do wymaganych grup zwracany jest standardowy błąd HTTP 403 Unauthorized. W przeciwnym przypadku tożsamość uzyskuje dostęp do zasobu. Szczegółowo, komunikację tą, opisuję poniższy diagram sekwencji. Rysunek 4: Komunikacja systemu zewnętrznego z Usługami Sieciowymi Pesel2 wykorzystująca token SAML2.0 Poszczególne kroki wykonane na rysunku nr 4:

1. System Zewnętrzny woła Usługę Sieciową wysyłając żądanie SOAP z tokenem SAML2.0, dodatkowo podpisując i szyfrując wiadomość. Żądanie jest przesyłane w kanale SSL, zestawionym za pomocą certyfikatu wydanego przez MSWIA i przekazanego Systemowi Zewnętrznemu. 1.1. Żądnie jest przekazywane do Bramy XML a następnie wiadomość jest rozszyfrowywana i weryfikowana pod kątem jej integralności. 1.2. W celu uwierzytelnienia i autoryzacji przekazanej w tokenie SAML2.0 tożsamości, Brama XML odwołuję się do serwera TFIM za pomocą protokołu WS-Trust. 1.2.1. Usługa TFIM konsumuje token SAML2.0 i przeprowadza operację uwierzytelnienia i autoryzacji zdefiniowaną w specjalnym łańcuchu. Dokładnie łańcuchy opisane są w dokumentacji administratora. Poniżej przedstawiony został przykładowy łańcuch TFIMa składający się z 5 kroków jego wynikiem jest wygenerowany token UserNameToken bez hasła (IDAsertion). Jeśli którykolwiek z kroków się nie uda, żądanie jest odrzucane przez Bramę XML. Rysunek 5: Kolejne kroki wykonywane przez komponent TFIM wykorzystywany przez Bramę XML 1.3. Przetworzone przez TFIM żądanie wraca do Bramy XML 1.4. Brama XML przesyła podpisane żądanie z tokenem IDAssertion do serwera UŚ 1.4.1. Serwer UŚ weryfikuje podpis otrzymanego żądania, jeśli jest poprawny przetwarza je i zwraca wynik (także podpisany)

1.5. Wynik zwrócony przez UŚ jest weryfikowany pod kątem integralności 1.6. Przygotowywane jest żądanie z wynikiem dla Systemu Zewnętrznego. W tym celu jest ono podpisywane i szyfrowane. 2. Żądanie zostaje przesłane do Systemu Zewnętrznego w kanale SSL

4. Usługa Sieciowa: FSSO 4.1 Opis Usługa FSSO (Federated Single Sign On) jest wykorzystywana przez systemy zewnętrzne względem Usług Sieciowych Pesel2, w celu wykorzystania danych użytkowników oraz ich uwierzytelniania i autoryzacji w Usłudze Katalogowej MSWIA. Siła usługi FSSO polega na tym, iż partner, MSWIA, który korzysta z usługi nie musi administrować swoim własnym repozytorium użytkowników, ich hasłami i ich przynależnością do grup. Zewnętrzny partner zdaje się w tym względzie na centralnie zarządzaną bazę użytkowników przechowywanych w Usłudze Katalogowej LDAP MSWIA. W celu zapewnienia odpowiedniego poziomu bezpieczeństwa Usłudze FSSO, informacje o tożsamościach przesyłane są wykorzystując tzw. federację SAML2.0. Termin ten określa szczegółowo specyfikacja protokołu SAML2.0 dostępna pod adresem: http://www.oasis-open.org/committees/download.php/27819/sstc-saml-techoverview-2.0-cd-02.pdf Istotą użycia standardu SAML2.0 jest fakt, iż pozwala on na przesyłanie wielu informacji o tożsamości, takich jak nazwa użytkownika, przynależność do grup czy inne, dodatkowe informacje, które mogą zostać wykorzystane przez partnera do odwzorowania użytkownika na role biznesowe w jego własnych aplikacjach. 4.2 Uwierzytelnienie i Autoryzacja Poniższy diagram sekwencji prezentuje przypadek wykonania uwierzytelnienia użytkownika w systemie partnera wykorzystującego usługę FSSO systemu Pesel2.

Rysunek 6: Sekwencja wykonanych akcji dla uwierzytelnienia FSSO przy użyciu artefaktu Rysunek nr 6 przedstawia przykładową interakcję pomiędzy systemem partnera (SP), przeglądarką użytkownika i systemem Pesel2 (IdP), będącym dostarczycielem tożsamości. 1. Użytkownik odwołuję się do znanego mu zasobu internetowego będącego serwisem partnera. 2. Usługa partnera informuje użytkownika, że musi się on uwierzytelnić w celu otrzymania dostępu do żądanego zasobu. 3. Użytkownik wybiera samodzielnie lub jest automatycznie przez SP przekierowany na stronę logowania leżącą u dostawcy tożsamości (IdP). 3.1.1. Użytkownik uwierzytelnia się w IdP przy użyciu identyfikatora lub hasła lub certyfikatu X.509 wydanego przez MSWIA

3.1.2. IdP w przypadku pomyślnego uwierzytelnienia przekierowuje użytkownika z powrotem przesyłając dodatkowo artefakt będący wygenerowanym przez IdP unikalnym identyfikatorem. 3.1.3. (Opcjonalnie) Użytkownik przedstawia SP uzyskany od IdP artefakt 1 (Opcjonalnie) SP weryfikuje artefakt wystawiony przez IdP na backchanellu. Jest to operacja wykonana bez udziału użytkownika. Przesyłane komunikaty są zaszyfrowane i zabezpieczone tokenami SAML pomiędzy ufającymi sobie stronami IdP i SP. 2 (Opcjonalnie) IdP podejmuje decyzję czy artefakt jest ważny i prawidłowy 3.1.3.1 W przypadku pozytywnej odpowiedzi SP tworzy sesję i kontekst JAAS na podstawie uzyskanych informacji konsumując token SAML2.0. Ponieważ w asercji SAML2.0 zawarte są atrybuty z informacją o przynależności użytkownika do grup możliwe jest jego prawidłowe zamapowanie na odpowiednie role biznesowe w aplikacji partnera. 3.1.4. Użytkownik zostaje uwierzytelniony i autoryzowany przez SP na podstawie uzyskanych danych Należy odnotować także, że możliwe jest również przeprowadzenie uwierzytelnienia bez użycia artefaktu, używając jedynie bindingu HTTP POST. W tym przypadku przez przeglądarkę użytkownika podczas przekierowania zwrotnego z IdP przesyłany jest także token SAML2.0 z asercją tożsamości. Zaleca się jednak stosowanie pierwszej z omówionych opcji dla zachowania maksymalnego bezpieczeństwa przesyłanych informacji. 4.3 Adres i wymiana danych pomiędzy IdP a SP Usługa FSSO dostępna jest w postaci webservice u wystawionego przez system MSWIA na serwerze HTTP WebSEAL i znajdującego się w strefie DMZ. Sama usługa znajduję się na serwerze WAS a serwer WebSEAL stanowi w tym przypadku Punkt Pojedynczego Kontaktu. Adresy usługi FSSO wystawione na środowisku testowym MSWIA to: https://test-linux-wsgw:9445/sps/saml20fed/saml20/login tu powinna zostać przekierowana przeglądarka użytkownika w celu jego logowania https://test-linux-wsgw:8883/sps/saml20fed/saml20/soap tu weryfikowane jest prawidłowe żądanie SAML2.0 w backchannelu (bez ingerencji użytkownika) pomiędzy serwerem Partnera a dostawcą usługi FSSO.

https://test-linux-wsgw:9445/sps/saml20fed/saml20/slo - tu należy przekierować użytkownika w celu jego wylogowania W celu przyłączenia zewnętrznego partnera do serwera IdP. Partner zobowiązany jest dostarczyć swoje klucze publiczne. IdP będzie używał ich do walidacji podpis oraz szyfrowania wiadomości przekazywanej do SP (wiadomość z tokenem SAML2.0). Dodatkowo partner musi jednorazowo przedstawić IdP informacje w postaci pliku XML w poniższym formacie (W takim samym formacie partner uzyska plik z adresacją i kluczami od IdP). <?xml version="1.0" encoding="utf-8"?><md:entitydescriptor entityid="https://nazwa hosta DNS partnera:bezpieczny port HTTP partnera/sps/nazwa federacji partnera/saml20" xmlns:md="urn:oasis:names:tc:saml:2.0:metadata"> <md:spssodescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolsupportenumeration="urn:oasis:names:tc:saml:2.0:protocol"> <md:keydescriptor use="signing"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate>MIIBzzCCATigAwIBAgIESw/dizANBgkqhkiG9w0BAQQFADAsMQsw CQYDVQQGEwJQTDEMMAoGA1UEChMDSUJNMQ8wDQYDVQQDEwZjbGllbnQwHhcNMD kxmti3mtqwote1whcnmtiwodizmtqwote1wjasmqswcqydvqqgewjqtdemmao GA1UEChMDSUJNMQ8wDQYDVQQDEwZjbGllbnQwgZ8wDQYJKoZIhvcNAQEBBQADgY 0AMIGJAoGBAI0jMQB1awJ6bu8Qi4kYlzUSN26xJQMpUXvpeKwpFlP0ksbjgwQSpkFv4 hnad+mnuuhfhxxwthc4kt2fugy1rg3mzmgthsjhst09slwvbzqz8ezbsv6n1xizqth O3nCeweEts+SICtCUEYKjvtHS+IVCFUQgMnLjTWKmKhk9WydTAgMBAAEwDQYJKoZI hvcnaqeebqadgyeazftz97g8cfgchs0tcmbihwjllwrcnbqtxqot7shhvi9khjntokap HkoSYPjXKB1io3hwR4MhEui0PAEgcGff5Iiq1m4hTksmMQ7JD209o25bW8ZubMhNbzB d42wbowlw10hmwac22iz4gl7wdsofsc98969rrut60qa6dpoju5y=</x509certifi cate> </X509Data> </KeyInfo> </md:keydescriptor> <md:keydescriptor use="encryption"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

<X509Data> <X509Certificate>MIIBzzCCATigAwIBAgIESw/dizANBgkqhkiG9w0BAQQFADAsMQsw CQYDVQQGEwJQTDEMMAoGA1UEChMDSUJNMQ8wDQYDVQQDEwZjbGllbnQwHhcNMD kxmti3mtqwote1whcnmtiwodizmtqwote1wjasmqswcqydvqqgewjqtdemmao GA1UEChMDSUJNMQ8wDQYDVQQDEwZjbGllbnQwgZ8wDQYJKoZIhvcNAQEBBQADgY 0AMIGJAoGBAI0jMQB1awJ6bu8Qi4kYlzUSN26xJQMpUXvpeKwpFlP0ksbjgwQSpkFv4 hnad+mnuuhfhxxwthc4kt2fugy1rg3mzmgthsjhst09slwvbzqz8ezbsv6n1xizqth O3nCeweEts+SICtCUEYKjvtHS+IVCFUQgMnLjTWKmKhk9WydTAgMBAAEwDQYJKoZI hvcnaqeebqadgyeazftz97g8cfgchs0tcmbihwjllwrcnbqtxqot7shhvi9khjntokap HkoSYPjXKB1io3hwR4MhEui0PAEgcGff5Iiq1m4hTksmMQ7JD209o25bW8ZubMhNbzB d42wbowlw10hmwac22iz4gl7wdsofsc98969rrut60qa6dpoju5y=</x509certifi cate> </X509Data> </KeyInfo> <md:encryptionmethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" xmlns:md="http://www.w3.org/2001/04/xmlenc#"/> </md:keydescriptor> <md:artifactresolutionservice Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://nazwa hosta DNS partnera:bezpieczny port SOAP partnera/sps/nazwa federacji partnera/saml20/soap" index="0" isdefault="true"/> <md:singlelogoutservice Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://nazwa hosta DNS partnera:bezpieczny port HTTP partnera/sps/nazwa federacji partnera/saml20/slo"/> <md:singlelogoutservice Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://nazwa hosta DNS partnera:bezpieczny port HTTP partnera/sps/nazwa federacji partnera/saml20/slo"/> <md:singlelogoutservice Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://nazwa hosta DNS partnera:bezpieczny port SOAP partnera/sps/nazwa federacji partnera/saml20/soap"/> <md:nameidformat>urn:oasis:names:tc:saml:2.0:nameidformat:persistent</md:nameidformat>

<md:nameidformat>urn:oasis:names:tc:saml:2.0:nameidformat:transient</md:nameidformat> <md:nameidformat>urn:oasis:names:tc:saml:1.1:nameidformat:emailaddress</md:nameidformat> <md:nameidformat>urn:oasis:names:tc:saml:2.0:nameidformat:encrypted</md:nameidformat> <md:assertionconsumerservice Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP- Artifact" Location="https://nazwa hosta DNS partnera:bezpieczny port HTTP partnera/sps/nazwa federacji partnera/saml20/login" index="0" isdefault="true"/> <md:assertionconsumerservice Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST" Location="https://nazwa hosta DNS partnera:bezpieczny port HTTP partnera/sps/nazwa federacji partnera/saml20/login" index="1"/> </md:spssodescriptor> <md:organization> <md:organizationname xml:lang="en">nazwy organizacji partnera</md:organizationname> <md:organizationdisplayname xml:lang="en">nazwy organizacji partnera</md:organizationdisplayname> <md:organizationurl xml:lang="en"/> </md:organization> <md:contactperson contacttype="technical"> <md:company>opcjonalne nazwy organizacji partnera</md:company> <md:givenname>opcjonalne nazwy organizacji partnera</md:givenname> <md:surname/> <md:emailaddress/> <md:telephonenumber/> </md:contactperson> </md:entitydescriptor>

Plik ten służy do jednorazowego zaimportowania informacji o partnerze i jego atrybutach do komponentu Tivoli Federated Identity Manager w serwerze IdP. Pogrubione fragmenty XMLa to informacja, jakie partner musi uzupełnić własnymi wpisami. W tagach <md:keydescriptor use="signing"> znajduje się klucz partnera służący IdP do walidacji poprawności podpisu. W tagach <md:keydescriptor use="encryption"> znajduje się natomiast klucz publiczny partnera służący do szyfrowania przez IdP komunikatów z tokenami SAML2.0. Inne istotne elementy, jakie należy uzupełnić to nazwy hosta partnera widoczne w DNS IdP (nazwa hosta DNS partnera) oraz porty HTTP i SOAP używane przez system partnera. Ponadto partner może podać opcjonalne informacje dotyczące jego organizacji, które będą widoczne w systemie IdP Pesel2. 4.4 Federacja konta użytkownika pomiędzy IdP a SP Po przeprowadzeniu pomyślnej federacji partnera i IdP należy przeprowadzić federację kont użytkowników, którzy będą wykorzystywani przez aplikację partnera. Użytkownicy ci muszą istnieć w repozytorium TAM Policy Serwer systemu Pesel2 (IdP) Aplikacja partnera ze swojego, uwierzytelnionego kontekstu systemu (aplikacja partnera musi stworzyć generycznego użytkownika w imieniu, którego wysyła żądanie do usługi FSSO potrzebny jest kontekst JAAS) wysyła poniższe żądanie do serwera MSWIA IdP: https://<host usługi FSSO>:<zabezpieczony port HTTP usługi FSSO>/sps/<nazwa federacji>/saml20/logininitial?relaystate=https:// <host usługi FSSO>/FIM/fimivt/protected/ivtlanding.jsp Użytkownik aplikacji partnera uwierzytelnia się za pomocą dostarczonego certyfikatu lub identyfikatora i hasła w formularzu po przekierowaniu na stronę IdP Po pomyślnym uwierzytelnieniu wyświetlona zostaje standardowa strona z informacjami o sfederowanym koncie Powyższe kroki muszą być wykonane jedynie przed pierwszym logowaniem i służą do wymiany unikalnych identyfikatorów użytkowników pomiędzy IdP a SP. Identyfikator ten jest jednorazowo zapisywany w usłudze katalogowej SP.

W przypadku nieprzeprowadzonej federacji konta, użytkownik nie będzie mógł uwierzytelnić się w usłudze FSSO. 4.5 Synchronizacja czasu pomiędzy IdP a SP Ważna kwestia jaka musi być spełniona przy korzystaniu z usługi FSSO to prawidłowa synchronizacja czasu systemowego serwera partnera z serwerem MSWIA. Usługa FSSO sprawdza czas wygenerowania przez zewnętrzne systemy tokenów bezpieczeństwa WS oraz artefaktów weryfikowanych przy uwierzytelnianiu użytkowników. Z powyższego powodu, aby klient mógł prawidłowo komunikować się z usługami MSWIA, dopuszczalna jest pewna tolerancja różnicy czasu pomiędzy systemem MSWIA a systemem zewnętrznym. Parametry te są modyfikowalne na kilka sposobów i można nim sterować za pomocą poniższych ustawień dostępnych z poziomu narzędzia TFIM. Wartości domyślne prezentowane są na rysunku nr 7. Rysunek 7: Parametry modyfikujące czas ważności tokenów bepieczeństwa usługi FSSO Dokładny opis parametrów znajduje się w dokumentacji TFIM dostępnej publicznie pod adresem: http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.tivoli.fim.do c_6.2/welcome.htm Nazwa Parametru Opis

Message Lifetime Artifact Lifetime Amount of time before the issue date that an assertion is considered valid Amount of time the assertion is valid after being issued Dopuszczalna długość ważności, przesyłanej wiadomości z tokenem bezpieczeństwa SAML wyrażona w sekundach Dopuszczalna długość ważności wygenerowanego przez IdP artefaktu wyrażona w sekundach Dopuszczalna długość ważności tokenu bezpieczeństwa wyrażona w sekundach, jeśli data jego wygenerowania jest wcześniejsza od aktualnej daty systemowej IdP Dopuszczalna długość ważności tokenu bezpieczeństwa wyrażona w sekundach, jeśli data jego wygenerowania jest późniejsza od aktualnej daty systemowej IdP

5. Usługa Sieciowa: Autoryzacja Zewnętrzna JACC 5.1 Opis Usługa Zewnętrznej Autoryzacji dostarczana jest w ramach standardu JACC i w oparciu o komponenty WAS i TAM Policy Server. Usługa ta wynosi na zewnątrz zapytania autoryzacyjne użytkowników do zasobów. Dzięki wykonywaniu decyzji autoryzacyjnych w jednym miejscu możliwe jest sprawniejsze i centralne zarządzanie uprawnieniami i dostępem użytkowników do wielu różnych usług. Usługa ta dostępna jest na serwerach WAS dostarczających Usługi Sieciowe Pesel2. Wszystkie role aplikacyjne zdefiniowane w aplikacjach JEE automatycznie eksportowane są do serwera TAM Policy Server, gdzie następuje ich mapowanie na grupy i użytkowników importowanych do TAM z repozytorium LDAP lub list kontroli dostępu (ACL). Obiekty, na które mapowane są role muszą istnieć w bazie TAM Policy Server. 5.2 Adresy JACC Usługa Autoryzacji Zewnętrznej dostępna jest na partycjach zlinux systemu mainframe w formie dwóch usług: Pdmgrd Pdacld Konfiguracja usługi w serwerze WAS: Nazwa parametru WAS Wartość parametru Adres partycji test-linux-tam Port serwera Policy Server (pdacld) 7135 Port serwera Authorization Server (pdmgrd) 7136 Policy class name com.tivoli.pd.as.jacc.tampolicy

Information required Policy configuration factory class name com.tivoli.pd.as.jacc.tampolicyconfigurationfactory Role configuration factory class name com.tivoli.pd.as.jacc.tamroleconfigurationfactory Provider initialization class name com.tivoli.pd.as.jacc.cfg.tamconfiginitialize