Toru 2829 10 2014 Dostawca tosamoci Id P

Toruń 28/29. 10. 2014 Dostawca tożsamości (Id. P) Shibboleth Id. P Maja Górecka-Wolniewicz mgw@umk. pl

Oprogramowanie Shibboleth Id. P • Shibboleth Id. P to standardowa aplikacja webowa w Javie, oparta na specyfikacji Servlet 2. 4 • Wymagania dotyczące Javy – java 1. 7 / Open. JDK 7 • Usługa NTP – niezbędna jest synchronizacja czasu! • Narzędzia do obsługi bazy danych użytkowników – Klient Open. LDAP, jeśli korzystamy z LDAP-a – Klient My. SQL, jeśli korzystamy z bazy My. SQL • My. SQL JDBC connector – https: //dev. mysql. com/downloads/connector/j/

Oprogramowanie Shibboleth Id. P • Środowisko pracy - kontener aplikacji webowych umożliwiający uruchamianie aplikacji w technologiach Java Servlets, Java Server Pages (JSP) – Apache Tomcat – Jetty 7 – JBoss Tomcat • Apache 2. 2/2. 4 z modułami mod_ssl i mod_proxy_ajp

Instalacja Shibboleth Id. P • Pobranie Shibboleth Id. P v. 2. 4. 2 – Strona https: //shibboleth. net/downloads/identity-provider wget https: //shibboleth. net/downloads/identityprovider/2. 4. 2/shibboleth-identityprovider-2. 4. 2 bin. tar. gz Nie należy instalować wersji poniżej 2. 4. 2 • Szczegółowe instrukcje instalacyjne znajdują się na stronach: – https: //wiki. shibboleth. net/confluence/display/SHIB 2/Id. PInstall – https: //wiki. aai. pionier. net. pl/index. php/Federacja: Shibboleth_Id. P

Instalacja Shibboleth Id. P • Rozpakowanie pakietu np. w katalogu /opt • Instalacja w docelowym katalogu: cd /opt/shibboleth-identityprovider-2. 4. 2. /install. sh – domyślny katalog instalacyjny to /opt/shibboleth-idp – podajemy nazwę tworzonego Id. P (np. logon. example. pl) – w trakcie instalacji jest generowana para klucz prywatny, certyfikat (self-signed), używana do podpisywania i szyfrowania metadanych – należy podać hasło chroniące magazyn – budowana jest aplikacja, która zostaje umieszczona w katalogu /opt/shibboleth-idp/war – kopiowane są pliki konfiguracyjne i biblioteki

