Federacja:ShibbolethIdP5-docker: Różnice pomiędzy wersjami
Nie podano opisu zmian |
Nie podano opisu zmian |
||
Linia 48: | Linia 48: | ||
: Podajemy pełną nazwę hosta, np. idp.uczelnia.pl | : Podajemy pełną nazwę hosta, np. idp.uczelnia.pl | ||
;SAML EntityID: [ https://idp.uczelnia.pl/idp/shibboleth ] | ;SAML EntityID: [ https://idp.uczelnia.pl/idp/shibboleth ] ? | ||
: ''Enter'' | : ''Enter'' | ||
Linia 56: | Linia 56: | ||
Następuje instalacja pluginów, na którą należy wyrazić zgodę odpowiadając dwukrotnie ''Y'' | Następuje instalacja pluginów, na którą należy wyrazić zgodę odpowiadając dwukrotnie ''Y'' | ||
Po zakończeniu instalacji w katalogu '''/opt/shibboleth-idp-pionier''' znajduje się instalacja i wstępna konfiguracja Shibboleth IdP. | |||
Proces dockera związany z inicjalizacją Shibboleth IdP zostaje zakończony, ale zaleca się wykonanie polecenia: | |||
docker compose -f ./docker-compose-init.yaml down --remove-orphans | |||
====Uruchomienie Shibboleth IdP==== | |||
Aby uruchomić usługę serwera IdP należy wykonać polecenie: | |||
docker compose up -d | |||
Przy pierwszym uruchomieniu zostanie pobrany obraz mariadb oraz openldap, zostaną utworzone wolumeny wspólne i następnie jest uruchamiany obraz pionierid-id, czyli startowany jest serwer webowy jetty i w ramach tego serwera jest udostępniana aplikacja Shibboleth IdP. | |||
W pliku docker-compose.yaml odpowiedzialnym za przebieg uruchamiania usługi jest umieszczony wpis: | |||
restart: always | |||
co oznacza, że system dockerowy będzie samodzielnie startował usługę - nie są potrzebne żadne dodatkowe działania, by zapewnić startowanie po reboocie maszyny podstawowej. |
Wersja z 17:29, 31 mar 2025
Opis
W tym podejściu przygotowywane są trzy środowiska dockerowe:
- baza mysql - zawiera bazę i tablice używane przez Shibboleth v. 5
- baza LDAP - zawiera prostą bazę danych użytkowników w celu zobrazowania procesu uwierzytelniania i dostarczania atrybutów w Shibboleth IdP; docelowo instalacja IdP może korzystać z dowolnej bazy danych użytkowników
- środowisko działania Shibboleth IdP: jetty jako serwer WWW i aplikacja Shibboleth IdP
Wymagania systemowe
- zainstalowany silnik dockerowy https://docs.docker.com/engine/install/
- zainstalowany docker compose https://docs.docker.com/compose/install/
Paczka instalacyjna i uruchomieniowa serwera IdP
Pobranie aktualnej paczki pionier-id-idp.tar.gz
Rozpakowanie paczki
np. w katalogu /opt
cd /opt tar xfv pionier-id-idp.tar.gz cd /opt/PIONIER.Id-IdP
Opis zawartości paczki
- w pliku default/jetty należy dostosować ustawienia dotyczące usługi serwera jetty, niezbędne jest podanie w JETTY_HOST adresu IP serwera; domyślnie serwer będzie korzystał z portów http 8081 oraz https 9444, jeśli port 8081 nie może być używany, proszę dostosować JETTY_PORT
- w podkatalogu pionier-jetty-credentials jest umieszczony plik jetty.p12 zawierający testowy certyfikat serwera, wystawiony na nazwę aai.example.pl przez niezaufane CA; w tym katalogu należy umieścić plik jetty.p12 zawierający certyfikat przeznaczony dla instalowanego serwera (wskazówki umieszczono poniżej)
- w pliku Dockerfile
- - w wierszu ARG jetty_pass=... podane jest jest hasło do certyfikatu jetty.p12 - plik z jetty.p12 w paczce instalacyjnej wymaga umieszczonego tam hasła, jeśli został wgrany nowy plik jetty.p12 należy dostosować wartość jetty_pass
- - w wierszach RUN echo... zawierających ustawienia portów jetty.http.port i jetty.ssl.port należy dostosować numery portów, jeśli 8081 i 9444 nie mogą być używane
- trzy pliki docker-compose-init.yaml, docker-compose-upgrade.yaml, docker-compose.yaml służą uruchamianiu środowiska w trybie inicjalizacji (docker-compose-init.yaml), upgrate'u (docker-compose-upgrade.yaml) oraz gotowej usługi (docker-compose.yaml)
- w pliku docker-compose.yaml jest zdefiniowany start poszczególnych usług oraz definicja współdzielonych wolumnenów:
- mariadb - start serwera mysql, tworzona jest baza shibboleth_pionier i potrzebne tablice
- openldap - start serwera openLDAP - serwer dostępny jest na portach 1389 i 1636, korzysta ze schematów znajdujących się w podkatalogu ldap-schemas, inicjowana jest zawartość bazy zgodnie z plikiem w podkatalogu ldifs
- idp - stat serwera jetty
- wspólne wolumeny są zdefiniowane dla usług mariadb oraz openldap i gwarantują trwałość baz danych
Przygotowanie obrazów
Po dostosowaniu zawartości plików wykonujemy tworzymy obraz Shibboleth IdP:
cd /opt/PIONIER.Id-IdP docker compose build
Po poprawnym zakończeniu sprawdzamy za pomocą polecenia:
docker images
że istnieje obraz pionier-idp-5
Zainicjowanie instalacji Shibboleth IdP
Przeprowadzamy instalację inicjującą. Na głównej maszynie zostanie utworzony katalog /opt/shibboleth-idp-pionier, w którym będzie umieszczona instalowana wersja Shibboleth IdP (plik uruchomieniowy oraz cała konfiguracja). Instalacja odbywa się w trybie interakcyjnym, należy odowiedzieć na zadane pytania lub potwierdzić wybór przez Enter. Uruchamiamy:
docker compose -f ./docker-compose-init.yaml run idp-init
Interakcja wygląda następująco:
- Installation Directory
- [/opt/shibboleth-idp] ?
- Enter
- Host Name
- [973fd3996aaa] ?
- Podajemy pełną nazwę hosta, np. idp.uczelnia.pl
- SAML EntityID
- [ https://idp.uczelnia.pl/idp/shibboleth ] ?
- Enter
Attribute Scope: [uczelnia.pl] ?
- Enter
Następuje instalacja pluginów, na którą należy wyrazić zgodę odpowiadając dwukrotnie Y
Po zakończeniu instalacji w katalogu /opt/shibboleth-idp-pionier znajduje się instalacja i wstępna konfiguracja Shibboleth IdP. Proces dockera związany z inicjalizacją Shibboleth IdP zostaje zakończony, ale zaleca się wykonanie polecenia:
docker compose -f ./docker-compose-init.yaml down --remove-orphans
Uruchomienie Shibboleth IdP
Aby uruchomić usługę serwera IdP należy wykonać polecenie:
docker compose up -d
Przy pierwszym uruchomieniu zostanie pobrany obraz mariadb oraz openldap, zostaną utworzone wolumeny wspólne i następnie jest uruchamiany obraz pionierid-id, czyli startowany jest serwer webowy jetty i w ramach tego serwera jest udostępniana aplikacja Shibboleth IdP.
W pliku docker-compose.yaml odpowiedzialnym za przebieg uruchamiania usługi jest umieszczony wpis:
restart: always
co oznacza, że system dockerowy będzie samodzielnie startował usługę - nie są potrzebne żadne dodatkowe działania, by zapewnić startowanie po reboocie maszyny podstawowej.