Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:attributes-nutshell [2020/04/16 15:50] – angelegt Silke Meyer
+++ de:attributes-nutshell [2024/11/28 13:50] (aktuell) – [Attributfilter] Links aktualisiert Doreen Liebenau
@@ Zeile 1: / Zeile 1: @@
+<- de:shibidp:config-attributes|Anpassung der Attributkonfiguration ^ de:shibidp:uebersicht|Überblick: Tutorial zur IdP-Inbetriebnahme ^ de:shibidp:troubleshooting|Troubleshooting ->
 ====== Attribute in a Nutshell ======
@@ Zeile 30: / Zeile 31: @@
 Der IdP kann konfiguriert werden, verschiedene Dinge mit den Attributen aus dem Nutzerverzeichnis zu tun:
-  * Er kann sie so, wie sie sind, weiterverarbeiten. Hier wird ein "simple" Attribut mit der id "surname" definiert. Es wird befüllt mit dem Wert des Attributes "sn", das der DataConnector myLDAP liefert.<code xml>    <AttributeDefinition id="surname" xsi:type="Simple">
+  * Er kann sie so, wie sie sind, weiterverarbeiten. Hier wird ein "simple" Attribut mit der id "sn" (surname) definiert. Es wird befüllt mit dem Wert des Attributes "sn", das der DataConnector myLDAP liefert.<code xml>    <AttributeDefinition id="sn" xsi:type="Simple">
         <InputDataConnector ref="myLDAP" attributeNames="sn"/>
     </AttributeDefinition></code>
@@ Zeile 44: / Zeile 45: @@
         </Script>
  </AttributeDefinition></code>