Tomcat • W konfiguracji serwera tomcat wskazujemy położenie aplikacji Shibboleth Id. P: – w pliku /etc/tomcat/Catalina/localhost/idp. xml wpisujemy <Context doc. Base="/opt/shibboleth-idp/war/idp. war" privileged="true" anti. Resource. Locking="false" anti. JARLocking="false" unpack. WAR="false" swallow. Output="true" /> – tworzymy katalog dla dodatkowych bibliotek mkdir -p /var/lib/tomcat/common/endorsed echo 'JAVA_ENDORSED_DIRS="/var/lib/tomcat/common/endorsed"' >> /etc/tomcat. conf cp /opt/shibboleth-identityprovider-2. 4. 2/endorsed/* /var/lib/tomcat/common/endorsed/

Tomcat, serwer httpd • Modyfikujemy plik konfiguracyjny /etc/tomcat/server. xml, aby był aktywny konektor AJP/1. 3 <Connector port="8009" enable. Lookups="false" redirect. Port="8443" protocol="AJP/1. 3" request. tomcat. Authentication="false" address="127. 0. 0. 1" /> • Dostosowujemy konfigurację httpd, by połączenie z serwerem było przekazywane do tomcata echo 'Proxy. Pass /idp/ ajp: //localhost: 8009/idp/' > /etc/httpd/conf. d/proxy_ajp. conf • Konfigurujemy serwer wirtualny https – serwer docelowo musi korzystać z certyfikatu wystawionego przez ogólnie znany urząd, np. TCS

Uruchomienie / restart usługi • Shibboleth Id. P domyślnie wysyła logi do plików w katalogu /opt/shibboleth-idp/logs – aplikacja pracuje z uprawnieniami użytkownika tomcat – trzeba zagwarantować prawo do zapisu • Restartujemy usługi httpd i tomcat • Metadane Id. P powinny być już dostępne pod adresem https: //logon. example. pl/idp/shibboleth

Konfiguracja Shibboleth Id. P • Pliki konfiguracyjne są zlokalizowane w katalogu /opt/shibboleth-idp/conf – relying-party. xml – attribute-resolver. xml – attribute-filter. xml – login. xml – handler. xml – logging. xml

Plik relying-party. xml • Termin relying party – na ogół Id. P komunikuje się z dostawcą usługi (SP), ale w zaawansowanych zastosowaniach może również komunikować się z innymi Id. P, dlatego Shibboleth używa terminu relying party, by wskazać stronę, z którą jest realizowana komunikacja (partnera) – trzy kategorie relying parties: • anonymous <Anonymous. Relying. Party> – Id. P nie ma metadanych tych partnerów • default <Default. Relying. Party> – Id. P ma metadane partnera, ale nie posiada dedykowanej dla niego konfiguracji • specified <Relying. Party> – Id. P ma metadane tego partnera i ma specyficzną dla niego konfigurację

Plik relying-party. xml • Metadane i partnerzy komunikacji relying parties • – podstawowym źródłem informacji o tym, w jaki sposób Id. P ma komunikować się z SP lub innym partnerem są metadane • zawierają klucze używane do szyfrowania, podpisywania • określają dozwolone protokoły, czy ma być stosowane szyfrowanie, podpisywanie przekazywanych danych – identyfikacja partnera (relying party) następuje poprzez element <Entity. Descriptor> i jego atrybut entity. ID zwany identyfikatorem encji (SP, Id. P) W pliku relying-party. xml umieszczone są podczas instalacji definicje partnerów komunikacji, nie jest potrzebna zmiana tych bloków: <rp: Anonymous. Relying. Party…/> <rp: Default. Relying. Party …> … </rp: Default. Relying. Party>

Plik relying-party. xml • Konfiguracja profili – W ramach definicji Default. Relying. Party / Relying. Party są wskazywane profile konfiguracji – element <rp: Profile. Configuration>, np. <rp: Profile. Configuration xsi: type="saml: Shibboleth. SSOProfile" include. Attribute. Statement="false" assertion. Lifetime="PT 5 M" sign. Responses="conditional" sign. Assertions="never" include. Conditions. Not. Before="true"/> <rp: Profile. Configuration xsi: type="saml: SAML 2 SSOProfile" include. Attribute. Statement="true" assertion. Lifetime="PT 5 M" assertion. Proxy. Count="0" sign. Responses="never" sign. Assertions="always" encrypt. Assertions="never" encrypt. Name. Ids="never" include. Conditions. Not. Before="true"/>

Plik relying-party. xml - metadane • Bloki o postaci <metadata: Metadata. Provider …. /> wskazują metadane zawierające informacje dotyczące potencjalnych partnerów Id. P • Wskazywanie metadanych: – poprzez umieszczenie metadanych w pliku na dysku <metadata: Metadata. Provider id="MD 1" xsi: type="metadata: Filesystem. Metadata. Provider" metadata. File="/opt/shibboleth-idp/metadata/md 1. xml"/> – poprzez pobranie metadanych ze wskazanego URL-a i zapamiętanie na dysku <metadata: Metadata. Provider id="MD 2" xsi: type="metadata: File. Backed. HTTPMetadata. Provider" metadata. URL="https: //xxx/Metadata" backing. File="/opt/shibboleth-idp/metadata/md 2. xml"/> • Można zadeklarować sprawdzanie czy metadane są ważne (stempel czasowy valid. Until), czy są podpisane właściwym certyfikatem itp.

Atrybuty w Shibboleth Id. P • Plik attribute-resolver. xml – deklaracja źródeł danych w blokach <Data. Connector> • atrybut id – nazwa źródła • atrybut xsi: type – typ źródła np. dc: LDAPDirectory, dc: Relational. Database • definicja parametrów połączeń itp. zależy od typu źródła – szczegółowe informacje o ustawieniach: https: //wiki. shibboleth. net/confluence/display/SHIB 2/Resolver. LD APData. Connector https: //wiki. shibboleth. net/confluence/display/SHIB 2/Resolver. RD BMSData. Connector

Atrybuty w Shibboleth Id. P • Plik attribute-resolver. xml – wykaz definicji atrybutów w elementach <resolver: Attribute. Definition> • atrybut id – identyfikator docelowy atrybutu • atrybut source. Attribute. ID – identyfikator źródłowy (np. w LDAP) • atrybut xsi: type – typ atrybutu (np. Simple, Scoped, SAML 2 Name. ID) • blok <resolver: Dependency> – wskazanie źródła • blok <resolver: Attribute. Encoder> – sposób kodowania • blok <resolver: Display. Name> – nazwa atrybutu • blok <resolver: Display. Description> – opis atrybutu

Zasady przekazywania atrybutów do SP • Plik attribute-filter. xml określa stosowaną politykę w zakresie udostępniania atrybutów – Id. P udostępnia wszystkim identyfikator persistent. Id <afp: Attribute. Filter. Policy id="release. Persistent. Id. To. Anyone"> <afp: Policy. Requirement. Rule xsi: type="basic: ANY"/> <afp: Attribute. Rule attribute. ID="persistent. Id"> <afp: Permit. Value. Rule xsi: type="basic: ANY" /> </afp: Attribute. Rule> </afp: Attribute. Filter. Policy> – Id. P udostępnia wszystkim eduperson. Targeted. ID <afp: Attribute. Filter. Policy id="release. EPTId. To. Anyone"> <afp: Policy. Requirement. Rule xsi: type="basic: ANY"/> <afp: Attribute. Rule attribute. ID="edu. Person. Targeted. ID"> <afp: Permit. Value. Rule xsi: type="basic: ANY" /> </afp: Attribute. Rule> </afp: Attribute. Filter. Policy>

Zasady przekazywania atrybutów do SP • attribute-filter. xml – przykłady – udostępnianie User. Id aplikacji Microsoft Office 365 <afp: Attribute. Filter. Policy id="Policy. For. Windows. Azure. AD"> <afp: Policy. Requirement. Rule xsi: type="basic: Attribute. Requester. String" value="urn: federation: Microsoft. Online" /> <!-- Release user. Principal. Name as Azure AD User ID --> <afp: Attribute. Rule attribute. ID="User. Id"> <afp: Permit. Value. Rule xsi: type="basic: ANY"/> </afp: Attribute. Rule> </afp: Attribute. Filter. Policy>

Zasady przekazywania atrybutów do SP • attribute-filter. xml – przykłady – udostępnianie atrybutów wszystkim SP, które deklarują akceptację Kodeksu postępowania (Code of Conduct) <afp: Attribute. Filter. Policy id="release. To. C"> <afp: Policy. Requirement. Rule xsi: type="saml: Attribute. Requester. Entity. Attribute. Exact. Match" attribute. Name="http: //macedir. org/entity-category" attribute. Value="http: //www. geant. net/uri/dataprotection-codeof-conduct/v 1"/> <afp: Attribute. Rule attribute. ID="display. Name"> <afp: Permit. Value. Rule xsi: type="basic: ANY"/> </afp: Attribute. Rule> <afp: Attribute. Rule attribute. ID="email"> <afp: Permit. Value. Rule xsi: type="basic: ANY"/> </afp: Attribute. Rule>

Konfiguracja uwierzytelniania – plik handler. xml • W pliku handler. xml umieszcza się definicje sposobu realizacji logowania – <Login. Handler xsi: type="ph: Username. Password"> oznacza logowanie przez parę danych (nazwa użytkownika, hasło), atrybut jaas. Configuration. Location wskazuje plik konfiguracyjny JASS, np. login. config – <ph: Login. Handler xsi: type="ph: Remote. User"> logowanie oparte na przekazaniu wartości REMOTE_USER

Konfiguracja uwierzytelniania - plik login. config • Plik login. config określa zasady uwierzytelniania, zgodnie ze specyfikacją Java Authentication and Authorization Service (JAAS) – Shibboleth wymaga, by w pliku był zdefiniowany blok Shib. User. Pass. Auth: Shib. User. Pass. Auth { edu. vt. middleware. ldap. jaas. Ldap. Login. Module required host="localhost" base. Dn="ou=Users, dc=test-org, dc=pl" bind. Dn="cn=admin, dc=test-org, dc=pl" bind. Credential="1 qaz 2 wsx" tls="false" subtree. Search="true" user. Field="uid"; }

Logowanie w Shibboleth Id. P • Plik konfiguracyjny logging. xml – katalog logowania /opt/shibboleth-idp/logs/ – domyślne logowanie do pliku idp-process. log – aby uzyskać więcej informacji o pracy Id. P można tymczasowo ustawić poziom DEBUG w blokach <logger> – aby śledzić działania związane z logowaniem LDAP, trzeba dodać: <logger name="edu. vt. middleware. ldap" level="DEBUG"/> – jeśli chcemy analizować pakiety zleceń i odpowiedzi, trzeba tymczasowo zmienić w pliku relying-party. xml wartości parametru encrypt. Assertion (never zamiast conditional)

Zgoda użytkownika na korzystanie z usługi i przekazanie atrybutów • Aby Id. P przekazywało do użytkownika usługi pytanie o zgodę na publikację atrybutów, konieczna jest instalacja rozszerzenia – u. Approve – rozszerzenie wykonane przez SWITCH https: //www. switch. ch/aai/support/tools/u. Approve. html – pobranie pakietu: https: //forge. switch. ch/redmine/projects/uapprove/files – instalacja: https: //www. switch. ch/aai/downloads/u. Approve-manual/ • Funkcja u. Approve: – po zalogowaniu są prezentowane zasady korzystania z usług (Terms of Use), a po ich akceptacji – użytkownik otrzymuje stronę pokazującą, jakie atrybuty zostaną przekazane do usługi i aby kontynuować prace musi zgodzić się na przekazanie atrybutów

u. Approve – instalacja • Po rozpakowaniu pakietu do katalogu $UAPPROVE_INSTALL (np. /opt/u. Approve-2. 5. 0) – kopiujemy pliki JAR z katalogów $UAPPROVE_INSTALL/lib/ i $UAPPROVE_INSTALL/lib/jdbc/ do katalogu /opt/shibbolethidp/lib ($IDP_HOME) – kopiujemy pliki konfiguracyjne u. Approve. properties i u. Approve. xml ($UAPPROVE_INSTALL/manual/configuration) do katalogu $IDP_HOME/conf i dostosowujemy ustawienia – tworzymy katalog $IDP_HOME/src/main/webapp/u. Approve i kopiujemy do niego pliki aplikacji webowej u. Approve cp $UAPPROVE_INSTALL/webapp/* $IDP_HOME/ src/main/webapp/u. Approve

Baza danych dla u. Approve • Tworzymy bazę danych o nazwie u. Approve • Nadajemy uprawnienia INSERT, SELECT, UPDATE, DELETE użytkownikowi u. Approve/secret • Tworzymy tablice wg schematu $UAPPROVE_INSTALL/manual/storage/tems-of-use-schema. sql $UAPPROVE_INSTALL/manual/storage/attribute-release-schema. sql • Zgodnie ze wskazówkami w dokumentacji u. Approve https: //www. switch. ch/aai/downloads/u. Approve-manual/ modyfikujemy: – plik $IDP_HOME/src/ main/webapp/WEB-INF/web. xml zgodnie ze wskazówkami w p. 2. 1 – plik zawierający warunki użytkowania (terms-of-use. html) • Reinstalujemy Shibboleth Id. P

Testowanie Id. P • Metadane Id. P dostępne pod adresem https: //logon. example. pl/idp/shibboleth – metadane Id. P należy udostępnić dostawcy usługi, SP – SP, na którym testujemy musi dołączyć do swojej konfiguracji metadane Id. P • Testowe SP przekazuje swoje metadane Id. P – Id. P umieszcza w swojej konfiguracji metadane SP