Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp:config-pidspecials [2020/10/15 11:49] – Silke Meyer
+++ de:shibidp:config-pidspecials [2021/04/26 15:30] (aktuell) – idp3 tag entfernt Silke Meyer
@@ Zeile 30: / Zeile 30: @@
   * im Default-Block wird nur die TransientId freigegeben
-  * einen Override definieren, in dem für gewisse EntityIds die persistentId freigegeben wird.
+  * einen Override definieren, in dem für gewisse EntityIds die persistentId freigegeben wird
 <file xml relying-party.xml>
@@ Zeile 69: / Zeile 69: @@
-===== Freigabe in Abhängigkeit zu anderen Attributen =====
+===== Freigabe in Abhängigkeit von anderen Attributen =====
-Möchte man die Freigabe der persistentId an einen SP weiter einschränken, ähnlich den Attribut-Filterregeln, ohne dabei den [[https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration#NameIDGenerationConfiguration-V2Compatibility|V2-Legacy-Support]] zu aktivieren so muss man etwas tüfteln.
-Da die persistentId in der aktuellen IdP-Version (3.2.1) standardmäßig nicht mehr als Attribut, sondern als NameIdentifier behandelt wird, so kann man diese zunächst nur global für bestimmte SPs in der /conf/relying-party.xml freischalten.\\
+Möchte man die Freigabe der persistentId analog zu Attribut-Filterregeln weiter einschränken, sind mehrere Schritte nötig.
-Siehe unter **[[de:shibidp3storage#konfiguration_der_persistent-id|Weitere Konfigurationsschritte]]**
-Nun hat man zwar die Möglichkeit mit Hilfe von [[https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions|ActivationConditions]] die NameIDGeneration weiter einzuschränken, jedoch existiert zu diesem Augenblick noch kein AttributContext.\\
+Man kann zwar mit Hilfe von [[https://wiki.shibboleth.net/confluence/display/IDP4/ActivationConditions|ActivationConditions]] die NameIDGeneration einschränken, jedoch existiert zu diesem Zeitpunkt noch kein AttributContext. Man kann deshalb in der ''/conf/relying-party.xml'' keine Abhängigkeit zu anderen Attributen abbilden: Diese werden erst nach dem Login der Nutzer*innen ausgelesen.
-Somit kann man in der /conf/relying-party.xml keine Abhängigkeit zu anderen Attributen abbilden, da diese erst nach dem Login des Nutzers ausgelesen werden.
-Um die persistentId wie gewünscht denoch nur dann an einen SP auszuliefern, wenn der Nutzer z.B. einen bestimmten Wert für das Attribut eduPersonEntitlement aufweist, so muss man dieses Vorhaben nun in zwei Schritte aufteilen.\\
+Um die persistentId dennoch nur dann an einen SP auszuliefern, wenn Nutzer*innen z.B. ein bestimmtes Entitlement haben, muss man wie folgt vorgehen:
-Zunächst geben wir die ID global für den SP frei.
-<file xml /conf/relying-party.xml>
+  - globale Freigabe der persistentID für den SP: <file xml /conf/relying-party.xml>
 <!-- ... -->
@@ Zeile 102: / Zeile 98: @@
 <!-- ... -->
 </file>
+  - Definition einer Condition mit allen [[https://wiki.shibboleth.net/confluence/display/IDP4/ActivationConditions#ActivationConditions-AttributeChecking|Anforderungen an ein Attribut]] und Referenzierung als Abhängigkeit bei der Generierung der persistentID: <file xml /system/conf/saml-nameid-system.xml>
-Anschließend definieren wir eine Condition mit all unseren [[https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions#ActivationConditions-AttributeChecking|Anforderungen an ein Attribut]] und referenzieren diese als Abhängigkeit bei der Generierung der ID.
-<file xml /system/conf/saml-nameid-system.xml>
 <!-- ... -->
@@ Zeile 145: / Zeile 138: @@
 </file>
-Wenn es sich um den oben genannten SP handelt und der Nutzer keinen der oben genannten Attribut-Werte aufweist, dann schlägt die Condition fehl und es wird keine persistentID generiert.\\
+Dadurch ist folgendes Verhalten des IdP konfiguriert: Wenn es sich um den konfigurierten SP handelt und die Nutzer*innen keinen der oben genannten Attribut-Werte aufweisen, dann schlägt die Condition fehl: Es wird keine persistentID generiert. In allen anderen Fällen sollte die Generierung der persistentID problemlos funktionieren.
-In allen anderen Fällen sollte die Generierung der persistentID problemlos funktionieren.
 ===== Beispiel für den Wechsel des IdM-Quellattributs =====
-Das folgende wurde uns netterweise von den Kollegen der Uni Jena zur Verfügung gestellt und soll als Beispiel dienen wie bei Bedarf das IdM-Quellattribut gewechselt werden kann und dabei schon bestehende persistentIds zu erhalten
+Das Beispiel der Uni Jena zeigt, wie bei Bedarf das IdM-Quellattribut gewechselt werden kann, aus dem persistentIDs generiert werden, und wie dabei schon bestehende persistentIds erhalten bleiben.
 ==== Migration der persistentId-DB an der Uni Jena ====
 Ziel der Aktion war das Auswechseln des Quellattributs der persistentId (gespeichert in
-einer PostgreSQL-Datenbank), die doch nicht so unique uid sollte hierbei durch die
+einer PostgreSQL-Datenbank), die doch nicht so unique ''uid'' sollte hierbei durch die
-eduPersonUniqueId ersetzt werden. Die eduPersonUniqueId bilden wir im IDM aus einer UUID
+''eduPersonUniqueId'' ersetzt werden. Die ''eduPersonUniqueId'' bilden wir im IDM aus einer UUID
 ohne Bindestriche mit Scope hinten dran (Beispiel:
-c845b14f1c643ccac9de204632512cd@uni-xy.de) und stellen sie per LDAP-Server zur Verfügung.
+''0c845b14f1c643ccac9de204632512cd@uni-xy.de'') und stellen sie per LDAP-Server zur Verfügung.
-Der Shibboleth IdP ist Version 3.2.1.
+Der Shibboleth IdP war Version 3.2.1.
-.) Den IdP stoppen.
+  - Den IdP stoppen.
+  - In ''/opt/shibboleth-idp/conf/saml-nameid.properties'' wird die Eigenschaft ''idp.persistentId.sourceAttribute = eduPersonUniqueId'' gesetzt.
-.) In /opt/shibboleth-idp/conf/saml-nameid.properties wird die Eigenschaft
+  - Die Werte der Spalte ''localid'' in der Tabelle ''shibpid'' müssen auf die jeweiligen Werte des Attributs ''eduPersonUniqueId'' abgeändert werden. Ich habe mir für die ganze Aktion ein Shellskript geschrieben.
-idp.persistentId.sourceAttribute = eduPersonUniqueId gesetzt.
+    - Man erzeugt sich einen Dump der Tabelle ''shibpid''.
+    - Man arbeitet sich zeilenweise durch diesen Dump. Die Spalte ''principalname'' in der Tabelle ''shibpid'' referenziert den Benutzernamen (''uid''). Über diesen sucht man nun im LDAP-Server nach der jeweiligen  ''eduPersonUniqueId'' und setzt in der Spalte ''localid'' deren Wert anstelle des bisherigen ein. Beispiel: <code># Aus...
-.) Die Werte der Spalte localid in der Tabelle shibpid müssen auf die jeweiligen Werte
-des Attributs eduPersonUniqueId abgeändert werden. Ich habe mir für die ganze Aktion ein
-Shellskript geschrieben.
-.1. - Man erzeugt sich einen Dump der Tabelle shibpid.
-.2. - Man arbeitet sich zeilenweise durch diesen Dump. Die Spalte principalname in der
-Tabelle shibpid referenziert den Benutzernamen (uid). Über diesen sucht man nun im
-LDAP-Server nach der jeweiligen eduPersonUniqueId und setzt in der Spalte localid deren
-Wert anstelle des bisherigen ein.
-Beispiel: Aus...
   "https://idp.uni-xy.de/idp/shibboleth";"https://testsp2.aai.dfn.de/shibboleth";"aaidemo";"aaidemo";"Znc0wfn/YabcZe7neb73Es123456";"";"2014-08-12 14:10:47.29";""
-...wird so...
+# ...wird so...
-  "https://idp.uni-xy.de/idp/shibboleth";"https://testsp2.aai.dfn.de/shibboleth";"aaidemo";"0e2cba36852b44d8be29e4168ec71e0d@uni-xy.de";"Znc0wfn/YabcZe7neb73Es123456";"";"2014-08-12 14:10:47.29";""
+  "https://idp.uni-xy.de/idp/shibboleth";"https://testsp2.aai.dfn.de/shibboleth";"aaidemo";"0e2cba36852b44d8be29e4168ec71e0d@uni-xy.de";"Znc0wfn/YabcZe7neb73Es123456";"";"2014-08-12 14:10:47.29";""</code>
+    - Man kopiert den modifizierten Dump zurück in die Tabelle ''shibpid''.
-.3. - Man kopiert den modifizierten Dump zurück in die Tabelle shibpid.
+  - Den IdP wieder starten und überprüfen, ob die Sache funktioniert hat.
-.) Den IdP wieder starten und überprüfen, ob die Sache funktioniert hat.
-Übrig bleibt nun noch das Entfernen der uid als Bestandteil der Bildungsvorschriften
+Übrig bleibt nun noch das Entfernen der ''uid'' als Bestandteil der Bildungsvorschriften anderer Attribute, z.B. beim ''eduPersonPrincipalName'' (= uid + "@uni-xy.de"). An den Bestandsnutzern kann man da nichts machen, der Plan ist aber, für neue Benutzer auch hier eduPersonPrincipalName = eduPersonUniqueId auszuliefern. Das sollte dann für eine ausreichende Kollisionsfreiheit sorgen.
-anderer Attribute, z.B. beim eduPersonPrincipalName (= uid + "@uni-xy.de"). An den
-Bestandsnutzern kann man da nichts machen, der Plan ist aber, für neue Benutzer auch hier
-eduPersonPrincipalName = eduPersonUniqueId auszuliefern. Das sollte dann für eine
-ausreichende Kollisionsfreiheit sorgen.
-{{tag>idp3 fixme}}
+{{tag>idp4}}

idp4