-  * Er kann neue Attribute erstellen, die z.B. von vorhandenen Attributen oder Werten abhängen. Im folgenden Beispiel wird ein Attribut aus einem anderen gebildet: Die eduPersonAffiliation muss bereits definiert sein und wird weiterverwendet. "Scoped" bedeutet, dass der in ''./conf/idp.properties'' definierte IdP-Scope ("hochschule-xy.de") an den Attributwert angehängt wird. So wird aus der eduPersonAffiliation die eduPersonScopedAffiliation gemacht. Wenn eduPersonAffiliation den Wert "student" hat, bekommt eduPersonScopedAffiliation den Wert "student@hochschule-xy.de". (vgl. [[https://wiki.shibboleth.net/confluence/display/IDP4/ScopedAttributeDefinition|ScopedAttributeDefinition im Shibboleth-Wiki]])<code xml>    <AttributeDefinition xsi:type="Scoped" id="eduPersonScopedAffiliation" scope="%{idp.scope}">
+  * Er kann neue Attribute erstellen, die z.B. von vorhandenen Attributen oder Werten abhängen. Im folgenden Beispiel wird ein Attribut aus einem anderen gebildet: Die eduPersonAffiliation muss bereits definiert sein und wird weiterverwendet. "Scoped" bedeutet, dass der in ''./conf/idp.properties'' definierte IdP-Scope ("hochschule-xy.de") an den Attributwert angehängt wird. So wird aus der eduPersonAffiliation die eduPersonScopedAffiliation gemacht. Wenn eduPersonAffiliation den Wert "student" hat, bekommt eduPersonScopedAffiliation den Wert "student@hochschule-xy.de". (vgl. [[https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199503258/ScopedAttributeDefinition|ScopedAttributeDefinition im Shibboleth-Wiki]])<code xml>    <AttributeDefinition xsi:type="Scoped" id="eduPersonScopedAffiliation" scope="%{idp.scope}">
         <InputAttributeDefinition ref="eduPersonAffiliation" />
     </AttributeDefinition></code>
-Diese Konfigurationen nehmen Sie in einer der zentralen Konfigurationsdateien ''./conf/attribute-resolver.xml'' vor: Dort sind sowohl die Attributquellen (LDAP, AD, SQL) als auch die IdP-intern definierten Attribute hinterlegt. Es gibt verschiedene Typen von ''AttributeDefinition'', u.a. Simple, Mapped, oder ScriptedAttribute, um mit den Attributen zu jonglieren. Alle Typen sind im [[https://wiki.shibboleth.net/confluence/display/IDP4/AttributeDefinitionConfiguration|Shibboleth-Wiki]] dokumentiert.
+Diese Konfigurationen nehmen Sie in einer der zentralen Konfigurationsdateien ''./conf/attribute-resolver.xml'' vor: Dort sind sowohl die Attributquellen (LDAP, AD, SQL) als auch die IdP-intern definierten Attribute hinterlegt. Es gibt verschiedene Typen von ''AttributeDefinition'', u.a. Simple, Mapped, oder ScriptedAttribute, um mit den Attributen zu jonglieren. Alle Typen sind im [[https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199502907/AttributeDefinitionConfiguration|Shibboleth-Wiki]] dokumentiert.
 ===== Attributfilter =====
-Welche Attribute an welche SPs herausgegeben werden, reguliert man über Attribute Filter Policies in ''./conf/attribute-filter.xml''. Dort werden die freizugebenden Attribute über ihre ID aus ''./conf/attribute-resolver.xml'' angesprochen. Die Kriterien, nach denen Filterregeln greifen sollen, sind sehr flexibel. Die gängigsten Fälle sind das Filtern nach EntityIDs, also einzelnen SPs, und nach Entity-Attributen, also nach Markern, die eine ganze Gruppe von SPs trägt. (Siehe auch im Shibboleth-Wiki:  [[https://wiki.shibboleth.net/confluence/display/IDP4/AttributeFilterConfiguration|AttributeFilterConfiguration]] und  [[https://wiki.shibboleth.net/confluence/display/IDP4/AttributeFilterPolicyConfiguration|AttributeFilterPolicyConfiguration]].)
+Welche Attribute an welche SPs herausgegeben werden, reguliert man über Attribute Filter Policies in ''./conf/attribute-filter.xml''. Dort werden die freizugebenden Attribute über ihre ID aus ''./conf/attribute-resolver.xml'' angesprochen. Die Kriterien, nach denen Filterregeln greifen sollen, sind sehr flexibel. Die gängigsten Fälle sind das Filtern nach EntityIDs, also einzelnen SPs, und nach Entity-Attributen, also nach Markern, die eine ganze Gruppe von SPs trägt. (Siehe auch im Shibboleth-Wiki:  [[https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199501794/AttributeFilterConfiguration|AttributeFilterConfiguration]] und  [[https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199501835/AttributeFilterPolicyConfiguration|AttributeFilterPolicyConfiguration]].)
 Eine einfache Filter-Policy, die //ein// Attribut an den SP mit der EntityID https://beispiel-sp.de/shibboleth herausgibt, könnte so aussehen:<code xml><AttributeFilterPolicy id="beispiel">
@@ Zeile 74: / Zeile 75: @@
 ===== Attribut-Encoding =====
-<callout color="#ff9900" title="Neuerung im IdP 4.x">
-Ab Shibboleth IdP 4.0.0 werden die Encoder in der Attribute Registry konfiguriert. Die alte Konfigurationsweise über ''./conf/attribute-resolver.xml'' ist weiterhin lauffähig!
-</callout>
 Service Provider verstehen die im IdP konfigurierten, menschenlesbaren Attributnamen nicht. Der IdP muss sie mithilfe eines Encoders konvertieren. Momentan werden von Shibboleth IdP von Haus aus drei Encoder unterstützt, nämlich SAML1 (veraltet), SAML2 und CAS. In Zukunft wird auch OIDC dazukommen.
-https://wiki.shibboleth.net/confluence/display/IDP4/AttributeEncoderPluginConfiguration
+https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199504645/AttributeEncoderPluginConfiguration
-Ab Shibboleth IdP 4.0.0 werden die Transcoding-Regeln in der neuen Attribute Registry konfiguriert. Bis Shibboleth IdP 3.4.6 standen die Encoder mit in der Attributdefinition in ''./conf/attribute-resolver.xml'' drin. Dies ist auch weiterhin eine funktionierende Konfiguration. Bei einer Neuinstallation sollten Sie jedoch den Weg der Attribute Registry gehen. Sie macht die Attributdefinition übersichtlicher.
 Die mitgelieferten Transcoding-Regeln liegen in ''./conf/attributes/default-rules.xml''. Sie können sie zunächst einfach lassen, wie sie sind, obwohl sie umfangreicher sind als nötig. Hier eine gekürzte Regel (lauffähige) für das mail-Attribut auf einem IdP, der nur SAML2 spricht:
@@ Zeile 121: / Zeile 118: @@
 </callout>
+{{tag>tutorial}}

tutorial