Dies ist eine alte Version des Dokuments!
Secret Key Management
Was tun im Fall eines Incidents?
Wenn Sie Sessions und User Consent in einer IdP-seitigen Datenbank ablegen, können Sie diesen Schritt überspringen.In der Standardeinstellung speichert der Shibboleth IdP Informationen zu Sitzungen und User Consent client-seitig im Browser, in Cookies und ggf. HTML Local Storage (siehe Shibboleth Wiki). Diese Daten werden durch Verschlüsselung geschützt. Die Keys, die dabei zum Einsatz kommen, sollten regelmäßig getauscht werden, wenn Sie die oben genannten Informationen nicht serverseitig speichern.
Laden Sie das Beispiel-Script herunter und legen es nach
/opt/shibboleth-idp/bin/update-sealer.sh
Vergessen Sie nicht das Script ausführbar zu machen:
root@idp:~# chmod 755 /opt/shibboleth-idp/bin/update-sealer.sh
Dieses Script liest die Sealer-relevanten Einstellungen aus ./conf/idp-properties und erzeugt damit neue Schlüsselwerte. Dazu legen Sie am besten einen täglichen Cron-Job an:
- /etc/cron.d/shibboleth-idp
01 01 * * * root /opt/shibboleth-idp/bin/update-sealer.sh >/dev/null
Hinweis: falls Sie bei der IdP-Installation am Anfang ein zu einfaches Sealer-Passwort vergeben haben können Sie dieses problemlos ändern indem Sie die Dateien ./credentials/sealer.* löschen und in ./conf/idp.properties neue Passwörter (idp.sealer.storePassword und idp.sealer.keyPassword) vergeben. Danach rufen Sie einfach obigen Cron-Job manuell auf, das Script erstellt die fehlenden Dateien unter Verwendung der neuen Passwörter wieder neu. Achten Sie nur darauf dass Sie beim Passwort keine Sonderzeichen verwenden da diese erfahrungsgemäß in Java-properties-Dateien Probleme machen können.
Referenz zum Shib-Wiki: https://wiki.shibboleth.net/confluence/display/IDP30/SecretKeyManagement
Aufnahme in DFN-AAI-Produktivumgebung
Die Basis-Konfiguration des IdPs ist damit abgeschlossen. Für die Inbetriebnahme des IdP beachten Sie bitte die Hinweise und Empfehlungen unter Produktivbetrieb.
Weiter geht es mit den Attribut-Konfigurationen in der DFN-AAI