Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:aai:attribute_authority [2020/07/01 18:07] Wolfgang Pempede:aai:attribute_authority [2022/05/02 14:48] (aktuell) Wolfgang Pempe
Zeile 1: Zeile 1:
-~~NOTOC~~ 
 ====== Attribute Authority ====== ====== Attribute Authority ======
-{{INLINETOC 2}} + 
-Bei Attribute Authorities handelt es sich um externe Attributquellen, anhand derer ein Service Provider zusätzliche, i.d.R. projektspezifische Nutzerdaten abrufen kann, die nicht von der Heimateinrichtung gepflegt werden (sollen). In der Regel geht hierbei um Projekt- oder Infrastruktur-spezifische Berechtigungen (Entitlements), die vom Projekt bzw. der Forschungsinfrastruktur festgelegt und gepflegt werden. +Bei Attribute Authorities handelt es sich um externe Attributquellen, anhand derer ein Service Provider zusätzliche, i.d.R. projektspezifische Nutzerdaten abrufen kann, die nicht von der Heimateinrichtung gepflegt werden (sollen). In der Regel geht es hierbei um Projekt- oder Infrastruktur-spezifische Berechtigungen (Entitlements), die vom Projekt bzw. der Forschungsinfrastruktur festgelegt und gepflegt werden. 
 Grundsätzlich kann auch die hinter dem jeweiligen SP liegende Anwendung eine entsprechende Datenbank anbinden. Falls die betreffende Anwendung dies nicht von Haus aus unterstützt oder die Betreiber den damit verbundenen Aufwand vermeiden wollen, ist es einfacher, dem SP die Aufgabe der Sammlung der Autorisierungsdaten zu übertragen - der diese standardkonform (SAML2) wahrnimmt, indem er Attribute Queries an eine oder mehrere Attribute Authorities richtet. Grundsätzlich kann auch die hinter dem jeweiligen SP liegende Anwendung eine entsprechende Datenbank anbinden. Falls die betreffende Anwendung dies nicht von Haus aus unterstützt oder die Betreiber den damit verbundenen Aufwand vermeiden wollen, ist es einfacher, dem SP die Aufgabe der Sammlung der Autorisierungsdaten zu übertragen - der diese standardkonform (SAML2) wahrnimmt, indem er Attribute Queries an eine oder mehrere Attribute Authorities richtet.
  
 Technisch gesehen handelt es sich bei einer Attribute Authority um einen üblicherweise funktionsreduzierten IdP, der als einziges Profil Attribute Queries unterstützen muss. Hierzu ist es erforderlich, dass der IdP der Heimateinrichtung ein Attribut liefert (z.B. E-Mail, eduPersonPrincipialName, eduPersonUniqueId, Subject-Id), das den / die jeweilige(n) Nutzer(in) eindeutig identifiziert und anhand dessen die Attribute Query bei einer oder mehreren Attribute Authorities erfolgt. Technisch gesehen handelt es sich bei einer Attribute Authority um einen üblicherweise funktionsreduzierten IdP, der als einziges Profil Attribute Queries unterstützen muss. Hierzu ist es erforderlich, dass der IdP der Heimateinrichtung ein Attribut liefert (z.B. E-Mail, eduPersonPrincipialName, eduPersonUniqueId, Subject-Id), das den / die jeweilige(n) Nutzer(in) eindeutig identifiziert und anhand dessen die Attribute Query bei einer oder mehreren Attribute Authorities erfolgt.
  
