Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp:config-pidspecials [2020/10/15 12:24] – [Beispiel für den Wechsel des IdM-Quellattributs] Silke Meyer
+++ de:shibidp:config-pidspecials [2025/03/10 14:12] (aktuell) – Doreen Liebenau
@@ Zeile 73: / Zeile 73: @@
 Möchte man die Freigabe der persistentId analog zu Attribut-Filterregeln weiter einschränken, sind mehrere Schritte nötig.
-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.
+Man kann zwar mit Hilfe von [[https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509766/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.
 Um die persistentId dennoch nur dann an einen SP auszuliefern, wenn Nutzer*innen z.B. ein bestimmtes Entitlement haben, muss man wie folgt vorgehen:
@@ Zeile 98: / 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>
+  - Definition einer Condition mit allen [[https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509766/ActivationConditions#Attribute-Checking|Anforderungen an ein Attribut]] und Referenzierung als Abhängigkeit bei der Generierung der persistentID: <file xml /system/conf/saml-nameid-system.xml>
 <!-- ... -->
@@ Zeile 147: / Zeile 147: @@
 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>idp5}}

idp5