Temat zadania:

Data opracowania: 30.09.2003

Spis treści

1. Wstęp
2. Czym jest Shibboleth
3. Miejsce LDAP-a w Shibboleth i jego rola
   Polecane linki

W niniejszym dokumencie omówiona zostanie rola i miejsce LDAP-a w projekcie Shibboleth grupy Internet2. Rozpatrywano oprogramowanie w wersji 1.1.

2. Czym jest Shibboleth

Najogólniej, Shibboleth jest systemem autentykacji i autoryzacji użytkownika, który używając przeglądarki internetowej łączy się z zasobami różnych instytucji (zrzeszonych, bądź nie, w tzw. federacje) w celu przeglądania podzbioru tych zasobów, do którego jest on uprawniony.

W skrócie, działanie systemu jest następujące: Użytkownik próbujący obejrzeć strzeżone omawianym systemem dane jest odsyłany do rodzimej domeny (serwera autentykacji instytucji, z której pochodzi lub w której chce on dokonac autentykacji), gdzie następuje jego autentykacja przy użyciu bezpiecznego połączenia. Następnie, lokalny serwer, tzw. origin site (oprogramowanie Shibboleth) generuje tymczasowy uchwyt dla tego użytkownika i wysyła go do zdalnego serwera instytucji, do danych której użytkownik chce uzyskać dostęp. W dalszym ciągu, instytucja ta (zdalna instalacja Shibboleth) kontaktuje się z lokalną instytucją użytkownika, w której dokonał on autentykacji, i przy użyciu otrzymanego wcześniej uchwytu, znów na drodze bezpiecznego połączenia, uzyskuje dane o użytkowniku - jego atrybuty. Na ich postawie zdalna instytucja decyduje czy zezwolić użytkownikowi na dostęp do żądanych zasobów.

Wymagania systemu z punktu widzenia użytkownika to tylko dostęp do przeglądarki internetowej z obsługą cookies, przekierowań, SSL i opcjonalnie JavaScript.

3. Miejsce LDAP-a w Shibboleth i jego rola

Przybliżmy wymagane komponenty wchodzące w skład origin site. Są to oprócz lokalnego systemu jednokrotnego logowania (SSO): Attribute Authority (AA) - moduł odpowiedzialny za obsługę/udostępnianie atrybutów użytkowników , Handle Service (HS) - moduł realizujący obsługę uchwytów użytkowników oraz usługa katalogowa. Z powyższych komponentów Shibboleth dostarcza własne (oparte całkowicie na języku Java) oprogramowanie dla AA i HS. Jako SSO można zastosowac np. rozwiązanie Pubcookie , a jako usługę katalogową, Shibboleth wykorzystuje serwer LDAP, którego obsługę ma wbudowaną. Wykorzystywanym schematem jest eduPerson.

Własnie na serwerze LDAP znajdować powinny się dane (atrybuty) wszystkich członków danej rodzimej, instytucji użytkownika. Ważną właściwością systemu jest możliwość wyspecyfikowania przez każdego użytkownika własnej polityki udostępniania swoich atrybutów (Attribute Release Policies (ARP's)) uzależnionej od instytucji, która odpytuje AA origin site'u użytkownika (de facto instytucja, do której użytkownik zgłosił sie po zasób) lub tez od samego zasobu, do którego użytkownik zgłasza chęć dostępu. Dodatkowo AA posiada Java API pozwalające na wyspecyfikowanie innej niż LDAP usługi kataogowej.

Używając wprowadzonych pojęć pracę origin site można przedstawić teraz następująco: Oprogramowanie w tym miejscu zaczyna pracę, gdy zgłosi się do jego HS przekierowany ze strony zdalnej instytucji (target site) użytkownik. Następuje odwołanie do usługi SSO w celu sprawdzenia, czy użytkownik dokonał autentykacji. Jeśli nie było autentykacji - będzie ona miała tutaj miejsce. Później, użytkownik wraz z wygenerowanym uchwytem zostaje odesłany do target site , którego komponent (SHAR - Shibboleth Attribute Requester) zgłasza się z tym uchwytem do AA origin site'a w celu uzyskania danych o użytkowniku (jego atrybutów). W tym miejscu AA konsultuje z ARP atrybuty użytkownika skojarzonego z uchwytem, wydobywa z LDAP-a jego atrybuty i podaje do SHAR te atrybuty, które są w zgodzie z polityką udostępniania atrybutów użytkownika dla tego SHAR.

Konfiguracja systemu dotycząca LDAP dotyczy głównie pliku resolver.xml, którego wzorzec można znaleźć pod nazwą resolver.ldap.xml w głównym katalogu konfiguracyjnym systemu, a więc /webapps/shibboleth/WEB-INF/classes/conf. W pliku tym oprócz definicji atrybutów znajdziemy najważniejsze opcje konfiguracyjne takie jak:

• java.naming.provider.url, której wartość specyfikuje URL serwera LDAP przechowującego atrybuty użytkowników, np. ldap://shib.uci.uni.torun.pl/dc=uni,dc=torun,dc=pl.
• java.naming.security.principal, która określa binddn, np. cn=Manager,dc=uni,dc=torun,dc=pl
• java.naming.security.credentials, która określa hasło dla powyższego binddn.

Ściśle związana z powyższym jest konfiguracja ARP przechowywanych na serwerze LDAP atrybutów użytkownika. Niestety nie ma obecnie dla użytkowników innej niż bezpośrednia edycja plików xml, drogi konfiguracji ich polityki udostępniania atrybutów. Autorzy systemu zapowiadają w przyszłości stworzenie odpowiedniego do tego celu GUI. Na razie pliki te znajdują się w katalogu wskazanym przez zmienną edu.internet2.middleware.shibboleth.aa.arp.provider.FileSystemArpRepository.Path w globalnym pliku konfiguracyjnym origin site'a /webapps/shibboleth/WEB-INF/classes/conf/origin.properties. Domyślnie skonfigurowane jest udostępnianie każdej instytucji atrybutu eduPersonScopedAffiliation.

Polecane linki

http://shibboleth.internet2.edu/ - strona projektu.
http://www.educause.edu/netatedu/groups/pki/eduperson/internet2-mace-dir-eduPerson-200210.htm - schemat eduPerson-200210.