-=== Weiterführende Informationen === +Weiterführende Informationen finden Sie unter: 
-  * [[https://www.dfn.de/fileadmin/5Presse/DFNMitteilungen/DFN_Mitteilungen_87.pdf|"Mit verteilten Rollen: Attribute Authorities in der DFN-AAI"]] (Gerrit Gragert + Wolfgang Pempe in: DFN-Mitteilungen 87) +  * [[https://www2.dfn.de/fileadmin/5Presse/DFNMitteilungen/DFN_Mitteilungen_87.pdf|"Mit verteilten Rollen: Attribute Authorities in der DFN-AAI"]] (Gerrit Gragert + Wolfgang Pempe in: DFN-Mitteilungen 87) 
-  * [[de:shibidp3userdepro|User Deprovisionierung via Attribute Query]]+  * [[de:shibidp:config-deprovisionierung|User Deprovisionierung via Attribute Query]]
  
 ===== Shibboleth IdP als Stand-alone Attribute Authority ===== ===== Shibboleth IdP als Stand-alone Attribute Authority =====
Zeile 52: Zeile 51:
  
 ==== Attribute Resolver ==== ==== Attribute Resolver ====
-Ein anfragender SP verwendet ein Attribut, anhand dessen ein*e Nutzer*in eindeutig identifiziert werden kann. Der SP verlangt z.B. vom Heimat-IdP das Attribut ''eduPersonUniqueId'' oder ''Subject-Id'' und richtet mit diesem Attribut als Identifier eine Attribute Query gegen die Attribute Authority. Der IdP muss in der Lage sein, dieses Attribut aufzulösen, d.h. auf einen "Principal" abzubilden (siehe dazu weiter unten, c14n) und die für dieses Identität hinterlegten Attribute abzurufen und an den anfragenden SP zu senden. Hierbei handelt es sich i.d.R. um eduPersonEntitlement mit Community-spezifischen Werten. Diese Informationen werden meistens in einer SQL-Datenbank abgelegt und von hierzu berechtigten Angehörigen der betreffenden Forschungscommunity gepflegt.+Ein anfragender SP verwendet ein Attribut, anhand dessen ein*e Nutzer*in eindeutig identifiziert werden kann. Der SP verlangt vom Heimat-IdP z.B. das Attribut ''eduPersonUniqueId'' oder ''Subject-Id'' und richtet mit diesem Attribut als Identifier eine Attribute Query gegen die Attribute Authority. Der IdP muss in der Lage sein, dieses Attribut aufzulösen, d.h. auf einen "Principal" abzubilden (siehe dazu weiter unten, c14n) und die für dieses Identität hinterlegten Attribute abzurufen und an den anfragenden SP zu senden. Hierbei handelt es sich i.d.R. um eduPersonEntitlement mit Community-spezifischen Werten. Diese Informationen werden meistens in einer SQL-Datenbank abgelegt und von hierzu berechtigten Angehörigen der betreffenden Forschungscommunity gepflegt.
  
 Im Attribute Resolver sieht dies dann ungefähr wie folgt aus: Im Attribute Resolver sieht dies dann ungefähr wie folgt aus:
Zeile 110: Zeile 109:
    <AttributeResolver type="SimpleAggregation" attributeId="subject-id" format="urn:oasis:names:tc:SAML:attribute:subject-id">    <AttributeResolver type="SimpleAggregation" attributeId="subject-id" format="urn:oasis:names:tc:SAML:attribute:subject-id">
        <Entity>https://trusted-attribute-authority.example.org/idp/shibboleth</Entity>        <Entity>https://trusted-attribute-authority.example.org/idp/shibboleth</Entity>
-       <Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="eduPersonEntitlement"/>+       <saml2:Attribute xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="eduPersonEntitlement"/>
    </AttributeResolver>    </AttributeResolver>
    <!-- ... -->    <!-- ... -->
 </file> </file>
  
-Über eine SP-seitige Attribute Filter Policy lässt sich festlegen, dass (z.B.) eduPersonEntitlement nur von der gewünschten Attribute Authority akzeptiert wird - und nicht von irgendwelchen anderen IdPs:+Über eine SP-seitige Attribute Filter Policy lässt sich festlegen, dass (z.B.) eduPersonEntitlement nur von der gewünschten Attribute Authority akzeptiert wird - und nicht von irgendwelchen anderen IdPs: \\ 
 +**Alte Syntax:**
 <file xml /etc/shibboleth/attribute-policy.xml> <file xml /etc/shibboleth/attribute-policy.xml>
    <!-- ... -->    <!-- ... -->
Zeile 123: Zeile 123:
    <!-- ... -->    <!-- ... -->
 </file> </file>
- +**Neue Syntax:** 
-{{tag>idp3 idp4 sp}}+<file xml /etc/shibboleth/attribute-policy.xml> 
 +   <!-- ... --> 
 +   <AttributeRule attributeID="eduPersonEntitlement"> 
 +      <PermitValueRule xsi:type="Issuer" value="https://trusted-attribute-authority.example.org/idp/shibboleth"/> 
 +   <AttributeRule> 
 +   <!-- ... --> 
 +</file> 
 +{{tag>idp4 sp attribute-authority}}
  • Zuletzt geändert: vor 4 Jahren