Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:attributes [2020/04/16 15:35] – Silke Meyer | de:attributes [2020/04/16 16:10] – Silke Meyer | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ~~NOTOC~~ | ||
====== Attribute ====== | ====== Attribute ====== | ||
- | {{INLINETOC 2}} | ||
- | ===== Attribute in a Nutshell ===== | ||
- | |||
- | ==== IdP und SP ==== | ||
- | |||
- | Ein **Identity Provider** stellt mithilfe von Attributen Informationen über Nutzer*innen zur Verfügung. Diese Attribute bilden die Grundlage für die Autorisierung am Service Provider. Daneben gibt es Attribute, die der eindeutigen Identifizierung von Nutzer*innen dienen (z.B. givenName, sn, eduPersonPrincipalName oder mail). Diese Attribute können am SP zur Personalisierung des Dienstes dienen. | ||
- | |||
- | Ein **Service Provider** nimmt die Attribute entgegen und gibt sie an die geschützte Anwendung weiter. Die SP-Software und/oder die Anwendung entscheiden anhand ihrer konfigurierten Regeln über den Zugriff. | ||
- | |||
- | ==== Attributschemata ==== | ||
- | |||
- | Wie es Ihnen möglicherweise von Verzeichnisdiensten bekannt ist, sind auch hier **Schemata** das Organisationsprinzip von Attributen. Ein Schema liegt fest, welche Attribute es gibt, welche und wie viele Werte ein Attribut haben kann und was es bedeutet. Im Föderationsumfeld haben sich folgende Schemata etabliert: | ||
- | * [[https:// | ||
- | * [[https:// | ||
- | * dfnEduPerson (im e-Learning-Bereich in Deutschland verbreitet) | ||
- | * weitere Attribute, etwa aus dem inetOrgPerson-Schema | ||
- | Für ausführlichere Informationen schauen Sie bitte auch [[de: | ||
- | <callout color="# | ||
- | Die Schemata können, müssen aber nicht in Ihrem IdM vorhanden sein! Der IdP kann zwischen den Attributen im IdM und den von SPs verlangten Attributen übersetzen. | ||
- | </ | ||
- | |||
- | Hier sehen Sie ein paar Beispiele für gängige Attribute. Für weitere Informationen schauen Sie bitte auf unsere [[de: | ||
- | |||
- | ^ Schema ^ Attributname ^ Bedeutung ^ Beispielwert ^ | ||
- | |eduPerson | eduPersonScopedAffiliation | Status innerhalb der Heimateinrichtung mit Scope | student@beispiel-uni.de | | ||
- | | |eduPersonPrincipalName | eindeutiger, | ||
- | | | eduPersonEntitlement | Berechtigung | urn: | ||
- | | SCHAC | schacPersonalUniqueCode | insbes. Matrikelnummer | urn: | ||
- | |||
- | ==== Attributdefinition am IdP ==== | ||
- | |||
- | 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 " | ||
- | < | ||
- | </ | ||
- | * Er kann sie splitten, neu zusammenfügen oder umschreiben. In diesem Beispiel wird inline Javascript verwendet, um eine Berechtigung in Abhängigkeit vom Wert eines anderen Attributes zu vergeben. Die eduPersonAffiliation muss bereits definiert sein. Dann kann sie als Input für eine neue Definition verwendet werden. Wenn der Wert von eduPersonAffiliation " | ||
- | < | ||
- | < | ||
- | < | ||
- | < | ||
- | if (eduPersonAffiliation.getValues().contains(" | ||
- | eduPersonEntitlement.getValues().add(" | ||
- | } | ||
- | | ||
- | </ | ||
- | </ | ||
- | * 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. " | ||
- | < | ||
- | </ | ||
- | |||
- | Diese Konfigurationen nehmen Sie in einer der zentralen Konfigurationsdateien '' | ||
- | |||
- | ==== Attributfilter ==== | ||
- | |||
- | Welche Attribute an welche SPs herausgegeben werden, reguliert man über Attribute Filter Policies in '' | ||
- | |||
- | Eine einfache Filter-Policy, | ||
- | < | ||
- | < | ||
- | </ | ||
- | |||
- | Eine von uns empfohlene Filterregel gibt einige anonyme Informationen grundsätzlich heraus: Egal, wer fragt, das Attribut '' | ||
- | < | ||
- | < | ||
- | < | ||
- | </ | ||
- | < | ||
- | < | ||
- | <Rule xsi: | ||
- | <Rule xsi: | ||
- | </ | ||
- | </ | ||
- | </ | ||
- | </ | ||
- | |||
- | ==== Attribut-Encoding ==== | ||
- | <callout color="# | ||
- | Ab Shibboleth IdP 4.0.0 werden die Encoder in der Attribute Registry konfiguriert. Die alte Konfigurationsweise über '' | ||
- | </ | ||
- | |||
- | Service Provider verstehen die im IdP konfigurierten, | ||
- | https:// | ||
- | |||
- | 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 '' | ||
- | |||
- | Die mitgelieferten Transcoding-Regeln liegen in '' | ||
- | <code xml> | ||
- | <bean parent=" | ||
- | < | ||
- | <props merge=" | ||
- | <!-- das Attribut, um das es geht --> | ||
- | <prop key=" | ||
- | <!-- Es soll nur SAML2 unterstützt werden. --> | ||
- | <prop key=" | ||
- | <!-- Die standardisierte oid für mail lautet urn: | ||
- | <prop key=" | ||
- | <!-- Anzeigenamen für die Zustimmungsabfrage vor der Attributfreigabe --> | ||
- | <prop key=" | ||
- | <prop key=" | ||
- | </ | ||
- | </ | ||
- | </ | ||
- | |||
- | ==== Attributübertragung ==== | ||
- | |||
- | Nachdem die Benutzer*innen der Attributübertragung zugestimmt haben, schickt der IdP eine SAML-Assertion an den SP. Ein Teil der SAML-Assertion ist das Attribute Statement. Der empfangende SP erkennt die Attribute anhand der URIs (meist urn:oid) im Feld " | ||
- | <code xml> | ||
- | < | ||
- | < | ||
- | Name=" | ||
- | < | ||
- | </ | ||
- | < | ||
- | Name=" | ||
- | < | ||
- | </ | ||
- | </ | ||
- | </ | ||
- | |||
- | <callout color="# | ||
- | Wenn Sie möchten, dass Ihr IdP die Assertions loggt, stellen Sie '' | ||
- | </ | ||