Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:shibidp:config-storage [2020/04/09 16:27] – Silke Meyer | de:shibidp:config-storage [2024/06/17 08:21] – [Datenbank-Credentials hinterlegen] Doreen Liebenau | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | <- de: | ||
~~NOTOC~~ | ~~NOTOC~~ | ||
- | ====== Server-Side Storage ====== | + | ====== Server-Side Storage |
{{INLINETOC 2}} | {{INLINETOC 2}} | ||
Standardmäßig werden Informationen zu Sessions, User Consent (bzgl. Attributfreigabe) und Persistent IDs clientseitig in Cookies abgelegt. Wir betrachten die clientseitige Speicherung nur als initiale " | Standardmäßig werden Informationen zu Sessions, User Consent (bzgl. Attributfreigabe) und Persistent IDs clientseitig in Cookies abgelegt. Wir betrachten die clientseitige Speicherung nur als initiale " | ||
- | < | + | < |
PersistentIds werden vom IdP pro Useraccount und pro Service Provider automatisch generiert. Sie sind pseudonym und können am SP zur Wiedererkennung und Personalisierung verwendet werden. Nur am IdP ist ist ersichtlich, | PersistentIds werden vom IdP pro Useraccount und pro Service Provider automatisch generiert. Sie sind pseudonym und können am SP zur Wiedererkennung und Personalisierung verwendet werden. Nur am IdP ist ist ersichtlich, | ||
</ | </ | ||
- | < | + | < |
Bei einer Attribute Query fragt ein Service Provider direkt beim IdP Nutzerdaten ab, also ohne, dass Nutzer*innen einen Loginvorgang angestoßen haben. Dies tun manche SPs, um Informationen darüber zu bekommen, ob Useraccounts am IdP noch aktiv sind. Für Attribute Queries wird gerne die persistentId verwendet. | Bei einer Attribute Query fragt ein Service Provider direkt beim IdP Nutzerdaten ab, also ohne, dass Nutzer*innen einen Loginvorgang angestoßen haben. Dies tun manche SPs, um Informationen darüber zu bekommen, ob Useraccounts am IdP noch aktiv sind. Für Attribute Queries wird gerne die persistentId verwendet. | ||
</ | </ | ||
Zeile 17: | Zeile 18: | ||
==== Installation ==== | ==== Installation ==== | ||
+ | 1. Im einfachsten Fall installieren Sie auf dem IdP einen lokalen Datenbank-Server. Sie können natürlich auch entfernte Datenbanken über das Netzwerk einbinden. | ||
+ | |||
<code bash> | <code bash> | ||
root@idp:~# apt install mariadb-server mariadb-client libmariadb-java | root@idp:~# apt install mariadb-server mariadb-client libmariadb-java | ||
Zeile 23: | Zeile 25: | ||
<code bash> | <code bash> | ||
- | root@idp:~# ln -s / | + | root@idp:~# ln -s / |
</ | </ | ||
- | Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren: | + | 2. Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren: |
<code bash> | <code bash> | ||
- | root@idp:~# systemctl restart | + | root@idp:~# systemctl restart |
</ | </ | ||
+ | |||
+ | 3. Installieren Sie schließlich im IdP das JDBC-Plugin:< | ||
==== Datenbank und Tabellen anlegen ==== | ==== Datenbank und Tabellen anlegen ==== | ||
Die Datenbank und der Datenbank-Benutzeraccount müssen manuell erstellt werden. Dann werden noch zwei Tabellen angelegt: | Die Datenbank und der Datenbank-Benutzeraccount müssen manuell erstellt werden. Dann werden noch zwei Tabellen angelegt: | ||
- | * '' | + | * '' |
* '' | * '' | ||
Zeile 52: | Zeile 56: | ||
version bigint(20) NOT NULL, | version bigint(20) NOT NULL, | ||
PRIMARY KEY (context, id) | PRIMARY KEY (context, id) | ||
- | ); | + | ) COLLATE utf8_bin; |
mysql> CREATE TABLE IF NOT EXISTS shibpid ( | mysql> CREATE TABLE IF NOT EXISTS shibpid ( | ||
Zeile 73: | Zeile 77: | ||
</ | </ | ||
- | ==== JPAStorageService | + | ==== JDBCStorageService |
- | Der DB-Zugriff wird über den [[https://wiki.shibboleth.net/ | + | Der DB-Zugriff wird über den [[https:// |
<file xml ./ | <file xml ./ | ||
Zeile 113: | Zeile 117: | ||
p: | p: | ||
- | <bean id="shibboleth.JPAStorageService" | + | <bean id="JDBCStorageService" |
- | | + | |
p: | p: | ||
- | | + | |
- | + | ||
- | <bean id=" | + | |
- | class=" | + | |
- | < | + | |
- | < | + | |
- | < | + | |
- | < | + | |
- | <bean class=" | + | |
- | </ | + | |
- | </ | + | |
- | + | ||
- | <bean id=" | + | |
- | class=" | + | |
- | p: | + | |
- | p: | + | |
- | p: | + | |
</ | </ | ||
</ | </ | ||
Zeile 139: | Zeile 126: | ||
==== Datenbank-Credentials hinterlegen ==== | ==== Datenbank-Credentials hinterlegen ==== | ||
- | Die Properties für den Datenbank-Zugriff werden jetzt noch in '' | + | 1. Die Properties für den Datenbank-Zugriff werden jetzt noch in '' |
<file java / | <file java / | ||
Zeile 149: | Zeile 136: | ||
</ | </ | ||
- | Das Passwort gehört wieder in die Datei '' | + | 2. Das Passwort gehört wieder in die Datei '' |
<file / | <file / | ||
mysql.password = GeHEIM007 | mysql.password = GeHEIM007 | ||
</ | </ | ||
- | Starten Sie Tomcat neu, um sicherzustellen, | + | 3. Starten Sie Tomcat neu, um sicherzustellen, |
<code bash> | <code bash> | ||
- | root@idp:~# systemctl restart | + | root@idp:~# systemctl restart |
</ | </ | ||
Zeile 168: | Zeile 155: | ||
Wählen Sie ein Quellattribut aus Ihrem IdM, das **über die Zeit eindeutig** bleibt! Bei OpenLDAP ist das oft die '' | Wählen Sie ein Quellattribut aus Ihrem IdM, das **über die Zeit eindeutig** bleibt! Bei OpenLDAP ist das oft die '' | ||
- | Ein möglicher Workaround: Sie können sich in der '' | + | Ein möglicher Workaround: Sie können sich in der '' |
==== Generierung und Speicherung ==== | ==== Generierung und Speicherung ==== | ||
- | Das gewählte Quellattribut legen Sie in '' | + | |
+ | Das gewählte Quellattribut legen Sie in '' | ||
<file properties / | <file properties / | ||
idp.persistentId.sourceAttribute = uid | idp.persistentId.sourceAttribute = uid | ||
- | # idp.persistentId.useUnfilteredAttributes = true | + | # BASE64 will match V2 values, we recommend BASE32 encoding for new installs. |
- | # Do *NOT* share the salt with other people, it's like divulging your private key. | + | idp.persistentId.encoding |
- | # idp.persistentId.algorithm = SHA | + | |
- | idp.persistentId.salt = MöglichstBeliebigUndGeHeim-mindestens-16bytes | + | |
# To use a database, use shibboleth.StoredPersistentIdGenerator | # To use a database, use shibboleth.StoredPersistentIdGenerator | ||
Zeile 184: | Zeile 170: | ||
# For basic use, set this to a JDBC DataSource bean name: | # For basic use, set this to a JDBC DataSource bean name: | ||
idp.persistentId.dataSource = shibboleth.MySQLDataSource | idp.persistentId.dataSource = shibboleth.MySQLDataSource | ||
+ | |||
</ | </ | ||
+ | |||
+ | Der Salt-Hash, mit dem die persistentIds generiert werden, wird aus Sicherheitsgründen in der zugriffsbeschränkten Passwortdatei '' | ||
+ | |||
+ | <file properties / | ||
+ | # Bitte durch einen zufällig generierten Salt ersetzen! | ||
+ | idp.persistentId.salt = my-very-very-long-hash | ||
+ | |||
+ | </ | ||
+ | |||
==== Generator anschalten ==== | ==== Generator anschalten ==== | ||
- | Die Generierung der persistentIds muss separat angeschaltet werden. Entfernen Sie dazu den Kommentar bei shibboleth.SAML2PersistentGenerator in '' | + | Die Generierung der persistentIds muss separat angeschaltet werden. Entfernen Sie dazu den Kommentar bei '' |
<file xml / | <file xml / | ||
Zeile 224: | Zeile 220: | ||
</ | </ | ||
- | Viertens: meist sind Usernamen im IdM-System unabhängig von Gross- und Kleinschreibung. D.h. die User können Ihren Loginnamen sowohl in Gross- als auch Kleinschreibung angeben und damit einen erfolgreichen Login durchführen. Allerdings führt dieses später zu Problemen beim Verwalten der Usernamen in der lokalen IdP-Datenbank da diese Gross- und Kleinschreibung unterscheidet. Wir empfehlen daher den Usernamen | + | ==== Lowercase-Usernamen |
+ | Meist sind Usernamen in IdM-Systemen unabhängig von Groß- und Kleinschreibung: | ||
+ | |||
+ | === bis IdP 4.0.1 === | ||
<file xml ./ | <file xml ./ | ||
... | ... | ||
Zeile 232: | Zeile 231: | ||
</ | </ | ||
- | Damit werden die Usernamen vom IdP nur noch in Kleinbuchstabenform verarbeitet und in die Datenbank geschrieben. | + | === ab IdP 4.1.0 === |
+ | <file properties ./ | ||
+ | idp.c14n.simple.lowercase = true | ||
+ | </ | ||
+ | |||
+ | ===== Data Connector ===== | ||
+ | Stellen Sie sicher, dass Ihre '' | ||
+ | |||
+ | <file xml ./ | ||
+ | < | ||
+ | xsi: | ||
+ | generatedAttributeID=" | ||
+ | salt=" | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
===== Session-Informationen und User Consent ===== | ===== Session-Informationen und User Consent ===== | ||
- | Nachdem Datenbankverbindung und persistentId aktiviert sind, können diese nun für die Speicherung von Session- und User Consent-Informationen genutzt werden. Dadurch wird als netter Nebeneffekt auch [[:de:shibidp3slo|SingleLogout-Unterstützung]] im IdP ermöglicht. | + | Nachdem Datenbankverbindung und persistentId aktiviert sind, können diese nun für die Speicherung von Session- und User Consent-Informationen genutzt werden. Dadurch wird als netter Nebeneffekt auch [[de:shibidp: |
<file properties / | <file properties / | ||
... | ... | ||
# Set to " | # Set to " | ||
- | idp.session.StorageService = shibboleth.JPAStorageService | + | idp.session.StorageService = JDBCStorageService |
# Set to " | # Set to " | ||
- | idp.consent.StorageService = shibboleth.JPAStorageService | + | idp.consent.StorageService = JDBCStorageService |
# Set to " | # Set to " | ||
Zeile 268: | Zeile 283: | ||
===== User Consent zu Attributfreigabe bei Attribute Queries berücksichtigen ===== | ===== User Consent zu Attributfreigabe bei Attribute Queries berücksichtigen ===== | ||
- | Damit bei Attribute Queries Nutzer-Entscheidungen zur Attributfreigabe berücksichtigt werden, muss in ./ | + | Damit bei Attribute Queries Nutzer-Entscheidungen zur Attributfreigabe berücksichtigt werden, muss in '' |
+ | |||
+ | Dann modifizieren Sie die Datei wie folgt: | ||
<file xml ./ | <file xml ./ | ||
Zeile 308: | Zeile 325: | ||
<code bash> | <code bash> | ||
- | root@idp:/ | + | root@idp:/ |
</ | </ | ||
Zeile 315: | Zeile 332: | ||
HINWEIS: Da die persistendId kein SAML-Attribut ist, wird Ihnen diese nach dem Login am IdP nicht in der Liste der zu übertragenden Attribute angezeigt. Erst wenn Sie wieder am Test-SP sind wird Ihnen dort die persistentId, | HINWEIS: Da die persistendId kein SAML-Attribut ist, wird Ihnen diese nach dem Login am IdP nicht in der Liste der zu übertragenden Attribute angezeigt. Erst wenn Sie wieder am Test-SP sind wird Ihnen dort die persistentId, | ||
- | Falls die persistentId nur an ausgewählte SPs übertragen werden soll, so finden sich [[:de:shibidp3pidspecials|hier einige Beispiele]]. | + | Falls die persistentId nur an ausgewählte SPs übertragen werden soll, so finden sich [[de:shibidp: |
- | **Weiter geht es mit [[:de:shibidp3slo|Single Logout]]. ** | + | ===== Umstellung auf SAML pairwise-id ===== |
+ | Die persistentID und das funktionsanaloge, | ||
+ | | ||
+ | | ||
+ | Für die Umstellung der persistentID auf die pairwise-id gibt es keinen perfekten Weg. Wir empfehlen folgendes Vorgehen, mit dem Sie vermeiden, alle Service Provider die persistentIDs bestehender Accounts umschreiben zu lassen: | ||
+ | * Ändern Sie im IdP das Encoding der persistentIDs auf BASE32. Damit erreichen Sie, dass **//neu generierte// | ||
+ | # BASE64 will match V2 values, we recommend BASE32 encoding for new installs. | ||
+ | idp.persistentId.encoding = BASE32</ | ||
+ | * Setzen Sie auch beim entsprechenden Data Connector in '' | ||
+ | < | ||
+ | xsi: | ||
+ | generatedAttributeID=" | ||
+ | salt=" | ||
+ | encoding=" | ||
+ | queryTimeout=" | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | * Bereits **bestehende persistentIDs** lassen Sie in der Datenbank bestehen, wie sie sind. Aus diesen persistentIDs werden dann zwar nicht standardkonforme SAML pairwise-ids gebildet. Wir gehen allerdings nicht davon aus, dass Service Provider, die die pairwise-id entgegennehmen, | ||
+ | * Übermitteln Sie für die pairwise-id den Wert, der persistentID **mit Scope**. | ||
+ | {{tag> |