| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| de:shibidp:config-attributes-edupersonuniqueid [2020/05/13 15:32] – [eduPersonUniqueId] Silke Meyer | de:shibidp:config-attributes-edupersonuniqueid [2024/11/27 14:59] (aktuell) – veraltete Config ohne Attribute Registry entfernt Doreen Liebenau |
|---|
| |
| <callout color="#ff9900" title="Attribute Authority?"> | <callout color="#ff9900" title="Attribute Authority?"> |
| Im Kontext von Forschungsprojekten/-Infrastrukturen und Fachinformationsdiensten müssen häufig dienstspezifische Zugangsberechtigungen für Einzelpersonen oder einrichtungsübergreifende Personengruppen vergeben werden. Solche Informationen werden i.d.R. nicht in den IdMs der beteiligten Heimateinrichtungen gepflegt, sondern in eine weiteren Attributquelle: einer Attribute Authority. Attribute Authorities verwalten nur community- bzw. projektspezifische Attribute und werden bei der Autorisierung zusätzlich zum IdP befragt. | Im Kontext von Forschungsprojekten/-Infrastrukturen und Fachinformationsdiensten müssen häufig dienstspezifische Zugangsberechtigungen für Einzelpersonen oder einrichtungsübergreifende Personengruppen vergeben werden. Solche Informationen werden i.d.R. nicht in den IdMs der beteiligten Heimateinrichtungen gepflegt, sondern in eine weiteren Attributquelle: einer Attribute Authority. Attribute Authorities werden meist von den Projekten selbst betrieben. Sie verwalten nur community- bzw. projektspezifische Attribute und werden bei der Autorisierung zusätzlich zum IdP befragt. |
| </callout> | </callout> |
| |
| Die Attribute, die eine Attribut Authority verwaltet, müssen über einen global gültigen, eindeutigen Identifier auf die Accounts der Heimateinrichtungen gemappt werden. Dazu können z.B. ''eduPersonPrincipalName'', ''mail'' oder [[..:start|eduPersonUniqueId]] verwendet werden. | Die Attribute, die eine Attribut Authority verwaltet, müssen über einen global gültigen, eindeutigen Identifier auf die Accounts der Heimateinrichtungen gemappt werden. Dazu können z.B. ''eduPersonPrincipalName'', ''mail'' oder [[https://doku.tid.dfn.de/de:common_attributes#a12|eduPersonUniqueId]] verwendet werden. |
| |
| Die ''eduPersonUniqueId'' hat den Vorteil, dass sie pseudonym ist: Von SP-Seite aus kann nicht auf die dahinter liegende Identität rückgeschlossen werden. | Die ''eduPersonUniqueId'' hat den Vorteil, dass sie pseudonym ist: Von SP-Seite aus kann nicht auf die dahinter liegende Identität rückgeschlossen werden. |
| |
| ===== IdP 3.4-Syntax ===== | <callout color="#ff9900" title="Best Practice"> |
| <file xml /opt/shibboleth-idp/conf/attribute-resolver.xml> | Wir empfehlen, der [[de:shibidp:config-attributes-aaiplus#idp_4x | hier dokumentierten Best Practice]] zu folgen und zunächst einen subjectHash zu generieren, der dann sowohl für eduPersonUniqueId, als auch für die SAML Subject ID verwendet wird. |
| <AttributeDefinition xsi:type="ScriptedAttribute" id="eduPersonUniqueId"> | </callout> |
| <InputAttributeDefinition ref="uid" /> | |
| <DisplayName xml:lang="en">Unique ID</DisplayName> | |
| <DisplayName xml:lang="de">Eindeutige ID</DisplayName> | |
| <DisplayDescription xml:lang="en">Unique ID: A unique identifier for a person, mainly for inter-institutional user identification</DisplayDescription> | |
| <DisplayDescription xml:lang="de">Eindeutige Nutzerkennung</DisplayDescription> | |
| <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.13" friendlyName="eduPersonUniqueId" /> | |
| <Script><![CDATA[ | |
| DigestUtils = Java.type("org.apache.commons.codec.digest.DigestUtils"); | |
| // unique value erzeugen | |
| uniqueValue = uid.getValues().get(0) + "SALT_MIN_48_CHARS"; | |
| // md5 value erzeugen | |
| localpart = DigestUtils.md5Hex(uniqueValue); | |
| // Scope anhängen | |
| eduPersonUniqueId.getValues().add(localpart + "@%{idp.scope}"); | |
| ]]> | |
| </Script> | |
| </AttributeDefinition> | |
| </file> | |
| |
| ===== IdP 4.x-Syntax ===== | Alternativ können Sie auch einen ähnlichen Weg wie oben gehen. Damit das Attribut hier von der Attribute Registry verarbeitet werden kann, können Sie so ein neues scoped Attribut erzeugen, das dann von der Registry mit den richtigen Transcoder verarbeitet wird. |
| |
| <file xml /opt/shibboleth-idp/conf/attribute-resolver.xml> | <file xml /opt/shibboleth-idp/conf/attribute-resolver.xml> |
| <AttributeDefinition xsi:type="ScriptedAttribute" id="eduPersonUniqueId"> | <AttributeDefinition id="eduPersonUniqueId" xsi:type="ScriptedAttribute"> |
| <InputAttributeDefinition ref="uid" /> | <InputAttributeDefinition ref="uid" /> |
| <Script><![CDATA[ | <Script><![CDATA[ |
| DigestUtils = Java.type("org.apache.commons.codec.digest.DigestUtils"); | var ScopedValue = Java.type("net.shibboleth.idp.attribute.ScopedStringAttributeValue"); |
| // unique value erzeugen | var DigestUtils = Java.type("org.apache.commons.codec.digest.DigestUtils"); |
| uniqueValue = uid.getValues().get(0) + "SALT_MIN_48_CHARS"; | // unique value erzeugen (do not change salt) |
| // md5 value erzeugen | var uniqueValue = uid.getValues().get(0) + "SALT_MIN_48_CHARS"; |
| localpart = DigestUtils.md5Hex(uniqueValue); | // md5 value erzeugen |
| // Scope anhängen | var idSaltHash = DigestUtils.md5Hex(uniqueValue); |
| eduPersonUniqueId.getValues().add(localpart + "@%{idp.scope}"); | // Scope dazu |
| ]]> | eduPersonUniqueId.getValues().add(new ScopedValue(idSaltHash, "%{idp.scope}")); |
| | ]]> |
| </Script> | </Script> |
| </AttributeDefinition> | </AttributeDefinition> |
| </file> | </file> |
| |
| {{tag>idp3 idp4}} | {{tag>idp4}} |