Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp:config-storage [2021/05/05 15:02] – Silke Meyer
+++ de:shibidp:config-storage [2021/10/20 09:41] – Ergänzung: Umstellung von persistentID auf pairwise-id Silke Meyer
@@ Zeile 1: / Zeile 1: @@
 <-  de:shibidp:config-tou|Nutzungsbedingungen ^ de:shibidp:uebersicht|Überblick: Tutorial zur IdP-Inbetriebnahme ^ de:shibidp:config-slo|Single Logout ->
 ~~NOTOC~~
-====== Server-Side Storage und persistentId ======
+====== Server-Side Storage und persistent Id ======
 {{INLINETOC 2}}
@@ Zeile 177: / Zeile 177: @@
 <file properties /opt/shibboleth-idp/conf/saml-nameid.properties>
 idp.persistentId.sourceAttribute = uid
-# idp.persistentId.useUnfilteredAttributes = true
+# BASE64 will match V2 values, we recommend BASE32 encoding for new installs.
+idp.persistentId.encoding = BASE32
 # To use a database, use shibboleth.StoredPersistentIdGenerator
@@ Zeile 295: / Zeile 296: @@
 ===== User Consent zu Attributfreigabe bei Attribute Queries berücksichtigen =====
-Damit bei Attribute Queries Nutzer-Entscheidungen zur Attributfreigabe berücksichtigt werden, muss in ./conf/intercept/consent-intercept-config.xml die entsprechende Condition gesetzt werden:
+Damit bei Attribute Queries Nutzer-Entscheidungen zur Attributfreigabe berücksichtigt werden, muss in ''./conf/intercept/consent-intercept-config.xml'' die entsprechende Condition gesetzt werden. Ab dem IdP 4.1.0 müssen Sie zunächst das [[https://wiki.shibboleth.net/confluence/display/IDP4/ConsentConfiguration|Intercept Consent-Modul aktivieren]], damit Sie die Datei überhaupt haben:<code bash>bin/module.sh -t idp.intercept.Consent || bin/module.sh -e idp.intercept.Consent</code>
+Dann modifizieren Sie die Datei wie folgt:
 <file xml ./conf/intercept/consent-intercept-config.xml>
@@ Zeile 343: / Zeile 346: @@
 Falls die persistentId nur an ausgewählte SPs übertragen werden soll, so finden sich [[de:shibidp:config-pidspecials|hier einige Beispiele]].
+===== Umstellung auf SAML pairwise-id =====
+Die persistentID und das funktionsanaloge, als deprecated geltende Attribut [[de:common_attributes#a11|eduPersonTargetedID]] sollen in Zukunft von der [[de:common_attributes#a17|SAML pairwise-id]] abgelöst werden. Die erlaubten Werte der pairwise-id unterscheiden sich allerdings von denen der persistentID (siehe die [[https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.html|Spezifikation]]):
+  * Die pairwise-id hat einen Scope.
+  * Die Werte werden mit BASE32 statt mit BASE64 kodiert. Sie dürfen also weniger Zeichen enthalten als alte persistentIDs und sind case-insensitive zu behandeln.
+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// persistentIDs** so kodiert werden, dass sie als Basis für standardkonforme pairwise-ids verwendet werden können.<file properties /opt/shibboleth-idp/conf/saml-nameid.properties>
+# BASE64 will match V2 values, we recommend BASE32 encoding for new installs.
+idp.persistentId.encoding = BASE32</file>
+  * 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, prüfen, ob der Wert vor dem Scope standardkonform ist.
+  * Übermitteln Sie für die pairwise-id den Wert, der persistentID **mit Scope**.
 {{tag>idp4 tutorial persistentid storage datenbank session included-in-ansible}}

idp4 tutorial persistentid storage datenbank session included-in-ansible