Dokumentacja Usług Sieciowych Uwierzytelniania i Autoryzacji. Wersja: 1.00
|
|
- Filip Marczak
- 8 lat temu
- Przeglądów:
Transkrypt
1 Dokumentacja Usług Sieciowych Uwierzytelniania i Autoryzacji Wersja: 1.00
2
3 Spis treści 1. Wprowadzenie Identyfikacja i opis dokumentu Cel Odnośniki Notacja Usługa Sieciowa: Uwierzytelnianie żądań wewnętrznych Opis Adres usług sieciowych Uwierzytelnianie i autoryzacja Usługa Sieciowa: Uwierzytelnianie żądań zewnętrznych Opis Adres Uwierzytelnianie i autoryzacja Usługa Sieciowa: FSSO Opis Uwierzytelnienie i Autoryzacja Adres i wymiana danych pomiędzy IdP a SP Federacja konta użytkownika pomiędzy IdP a SP Synchronizacja czasu pomiędzy IdP a SP Usługa Sieciowa: Autoryzacja Zewnętrzna JACC Opis Adresy JACC... 25
4 1. Wprowadzenie 1.1 Identyfikacja i opis dokumentu Niniejszy dokument stanowi dokumentację Usług Sieciowych wystawionych na potrzeby Uwierzytelniania i Autoryzacji w systemie PESEL 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
5 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 test-linux-wsgw
6 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.
7 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.
8 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: Udostepnianie_InboundPortLTPA_CUBE2Run 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).
9 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 Brama XML weryfikuje otrzymane żądanie 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 Brama XML wywołuje docelową Usługę Sieciową
10 Serwer Usług Sieciowych weryfikuje integralność (podpis) wiadomości i jeśli jest prawidłowy przygotowuje wynik Serwer UŚ podpisuje żądanie z wynikiem Brama XML odbiera odpowiedź UŚ Brama XML weryfikuje integralność otrzymanej wiadomości Brama XML podpisuje nowe żądanie dla aplikacji GUI zawierające wynik 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.
11 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
12 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: _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.
13 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:
14 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 Żądnie jest przekazywane do Bramy XML a następnie wiadomość jest rozszyfrowywana i weryfikowana pod kątem jej integralności 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 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Ś Serwer UŚ weryfikuje podpis otrzymanego żądania, jeśli jest poprawny przetwarza je i zwraca wynik (także podpisany)
15 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
16 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: 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.
17 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) Użytkownik uwierzytelnia się w IdP przy użyciu identyfikatora lub hasła lub certyfikatu X.509 wydanego przez MSWIA
18 IdP w przypadku pomyślnego uwierzytelnienia przekierowuje użytkownika z powrotem przesyłając dodatkowo artefakt będący wygenerowanym przez IdP unikalnym identyfikatorem (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 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 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: tu powinna zostać przekierowana przeglądarka użytkownika w celu jego logowania tu weryfikowane jest prawidłowe żądanie SAML2.0 w backchannelu (bez ingerencji użytkownika) pomiędzy serwerem Partnera a dostawcą usługi FSSO.
19 - 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=" 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=" <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="
20 <X509Data> <X509Certificate>MIIBzzCCATigAwIBAgIESw/dizANBgkqhkiG9w0BAQQFADAsMQsw CQYDVQQGEwJQTDEMMAoGA1UEChMDSUJNMQ8wDQYDVQQDEwZjbGllbnQwHhcNMD kxmti3mtqwote1whcnmtiwodizmtqwote1wjasmqswcqydvqqgewjqtdemmao GA1UEChMDSUJNMQ8wDQYDVQQDEwZjbGllbnQwgZ8wDQYJKoZIhvcNAQEBBQADgY 0AMIGJAoGBAI0jMQB1awJ6bu8Qi4kYlzUSN26xJQMpUXvpeKwpFlP0ksbjgwQSpkFv4 hnad+mnuuhfhxxwthc4kt2fugy1rg3mzmgthsjhst09slwvbzqz8ezbsv6n1xizqth O3nCeweEts+SICtCUEYKjvtHS+IVCFUQgMnLjTWKmKhk9WydTAgMBAAEwDQYJKoZI hvcnaqeebqadgyeazftz97g8cfgchs0tcmbihwjllwrcnbqtxqot7shhvi9khjntokap HkoSYPjXKB1io3hwR4MhEui0PAEgcGff5Iiq1m4hTksmMQ7JD209o25bW8ZubMhNbzB d42wbowlw10hmwac22iz4gl7wdsofsc98969rrut60qa6dpoju5y=</x509certifi cate> </X509Data> </KeyInfo> <md:encryptionmethod Algorithm=" xmlns:md=" </md:keydescriptor> <md:artifactresolutionservice Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location=" 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=" 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=" 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=" 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>
21 <md:nameidformat>urn:oasis:names:tc:saml:2.0:nameidformat:transient</md:nameidformat> <md:nameidformat>urn:oasis:names:tc:saml:1.1:nameidformat: address</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=" 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=" 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: address/> <md:telephonenumber/> </md:contactperson> </md:entitydescriptor>
22 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 Pesel 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: usługi FSSO>:<zabezpieczony port HTTP usługi FSSO>/sps/<nazwa federacji>/saml20/logininitial?relaystate= <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.
23 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: c_6.2/welcome.htm Nazwa Parametru Opis
24 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
25 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
26 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
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,
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
PolishAPI. Rekomendacje oraz podstawowe założenia do przygotowania interfejsu awaryjnego. Dokument opracowany przez Grupę Projektową ds.
PolishAPI Rekomendacje oraz podstawowe założenia do przygotowania interfejsu awaryjnego Dokument opracowany przez Grupę Projektową ds. PolishAPI 8 lipca 2019 Wersja 1.0 Spis treści 1 Wstęp i zastrzeżenia...
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
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)
elektroniczna Platforma Usług Administracji Publicznej
elektroniczna Platforma Usług Administracji Publicznej Instrukcja użytkownika Profil Zaufany wersja 04-01 SPIS TREŚCI Ministerstwo Spraw Wewnętrznych i Administracji ul. Batorego 5, 02-591 Warszawa www.epuap.gov.pl.
elektroniczna Platforma Usług Administracji Publicznej
elektroniczna Platforma Usług Administracji Publicznej Instrukcja użytkownika Profil Zaufany wersja 02-02. Ministerstwo Spraw Wewnętrznych i Administracji ul. Batorego 5, 02-591 Warszawa www.epuap.gov.pl
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
Instrukcja konfiguracji funkcji skanowania
Instrukcja konfiguracji funkcji skanowania WorkCentre M123/M128 WorkCentre Pro 123/128 701P42171_PL 2004. Wszystkie prawa zastrzeżone. Rozpowszechnianie bez zezwolenia przedstawionych materiałów i informacji
Konfiguracja poczty IMO w programach Microsoft Outlook oraz Mozilla Thunderbird
Konfiguracja poczty IMO w programach Microsoft Outlook oraz Mozilla Thunderbird 1. Mozilla Thunderbird Rozpocząć konfigurację IMO poczty należy od kliknięcia opcji utworzenia nowego konta w programie.
Dokumentacja użytkownika systemu wnioskowania i zarządzania certyfikatami BPTP O3 w systemie ITIM Wersja 2.1
Dokumentacja użytkownika systemu wnioskowania i zarządzania certyfikatami BPTP O3 w systemie ITIM Wersja 2.1 1 1 Wstęp... 3 2 Wnioskowanie o certyfikaty... 3 2.1 Wnioskowanie o certyfikat przez partnera...
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
Zdalne logowanie do serwerów
Zdalne logowanie Zdalne logowanie do serwerów Zdalne logowanie do serwerów - cd Logowanie do serwera inne podejście Sesje w sieci informatycznej Sesje w sieci informatycznej - cd Sesje w sieci informatycznej
Korzystanie z Certyfikatów CC Signet w programie MS Outlook 98
Korzystanie z Certyfikatów CC Signet w programie MS Outlook 98 1. Wprowadzenie... 2 2. Podpisywanie i szyfrowanie wiadomości pocztowych... 2 2.1. Wysyłanie wiadomości z podpisem cyfrowym... 3 2.2. Odbieranie
Projektowanie obiektowe oprogramowania Wykład 14 Architektura systemów (1), Interoperability Wiktor Zychla 2013
Projektowanie obiektowe oprogramowania Wykład 14 Architektura systemów (1), Interoperability Wiktor Zychla 2013 1 Architektura aplikacji rozległych Aplikacje rozległe (ang. Enterprise applications) to
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
Polityka prywatności Spółdzielni Mieszkaniowej Słoneczny Stok
Polityka prywatności Spółdzielni Mieszkaniowej Słoneczny Stok Spółdzielnia Mieszkaniowa Słoneczny Stok szanuje prawo do prywatności Użytkowników serwisu sm-slonecznystok.pl. W szczególności dba o ochronę
Instrukcja obsługi certyfikatów w programie pocztowym MS Outlook Express 5.x/6.x
Spis treści Wstęp... 1 Instalacja certyfikatów w programie pocztowym... 1 Instalacja certyfikatów własnych... 1 Instalacja certyfikatów innych osób... 3 Import certyfikatów innych osób przez odebranie
elektroniczna Platforma Usług Administracji Publicznej
elektroniczna Platforma Usług Administracji Publicznej Instrukcja użytkownika Profil Zaufany wersja 7.3. Ministerstwo Spraw Wewnętrznych i Administracji ul. Batorego 5, 02-591 Warszawa www.epuap.gov.pl
SET (Secure Electronic Transaction)
SET (Secure Electronic Transaction) Krzysztof Maćkowiak Wprowadzenie SET (Secure Electronic Transaction) [1] to protokół bezpiecznych transakcji elektronicznych. Jest standardem umożliwiający bezpieczne
Problemy z bezpieczeństwem w sieci lokalnej
Problemy z bezpieczeństwem w sieci lokalnej możliwości podsłuchiwania/przechwytywania ruchu sieciowego pakiet dsniff demonstracja kilku narzędzi z pakietu dsniff metody przeciwdziałania Podsłuchiwanie
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
POLITYKA PRYWATNOŚCI ORAZ POLITYKA PLIKÓW COOKIES W Sowa finanse
POLITYKA PRYWATNOŚCI ORAZ POLITYKA PLIKÓW COOKIES W Sowa finanse I. Definicje Niżej wymienione pojęcia użyte w Polityce prywatności lub Polityce Plików cookies należy rozumieć następująco: Administrator
Portal SRG BFG Instrukcja korzystania z Portalu SRG BFG
Portal SRG BFG Instrukcja korzystania z Portalu SRG BFG Opracowano w Departamencie Informatyki Bankowego Funduszu Gwarancyjnego Październik 2016 Spis treści: 1. Dostęp do strony Portalu... 3 1.1. Adres
Java wybrane technologie
Java wybrane technologie spotkanie nr 14 Bezpieczeństwo Podstawowe pojęcia uwierzytelniania (authentication) autoryzacja (authorization) atrybuty bezpieczeństwa informacji integralność danych (data integrity)
Dokumentacja SMS przez FTP
Dokumentacja SMS przez FTP 1 Wprowadzenie... 2 Właściwości plików... 3 Tworzenie konfiguracji w Panelu Klienta... 4 Raporty doręczeń... 5 Historia zmian... 6 2 Wprowadzenie Usługa wysyłki SMS przez FTP
Ministerstwo Finansów
Ministerstwo Finansów Departament Informatyzacji Specyfikacja Wejścia-Wyjścia Wersja 1.0 Warszawa, 16.02.2017 r. Copyright (c) 2017 Ministerstwo Finansów MINISTERSTWO FINANSÓW, DEPARTAMENT INFORMATYZACJI
SSL (Secure Socket Layer)
SSL --- Secure Socket Layer --- protokół bezpiecznej komunikacji między klientem a serwerem, stworzony przez Netscape. SSL w założeniu jest podkładką pod istniejące protokoły, takie jak HTTP, FTP, SMTP,
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.
Obsługa poczty elektronicznej w domenie emeritus.ue.poznan.pl
Obsługa poczty elektronicznej w domenie emeritus.ue.poznan.pl Centrum Informatyki http://ci.ue.poznan.pl helpdesk@ue.poznan.pl al. Niepodległości 10, 61-875 Poznań tel. + 48 61 856 90 00 NIP: 777-00-05-497
Portal SRG BFG. Instrukcja korzystania z Portalu SRG BFG
Portal SRG BFG Instrukcja korzystania z Portalu SRG BFG Opracowano w Departamencie Informatyki i Administracji Bankowego Funduszu Gwarancyjnego Październik 2013 Spis treści: 1. Dostęp do strony portalu...
GS2TelCOMM. Rozszerzenie do TelCOMM 2.0. Opracował: Michał Siatkowski Zatwierdził: IMIĘ I NAZWISKO
GS2TelCOMM Rozszerzenie do TelCOMM 2.0 Opracował: Michał Siatkowski 29-03-2017 Zatwierdził: IMIĘ I NAZWISKO DATA TEL-STER 2017 Spis treści Wprowadzenie... 3 Architektura... 3 Instalacja... 3 Współpraca
ZABEZPIECZENIE KOMUNIKACJI Z SYSTEMEM E-PŁATNOŚCI
PROJEKT: ZAPROJEKTOWANIE, WYKONANIE I WDROŻENIE SYSTEMU INFORMATYCZNEGO OBSŁUGUJĄCEGO E-PŁATNOŚCI ZABEZPIECZENIE KOMUNIKACJI Z SYSTEMEM E-PŁATNOŚCI Strona 1 z 19 Informacje o Historia zmian Wprowadzenie
POLITYKA CERTYFIKACJI KIR dla ZAUFANYCH CERTYFIKATÓW NIEKWALIFIKOWANYCH
Krajowa Izba Rozliczeniowa S.A. POLITYKA CERTYFIKACJI KIR dla ZAUFANYCH CERTYFIKATÓW NIEKWALIFIKOWANYCH Wersja 1.7 Historia dokumentu Numer wersji Status Data wydania 1.0 Dokument zatwierdzony przez Zarząd
Polityka prywatności i bezpieczeństwa przetwarzania danych osobowych w zbiorze czas-na-przeglad.pl
Poznań, 24.01.2011 Polityka prywatności i bezpieczeństwa przetwarzania danych osobowych w zbiorze czas-na-przeglad.pl Realizując postanowienia ustawy z dnia 29.08.1997r. o ochronie danych osobowych (Dz.
4. Podstawowa konfiguracja
4. Podstawowa konfiguracja Po pierwszym zalogowaniu się do urządzenia należy zweryfikować poprawność licencji. Można to zrobić na jednym z widżetów panelu kontrolnego. Wstępną konfigurację można podzielić
elektroniczna Platforma Usług Administracji Publicznej
elektroniczna Platforma Usług Administracji Publicznej Instrukcja użytkownika Profil Zaufany wersja 7.4. Ministerstwo Spraw Wewnętrznych i Administracji ul. Batorego 5, 02-591 Warszawa www.epuap.gov.pl
POLITYKA CERTYFIKACJI KIR dla ZAUFANYCH CERTYFIKATÓW NIEKWALIFIKOWANYCH
Krajowa Izba Rozliczeniowa S.A. POLITYKA CERTYFIKACJI KIR dla ZAUFANYCH CERTYFIKATÓW NIEKWALIFIKOWANYCH Wersja 1.5 Historia dokumentu Numer wersji Status Data wydania 1.0 Dokument zatwierdzony przez Zarząd
System Kancelaris. Zdalny dostęp do danych
Kancelaris krok po kroku System Kancelaris Zdalny dostęp do danych Data modyfikacji: 2008-07-10 Z czego składaj adają się systemy informatyczne? System Kancelaris składa się z dwóch części: danych oprogramowania,
POLITYKA PRYWATNOŚCI ORAZ ZASADY PRZETWARZANIA DANYCH OSOBOWYCH
POLITYKA PRYWATNOŚCI ORAZ ZASADY PRZETWARZANIA DANYCH OSOBOWYCH IPMS spółka z ograniczoną odpowiedzialnością ( IPMS ) dokłada wszelkich starań by chronić Państwa dane osobowe przed nieuprawnionym dostępem
Modele uwierzytelniania, autoryzacji i kontroli dostępu do systemów komputerowych.
Modele uwierzytelniania, autoryzacji i kontroli dostępu do systemów komputerowych. Uwierzytelnianie, autoryzacja i kontrola dostępu Funkcjonowanie internetu w dużej mierze opiera się na zaufaniu i kontroli
Instrukcja aktywacji tokena w usłudze BPTP
Instrukcja aktywacji tokena w usłudze BPTP Użytkownicy usługi BPTP, którzy otrzymali przesyłki pocztowe zawierające token USB wraz z listem informującym o potrzebie aktywacji urządzenia powinni wykonać
Wprowadzenie do PKI. 1. Wstęp. 2. Kryptografia symetryczna. 3. Kryptografia asymetryczna
1. Wstęp Wprowadzenie do PKI Infrastruktura klucza publicznego (ang. PKI - Public Key Infrastructure) to termin dzisiaj powszechnie spotykany. Pod tym pojęciem kryje się standard X.509 opracowany przez
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
Bezpieczeństwo systemów informatycznych
Politechnika Poznańska Bezpieczeństwo systemów rozproszonych Bezpieczeństwo systemów informatycznych ĆWICZENIE VPN 1. Tunele wirtualne 1.1 Narzędzie OpenVPN OpenVPN jest narzędziem służącym do tworzenia
Polityka Certyfikacji dla Certyfikatów PEMI
Centrum Certyfikacji PEMI Ul. Stefana Bryły 3/582 02-685 Warszawa Polityka Certyfikacji dla Certyfikatów PEMI wersja 1.0 Spis treści: 1 Wprowadzenie... 3 1.1 Identyfikator polityki... 3 1.2 Historia zmian...
INSTRUKCJA OBSŁUGI DLA SIECI
INSTRUKCJA OBSŁUGI DLA SIECI Zapisywanie dziennika druku w lokalizacji sieciowej Wersja 0 POL Definicje dotyczące oznaczeń w tekście W tym Podręczniku użytkownika zastosowano następujące ikony: Uwagi informują
Opis konfiguracji i wysyłki wniosków EKW w aplikacji Komornik SQL-VAT
Opis konfiguracji i wysyłki wniosków EKW w aplikacji Komornik SQL-VAT 2016 Currenda Sp. z o.o. Spis treści 1. Wstęp... 3 2. Instalacja certyfikatu EKW... 3 2.1. Instalacja na nową kartę... 3 2.2. Instalacja
Kierunek: technik informatyk 312[01] Semestr: II Przedmiot: Urządzenia techniki komputerowej Nauczyciel: Mirosław Ruciński
Kierunek: technik informatyk 312[01] Semestr: II Przedmiot: Urządzenia techniki komputerowej Nauczyciel: Mirosław Ruciński Temat 8.9. Wykrywanie i usuwanie awarii w sieciach komputerowych. 1. Narzędzia
Połączenie VPN SSL Web Proxy. 1. Konfiguracja serwera VPN 1.1. Ustawienia ogólne 1.2. Profile SSL Web Proxy 1.3. Konto SSL 1.4. Grupa użytkowników
1. Konfiguracja serwera VPN 1.1. Ustawienia ogólne 1.2. Profile SSL Web Proxy 1.3. Konto SSL 1.4. Grupa użytkowników 2. Konfiguracja klienta VPN 3. Status połączenia 3.1. Klient VPN 3.2. Serwer VPN Procedura
i-bank Mobile Banking INSTRUKCJA OBSŁUGI v3
i-bank Mobile Banking INSTRUKCJA OBSŁUGI v3 Przedsiębiorstwo Informatyczne SABA SERVICE Sp. z o.o. ul. Gorzowska 64 74-320 Barlinek tel. (0-95) 74-64-402 fax. (0-95) 74-60-242 e-mail biuro@sabaservice.net
OBSŁUGA I KONFIGURACJA SIECI W WINDOWS
OBSŁUGA I KONFIGURACJA SIECI W WINDOWS Jak skonfigurować komputer pracujący pod kontrolą systemu operacyjnego Windows 7, tak aby uzyskać dostęp do internetu? Zakładamy, że komputer pracuje w małej domowej
Czym są pliki cookies?
Czym są pliki cookies? Poprzez pliki cookies należy rozumieć dane informatyczne, w szczególności pliki tekstowe, przechowywane w urządzeniach końcowych użytkowników przeznaczone do korzystania ze stron
Instrukcja konfigurowania poczty Exchange dla klienta pocztowego użytkowanego poza siecią uczelnianą SGH.
Instrukcja konfigurowania poczty Exchange dla klienta pocztowego użytkowanego poza siecią uczelnianą SGH. Spis treści 1. Konfiguracja poczty Exchange dla klienta pocztowego Outlook 2007 protokół Exchange
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
12. Wirtualne sieci prywatne (VPN)
12. Wirtualne sieci prywatne (VPN) VPN to technologia tworzenia bezpiecznych tuneli komunikacyjnych, w ramach których możliwy jest bezpieczny dostęp do zasobów firmowych. Ze względu na sposób połączenia
NetIQ Access Manager. Broszura informacyjna. Kontrola dostępu, zarządzanie regułami, zapewnienie zgodności. www.netiq.pl
Broszura informacyjna www.netiq.pl ZARZĄDZANIE TOŻSAMOŚCIĄ I BEZPIECZEŃSTWO NetIQ Access Manager Kontrola dostępu, zarządzanie regułami, zapewnienie zgodności Wprowadzenie Konkurencyjność współczesnej
Opis przykładowego programu realizującego komunikację z systemem epuap wykorzystując interfejs komunikacyjny "doręczyciel"
Opis przykładowego programu realizującego komunikację z systemem epuap wykorzystując interfejs komunikacyjny "doręczyciel" dn.24.09.2009 r. Dokument opisuje przykładowy program doręczający dokumenty na
Serwer SSH. Wprowadzenie do serwera SSH Instalacja i konfiguracja Zarządzanie kluczami
Serwer SSH Serwer SSH Wprowadzenie do serwera SSH Instalacja i konfiguracja Zarządzanie kluczami Serwer SSH - Wprowadzenie do serwera SSH Praca na odległość potrzeby w zakresie bezpieczeństwa Identyfikacja
bla bla Guard podręcznik użytkownika
bla bla Guard podręcznik użytkownika Guard Guard: podręcznik użytkownika data wydania środa, 03. wrzesień 2014 Version 1.0 Copyright 2006-2014 OPEN-XCHANGE Inc., Niniejszy dokument stanowi własność intelektualną
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...
ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ
ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ WYMAGANIA BEZPIECZEŃSTWA DLA SYSTEMÓW IT Wyciąg z Polityki Bezpieczeństwa Informacji dotyczący wymagań dla systemów informatycznych. 1 Załącznik Nr 3 do Część II SIWZ Wymagania
Wykład 4. Metody uwierzytelniania - Bezpieczeństwo (3) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz
Wykład 4 Metody uwierzytelniania - Bezpieczeństwo (3) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz Struktura wykładu 1. Protokół SSL do zabezpieczenia aplikacji na poziomie protokołu transportowego
Currenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3
Currenda EPO Instrukcja Konfiguracji Wersja dokumentu: 1.3 Currenda EPO Instrukcja Konfiguracji - wersja dokumentu 1.3-19.08.2014 Spis treści 1 Wstęp... 4 1.1 Cel dokumentu... 4 1.2 Powiązane dokumenty...
Kurs OPC S7. Spis treści. Dzień 1. I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501)
Spis treści Dzień 1 I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501) I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami
Instrukcja instalacji Control Expert 3.0
Instrukcja instalacji Control Expert 3.0 Program Control Expert 3.0 jest to program służący do zarządzania urządzeniami kontroli dostępu. Dedykowany jest dla kontrolerów GRx02 i GRx06 oraz rozwiązaniom
Skrócona instrukcja konfiguracji skanowania iwysyłania wiadomości e-mail
Xerox WorkCentre M118i Skrócona instrukcja konfiguracji skanowania iwysyłania wiadomości e-mail 701P42708 Ta instrukcja zawiera instrukcje niezbędne do konfiguracji funkcji skanowania i wysyłania wiadomości
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)...
Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B
Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B NAZWA ZADANIA ZADANIE CZĄSTKOWE TECHNOLOGIA ILOŚĆ OSÓB ILOŚĆ GODZIN TERMIN REALIZACJI 1 2 4 5 6 7 Zadanie 1 - wersji alfa 1 systemu B2B 3 723
Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl
Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl wersja.2.9 data 2014-11-21 Opis usług: P24 KOD P24 KLUCZ P24 WAPA SEND SMS Strona 1 z 8 P24 KOD Przebieg transakcji Operacje po stronie Sprzedawcy
Przewodnik technologii ActivCard
PROFESJONALNE USŁUGI BEZPIECZEŃSTWA Przewodnik technologii ActivCard Część VIII. Wykorzystanie kart Smart Card w systemie identyfikacji cyfrowej ActivPack CLICO Sp. z o.o., Al. 3-go Maja 7, 30-063 Kraków;
procertum SmartSign 3.2 kwalifikowany i niekwalifikowany znacznik czasu instrukcja obsługi wersja UNIZETO TECHNOLOGIES SA
procertum SmartSign 3.2 kwalifikowany i niekwalifikowany znacznik czasu instrukcja obsługi wersja 1.0.2 Spis treści 1. URUCHOMIENIE APLIKACJI... 3 2. KONFIGURACJA - USTAWIENIA OGÓLNE... 4 3. KONFIGURACJA
Połączenie VPN aplikacji SSL. 1. Konfiguracja serwera VPN 1.1. Ustawienia ogólne 1.2. Profile aplikacji SSL 1.3. Konto SSL 1.4. Grupa użytkowników
1. Konfiguracja serwera VPN 1.1. Ustawienia ogólne 1.2. Profile aplikacji SSL 1.3. Konto SSL 1.4. Grupa użytkowników 2. Konfiguracja klienta VPN 2.1. Ustawienia ogólne 2.2. Aplikacja VNC 2.3. Aplikacja
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
Wszystkie parametry pracy serwera konfigurujemy w poszczególnych zakładkach aplikacji, podzielonych wg zakresu funkcjonalnego.
Sz@rk Server - konfigurowanie systemu Sz@rk Server jest serwerem aplikacji z wydzieloną logiką biznesową, pracującym w architekturze opartej o usługi (SOA). Dane pomiędzy serwerem i klientami przesyłane
Wymagania bezpieczeństwa wobec statycznych bezpośrednich 1-fazowych i 3-fazowych liczników energii elektrycznej. Wymaganie techniczne
Wymagania bezpieczeństwa wobec statycznych bezpośrednich 1-fazowych i 3-fazowych liczników energii elektrycznej Lp. 1. Wymagania ogólne Wymaganie techniczne 1.1 Licznik musi posiadać aktywną funkcję Watchdog
Połączenie VPN LAN-LAN IPSec X.509 (stały IP > stały IP)
Zestawienie tunelu VPN po protokole IPSec pomiędzy routerem Vigor 2910 (klient VPN) a VigorPro 5500 (serwer VPN). 1. Certyfikaty na routerach Vigor 1.1. Ustawienie czasu 1.2. Lokalny certyfikat (żądanie
Laboratorium Ericsson HIS NAE SR-16
Laboratorium Ericsson HIS NAE SR-16 HIS WAN (HIS 2) Opis laboratorium Celem tego laboratorium jest poznanie zaawansowanej konfiguracji urządzenia DSLAM Ericsson HIS NAE SR-16. Konfiguracja ta umożliwi
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
ekopia w Chmurze bezpieczny, zdalny backup danych
ekopia w Chmurze bezpieczny, zdalny backup danych Instrukcja użytkownika dla klientów systemu mmedica Wersja 1.0 Data ostatniej aktualizacji: 25.03.2015 Spis treści 1 Wstęp... 3 2 Rejestracja... 4 3 Korzystanie
Zadanie1: Odszukaj w serwisie internetowym Wikipedii informacje na temat protokołu http.
T: Konfiguracja usługi HTTP w systemie Windows. Zadanie1: Odszukaj w serwisie internetowym Wikipedii informacje na temat protokołu http. HTTP (ang. Hypertext Transfer Protocol) protokół transferu plików
Certyfikat niekwalifikowany zaufany Certum Silver. Instalacja i użytkowanie pod Windows Vista. wersja 1.0 UNIZETO TECHNOLOGIES SA
Certyfikat niekwalifikowany zaufany Certum Silver Instalacja i użytkowanie pod Windows Vista wersja 1.0 Spis treści 1. POBRANIE CERTYFIKATU SILVER... 3 2. IMPORT CERTYFIKATU DO PROGRAMU POCZTA SYSTEMU
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
1. Zakres modernizacji Active Directory
załącznik nr 1 do umowy 1. Zakres modernizacji Active Directory 1.1 Opracowanie szczegółowego projektu wdrożenia. Określenie fizycznych lokalizacji serwerów oraz liczby lokacji Active Directory Określenie
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
procertum SmartSign 3.2 wersja 1.0.2
Instrukcja obsługi- kwalifikowany i niekwalifikowany znacznik czasu procertum SmartSign 3.2 wersja 1.0.2 Spis treści 1. URUCHOMIENIE APLIKACJI... 3 2. KONFIGURACJA - USTAWIENIA OGÓLNE... 4 3. KONFIGURACJA
Instrukcja generowania żądania CSR SOW WERSJA 1.6
Instrukcja generowania żądania CSR SOW WERSJA 1.6 Informacja o wydaniu Data wydania Wersja Opis wydania 2018.01.11 1.0 Wydanie pierwsze 2018.01.26 1.1 Wydanie 1.1 2018.02.02 1.2 Wydanie 1.2 2018.02.13
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
Enkapsulacja RARP DANE TYP PREAMBUŁA SFD ADRES DOCELOWY ADRES ŹRÓDŁOWY TYP SUMA KONTROLNA 2 B 2 B 1 B 1 B 2 B N B N B N B N B Typ: 0x0835 Ramka RARP T
Skąd dostać adres? Metody uzyskiwania adresów IP Część sieciowa Jeśli nie jesteśmy dołączeni do Internetu wyssany z palca. W przeciwnym przypadku numer sieci dostajemy od NIC organizacji międzynarodowej
DESlock+ szybki start
DESlock+ szybki start Wersja centralnie zarządzana Wersja bez centralnej administracji standalone WAŻNE! Pamiętaj, że jeśli chcesz korzystać z centralnego zarządzania koniecznie zacznij od instalacji serwera
PODSTAWOWA KONFIGURACJA LINKSYS WRT300N
PODSTAWOWA KONFIGURACJA LINKSYS WRT300N 1. Topologia połączenia sieci WAN i LAN (jeśli poniższa ilustracja jest nieczytelna, to dokładny rysunek topologii znajdziesz w pliku network_konfigurowanie_linksys_wrt300n_cw.jpg)
VPN Host-LAN IPSec X.509 z wykorzystaniem DrayTek Smart VPN Client
1. Konfiguracja serwera VPN 1.1. Włączenie obsługi IPSec 1.2. Ustawienie czasu 1.3. Lokalny certyfikat (żądanie certyfikatu z serwera CA) 1.4. Certyfikat zaufanego CA 1.5. Identyfikator IPSec 1.6. Profil
Połączenie VPN Host-LAN SSL z wykorzystaniem przeglądarki. 1. Konfiguracja serwera VPN 1.1. Ustawienia ogólne 1.2. Konto SSL 1.3. Grupa użytkowników
1. Konfiguracja serwera VPN 1.1. Ustawienia ogólne 1.2. Konto SSL 1.3. Grupa użytkowników 2. Konfiguracja klienta VPN 3. Status połączenia 3.1. Klient VPN 3.2. Serwer VPN Procedura konfiguracji została
Administratora CSIZS - OTM
Powykonawcza Dokumentacja Wykonawca: Asseco Poland S.A. Ul. Olchowa 14, 35-322 Rzeszów Informacje o dokumencie: Autor Zespół ds. Wytwarzania i Analizy Tytuł Produkt 33.3 Dokumentacja administratora OTM
E-administracja. Korzystanie z Elektronicznej Platformy Usług Administracji Publicznej
Szkolenie komputerowe: E-administracja. Korzystanie z Elektronicznej Platformy Usług Administracji Publicznej W ramach projektu Seniorzy w przestrzeni publicznej (FIO 2014) PROWADZĄCY: ŁUKASZ KUCHA 1 Czym
Exchange 2013. Konfiguracja protokołu SSL/TLS w serwerze pocztowym Exchange 2013. wersja 1.0
Exchange 2013 Konfiguracja protokołu SSL/TLS w serwerze pocztowym Exchange 2013 wersja 1.0 Spis treści 1. GENEROWANIE ŻĄDANIA WYSTAWIENIA CERTYFIKATU (NA PRZYKŁADZIE CERTYFIKATU TYPU WILDCARD I DOMENY
Ministerstwo Finansów
Ministerstwo Finansów Departament Informatyzacji Rejestr Domen Służących do Oferowania Gier Hazardowych Niezgodnie z Ustawą Specyfikacja Wejścia-Wyjścia Wersja 1.1 Warszawa, 16.02.2017 r. Copyright (c)
Konfiguracja bezpiecznego tunelu IPSec VPN w oparciu o bramę ZyWall35 i klienta ZyXEL RSC (Remote Security Client).
. ZyXEL Communications Polska, Dział Wsparcia Technicznego Konfiguracja bezpiecznego tunelu IPSec VPN w oparciu o bramę ZyWall35 i klienta ZyXEL RSC (Remote Security Client). Niniejszy dokument przedstawia
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
Instrukcja logowania i realizacji podstawowych transakcji w systemie bankowości internetowej dla klientów biznesowych BusinessPro.
Instrukcja logowania i realizacji podstawowych transakcji w systemie bankowości internetowej dla klientów biznesowych BusinessPro aktualizacja: 8 listopada 2017 r. Spis treści: 1. Logowanie do bankowości