Dies ist eine alte Version des Dokuments!


Attribute Authority

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. 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 hohen Aufwand zur Vermeidung von Inkonsistenzen der Nutzerdaten 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.

Weiterführende Informationen

Im Gegensatz zu einem 'normalen' IdP wird der <IdPSSODescriptor> nicht benötigt, relevant ist lediglich der <AttributeAuthorityDescriptor>. In der DFN-AAI Metadatenverwaltung werden Attribute Authorities als eigener Entity-Typ unterstützt.

Einzig benötigtes Profil ist Attribute Query. Dieses darf nur für berechtigte SPs freigegeben werden.

Beispiel:

/opt/shibboleth-idp/conf/relying-party.xml
    <!--...-->
    <bean id="shibboleth.UnverifiedRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
            <!-- hier sollte grundsätzlich kein Profil aktiviert werden /> -->
            </list>
        </property>
    </bean>
 
    <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
             <!-- auch hier geben wir kein Profil frei -->
            </list>
        </property>
    </bean>
 
    <!-- In den Overrides wird nun das Attribute Query Profile für ausgewählte SP aktiviert -->
 
    <util:list id="shibboleth.RelyingPartyOverrides">
        <bean parent="RelyingPartyByName" c:relyingPartyIds="#{{'https://trusted-sp1.org/shibboleth','https://trusted-sp2.org/shibboleth'}}">
            <property name="profileConfigurations">
                <list>
                    <ref bean="SAML2.AttributeQuery" />
                </list>
            </property>
        </bean>
    </util:list>

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) 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 das dann ungefähr wie folgt aus:

/opt/shibboleth-idp/conf/attribute-resolver.xml
    <!-- ... -->
    <AttributeDefinition id="eduPersonEntitlement" xsi:type="Simple">
        <InputDataConnector ref="myDatabase" attributeNames="name" />
        <!-- NB: bei Shibboleth IdP 4.x sind die AttributeEncoder ausgelagert! -->
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" friendlyName="myEduPersonEntitlement" encodeType="false"/>
    </AttributeDefinition>
 
    <!-- ... -->
 
    <DataConnector id="myDatabase" xsi:type="RelationalDatabase">
       <BeanManagedConnection>shibboleth.MySQLDataSource</BeanManagedConnection>
       <QueryTemplate>
        <![CDATA[
             SELECT entitlement from user u where u.subjectid='$resolutionContext.principal';
        ]]>
       </QueryTemplate>
       <ResultCache expireAfterAccess="PT10S"/>
    </DataConnector>
    <!-- ... -->
  • Zuletzt geändert: vor 4 Jahren