REFEDS Assurance Framework - Identity Provider

(allgemeine Informationen zu Verlässlichkeit/Assurance)

Erste Schritte und Voraussetzungen

Lesen Sie bitte die aktuelle Version der Spezifikation!
Bei Fragen wenden Sie sich bitte an das DFN-AAI Team.

Um als Identity Provider bzw. Heimateinrichtung grundsätzliche Konformität mit dem REFEDS Assurance Framework zu signalisieren und entsprechende Attributwerte zu übertragen, müssen vier sog. Conformance Criteria erfüllt sein:

The Identity Provider is operated with organizational-level authority
Kommentar: IdPs müssen auch vertragstechnisch im Namen der jeweiligen Einrichtung betrieben werden, einzelne Fakultäten oder Universitäts-Institute kommen hierfür nicht in Frage
The Identity Provider is trusted enough to be used to access your organization’s own systems
Kommentar: … sofern diese SAML-fähig sind. Etwa die Hälfte der an der DFN-AAI teilnehmenden Einrichtungen nutzt hierfür die lokalen Metadaten
You publish contact information for your Identity Provider and respond in a timely fashion to operational issues
Kommentar: Diese Punkte sind auch Gegenstand der DFN-AAI-Dienstvereinbarung
You apply security practices to protect user information, safeguard transaction integrity, and ensure timely incident response
Kommentar: Das Thema Betriebssicherheit gilt in besonderen Maße für Identity Provider. Hierzu gehört auch das zeitnahe Einspielen von Security Updates!
You ensure the metadata registered in Federation is complete, accurate and up to date.
Kommentar: Die Verpflichtung, Betriebs- und Kontakt-Informationen aktuell und korrekt zu halten, ist vertraglich in der DFN-AAI-Dienstvereinbarung festgelegt.

Die Erfüllung dieser Kriterien ist eine der Voraussetzungen für die Teilnahme an der DFN-AAI. Siehe hierzu auch Voraussetzungen für die Teilnahme an der DFN-AAI und Best Practices.

Beachten Sie bitte auch folgendes:

Nachweislich falsche Angabe zur Verlässlichkeit von Identitäten führen zum Ausschluss aus der DFN-AAI!

Dienste, die Assurance-Informationen erfordern

Meta-Videoportal für die Lehrkräftebildung, siehe auch unter Entity Categories
Helmholtz AAI
EuroHPC: LUMI, PUHURI, siehe Letter for Identity Providers
National Institutes of Health (NIH): https://spaces.at.internet2.edu/display/federation/get-nih-ready

Liste der IdPs aus dem HPC-Kontext, die eduPersonAssurance (nicht) übertragen: https://wiki.geant.org/display/MyAccessID/IdP+Status+Report

Konfigurationsbeispiele

Wichtiger Hinweis:
Die folgenden Beispiele sind als Anregungen gedacht und sollten keinesfalls unreflektiert via copy + paste übernommen werden!

Bitte recherchieren Sie gründlich, welche Kriterien des REFEDS Assurance Framework seitens Ihrer Heimateinrichtung auf welche Weise und ggf. für welche Nutzendengruppen erfüllt sind. Von dieser Faktenlage ausgehend erstellen Sie bitte eine entsprechend angepasste Attribute Resolver Konfiguration.

Föderationsmetadaten

Stellen Sie sicher, dass der IdP mindestens die Datei dfn-aai-sp-metadata.xml importiert! Ein Konfigurationsbeispiel findet sich unter Produktivbetrieb.

Attributfreigabe

Da eduPersonAssurance keine personenbezogenen Daten enthält und Service Provider die Information zur Verlässlichkeit von Identitäten für die Autorisierungsentscheidung benötigen, sollte dieses Attribut grundsätzlich an alle Service Provider übertragen werden. Siehe hierzu das Beispiel zur Attribute Filter Basiskonfiguration.

User Consent

Um das Attribut eduPersonAssurance - sofern gewünscht - vom User Consent auszunehmen, muss die Datei consent-intercept-config.xml entsprechend angepasst werden.

Attribute Resolver

Um gegenüber Service Providern die grundsätzliche Konformität mit dem REFEDS Assurance Framework zu signalisieren, genügt es, das sog. 'Prefix' als Attributwert zu übertragen. Dies ist die Minimalkonfiguration. Weiterhin wird hier über den Wert https://refeds.org/assurance/version/2 die grundsätzliche Konformität mit Version 2 des REFEDS Assurance signalisiert.

./conf/attribute-resolver.xml

...
    <AttributeDefinition xsi:type="Simple" id="eduPersonAssurance">
        <InputDataConnector ref="staticAttributes" attributeNames="eduPersonAssurance" />
    </AttributeDefinition>
...
    <DataConnector id="staticAttributes" xsi:type="Static">
        <Attribute id="eduPersonAssurance">
            <Value>https://refeds.org/assurance</Value>
            <Value>https://refeds.org/assurance/version/2</Value>
        </Attribute>
    </DataConnector>
...

Sind die Prozesse zur Aktualisierung der Nutzendendaten und zur Deprovisionierung einheitlich für alle Nutzenden und erfolgt die Aktualisierung innerhalb eines Monats, kann der entsprechende Attributwert ebenfalls statisch gesetzt werden:

./conf/attribute-resolver.xml

...
    <DataConnector id="staticAttributes" xsi:type="Static">
        <Attribute id="eduPersonAssurance">
            <Value>https://refeds.org/assurance</Value>
            <Value>https://refeds.org/assurance/version/2</Value>
            <Value>https://refeds.org/assurance/ATP/ePA-1m</Value>
        </Attribute>
    </DataConnector>
...

Falls die Anforderungen bezüglich Identifier Uniqueness (Unique-1 bis Unique-4) erfüllt werden: $PREFIX$/ID/unique. Für Fälle, in denen noch der eduPersonPrincipalName zum Einsatz kommen und auch für dieses Attribut die Bedingungen Unique-1 bis Unique-3 gegeben sind, kann ergänzend $PREFIX$/ID/eppn-unique-no-reassign gesetzt werden.

./conf/attribute-resolver.xml

...
    <DataConnector id="staticAttributes" xsi:type="Static">
        <Attribute id="eduPersonAssurance">
            <Value>https://refeds.org/assurance</Value>
            <Value>https://refeds.org/assurance/version/2</Value>
            <Value>https://refeds.org/assurance/ATP/ePA-1m</Value>
            <Value>https://refeds.org/assurance/ID/unique</Value>
            <Value>https://refeds.org/assurance/ID/eppn-unique-no-reassign</Value>
        </Attribute>
    </DataConnector>
...

Hier ein etwas komplexeres Beispiel, das von folgenden Annahmen ausgeht:

bei bestimmten Nutzendengruppen erfolgt die Aktualisierung der Daten im Identity Management System (und dem daran angeschlossenen Nutzendenverzeichnis) innerhalb eines Tages
bei den Beschäftigten des Universitätsklinikums, die offiziell Angehörige der Universität sind, geschieht dies hingegen innerhalb eines Monats
bei frisch immatrikulierten Studierenden, bei denen noch keine Identitätsprüfung anhand eines amtlichen Ausweisdokuments oder eines analogen eIDAS-konformen Tokens erfolgt ist, wird $PREFIX$/IAP/low angenommen,
bei allen anderen Nutzenden ist bereits eine den Vorgaben entsprechende Identitätsprüfung erfolgt, daher kann $PREFIX$/IAP/medium zusätzlich gesetzt werden. Selbiges gilt für Studierende, bei denen die Validierung im Rahmen ihrer ersten Prüfung erfolgt ist.
die in den o.g. Punkten genannten Unterschiede werden über Gruppenmitgliedschaften anhand des LDAP-/AD-Attributs memberOf modelliert.

Wichtig: Bei $PREFIX$/IAP/medium und $PREFIX$/IAP/high müssen die jeweils niedrigeren Verlässlichkeiten mit übertragen werden. Analog ist bei $PREFIX$/ATP/ePA-1d zu verfahren, hier muss $PREFIX$/ATP/ePA-1m mit angegeben werden.

./conf/attribute-resolver.xml

...
    <AttributeDefinition xsi:type="ScriptedAttribute" id="eduPersonAssurance">
        <InputDataConnector ref="myLDAP" attributeNames="memberOf" />
        <Script><![CDATA[
            eduPersonAssurance.getValues().add("https://refeds.org/assurance");
            eduPersonAssurance.getValues().add("https://refeds.org/assurance/version/2");
            eduPersonAssurance.getValues().add("https://refeds.org/assurance/IAP/low");
            eduPersonAssurance.getValues().add("https://refeds.org/assurance/ATP/ePA-1m");
            if (!memberOf.getValues().contains("unchecked_student")) {
               eduPersonAssurance.getValues().add("https://refeds.org/assurance/IAP/medium");
            }
            if (!memberOf.getValues().contains("university_hospital_staff")) {
               eduPersonAssurance.getValues().add("https://refeds.org/assurance/ATP/ePA-1d");
            }
        ]]>
        </Script>
    </AttributeDefinition>
...

(Shibboleth Wiki: Scripted Attribute Definition)

Alternativ lässt sich der oben angenommene Sachverhalt auch über eine Mapped Attribute Definition abbilden:

./conf/attribute-resolver.xml

...
    <AttributeDefinition xsi:type="MappedAttribute" id="eduPersonAssurance">
        <InputDataConnector ref="myLDAP" attributeNames="memberOf" />
        <ValueMap>
            <ReturnValue>https://refeds.org/assurance</ReturnValue>
            <SourceValue caseSensitive="false">checked_students</SourceValue>
            <SourceValue caseSensitive="false">unchecked_students</SourceValue>
            <SourceValue caseSensitive="false">university_staff</SourceValue>
            <SourceValue caseSensitive="false">university_hospital_staff</SourceValue>
        </ValueMap>
        <ValueMap>
            <ReturnValue>https://refeds.org/assurance/IAP/low</ReturnValue>
            <SourceValue caseSensitive="false">checked_students</SourceValue>
            <SourceValue caseSensitive="false">unchecked_students</SourceValue>
            <SourceValue caseSensitive="false">university_staff</SourceValue>
            <SourceValue caseSensitive="false">university_hospital_staff</SourceValue>
        </ValueMap>
        <ValueMap>
            <ReturnValue>https://refeds.org/assurance/IAP/medium</ReturnValue>
            <SourceValue caseSensitive="false">checked_students</SourceValue>
            <SourceValue caseSensitive="false">university_staff</SourceValue>
            <SourceValue caseSensitive="false">university_hospital_staff</SourceValue>
        </ValueMap>
        <ValueMap>
            <ReturnValue>https://refeds.org/assurance/ATP/ePA-1d</ReturnValue>
            <SourceValue caseSensitive="false">checked_students</SourceValue>
            <SourceValue caseSensitive="false">unchecked_students</SourceValue>
            <SourceValue caseSensitive="false">university_staff</SourceValue>
        </ValueMap>
        <ValueMap>
            <ReturnValue>https://refeds.org/assurance/ATP/ePA-1m</ReturnValue>
            <SourceValue caseSensitive="false">checked_students</SourceValue>
            <SourceValue caseSensitive="false">unchecked_students</SourceValue>
            <SourceValue caseSensitive="false">university_staff</SourceValue>
            <SourceValue caseSensitive="false">university_hospital_staff</SourceValue>
        </ValueMap>
    </AttributeDefinition>
...

(Shibboleth Wiki: Mapped Attribute Definition)

Hier noch ein Beispiel, dass davon ausgeht, dass für alle Mitarbeiter:innen folgendes gilt: „The identity proofing and credential issuance, renewal and replacement are done in a way that qualifies (or would qualify) the user to access the Home Organisation’s internal administrative systems“ (z.B. Finanzadministration, Studierendenverwaltung, etc.), so dass für diese User $PREFIX$/IAP/local-enterprise gesetzt werden kann:

./conf/attribute-resolver.xml

...
    <AttributeDefinition xsi:type="ScriptedAttribute" id="eduPersonAssurance">
        <InputAttributeDefinition ref="eduPersonAffiliation" />
        <Script><![CDATA[
            eduPersonAssurance.getValues().add("https://refeds.org/assurance");
            eduPersonAssurance.getValues().add("https://refeds.org/assurance/version/2");
            if (eduPersonAffiliation.getValues().contains("staff")) {
               eduPersonAssurance.getValues().add("https://refeds.org/assurance/IAP/local-enterprise");
            }
        ]]>
        </Script>
    </AttributeDefinition>
...

Materialien

REFEDS Assurance Framework Implementation Guidance for InCommon Participants (einige Hintergrundinformationen, die auch für die DFN-AAI relevant sind)
Comparison Guide to Identity Assurance Mappings for Infrastructures
Making Identity Assurance and Authentication Strength Work for Federated Infrastructures
Materialien vom AAI-Workshop Februar 2022

assurance