Zum grundlegenden Verständnis der Attribut-Generierung, -Freigabe und -Übertragung empfehlen wir die Seite Attributes in a Nutshell.
Die Erzeugung und Freigabe der SAML-Attribute wird über die Dateien .conf/attribute-resolver.xml, ./conf/attribute-filter.xml und ./conf/attribute-registry.xml gesteuert. Als nächstes laden Sie sich hier ein funktionierendes Minimalbeispiel herunter und testen damit, ob Ihr IdP Attribute an unseren Test-SP übermittelt. Die detaillierte Attributfreigabe für Ihren speziellen IdP machen Sie später.
attribute-resolver.xml aus einer IdP 3.x-Installation kann nicht einfach in eine Neuinstallation von IdP 4.x hineinkopiert werden! Die Elemente „DisplayName“, „DisplayDescription“ und „AttributeEncoder“, die in der Resolver-Syntax des 3er-IdP enthalten waren, sind jetzt in der Attribute Registry unterhalb von ./conf/attributes definiert. Diese Zeilen müssen aus attribute-resolver.xml entfernt werden, damit die Datei in einem neu installierten 4er-IdP verwendet werden kann.
Die zentrale Konfigurationsdatei für die Generierung von Attributen ist ./conf/attribute-resolver.xml. Hier definieren Sie
Um es zunächst übersichtlicher zu halten, legen Sie sich bitte unten stehende Beispieldatei nach ./conf/attribute-resolver.xml. Sie ist für Testzwecke nach der Erstinstallation gedacht. Die Werte für attributeNames müssen ggf. den tatsächlichen Attributnamen in Ihrem Nutzerverzeichnis angepasst werden. Für den späteren Produktivbetrieb müssen i.d.R. noch mindestens die Definitionen der für den Bibliotheksbereich relevanten Attribute eduPerson(Scoped)Affiliation und eduPersonEntitlement ergänzt werden, siehe die entsprechende Dokumentation.
(Ein Klick auf den Dateinamen startet den Download)
<?xml version="1.0" encoding="UTF-8"?> <AttributeResolver xmlns="urn:mace:shibboleth:2.0:resolver" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd"> <!-- ========================================== --> <!-- Attribute Definitions --> <!-- ========================================== --> <!-- Attribute aus Userangaben --> <AttributeDefinition id="uid" xsi:type="PrincipalName" /> <AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" scope="%{idp.scope}"> <InputAttributeDefinition ref="uid" /> </AttributeDefinition> <!--- Attribute aus dem IdM --> <!-- Bitte beachten Sie unten im Data Connector "myLDAP" die Zeile "exportAttributes". Dort werden all die Attribute automatisch aus dem IdM geholt, die im IdM genau so heißen, wie der IdP sie in seiner Attribute Registry auch definiert hat. Für diese Attribute brauchen Sie dann hier keine eigene Attributdefinition mehr. Analog verhält es sich mit dem Data Connector "staticAttributes" --> <!-- ========================================== --> <!-- Data Connectors --> <!-- ========================================== --> <DataConnector id="myLDAP" xsi:type="LDAPDirectory" ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}" baseDN="%{idp.attribute.resolver.LDAP.baseDN}" principal="%{idp.attribute.resolver.LDAP.bindDN}" principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}" useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}" connectTimeout="%{idp.attribute.resolver.LDAP.connectTimeout}" trustFile="%{idp.attribute.resolver.LDAP.trustCertificates}" responseTimeout="%{idp.attribute.resolver.LDAP.responseTimeout}" failFastInitialize="%{idp.pool.LDAP.failFastInitialize:false}" exportAttributes="givenName sn mail displayName" > <FilterTemplate> <![CDATA[ %{idp.attribute.resolver.LDAP.searchFilter} ]]> </FilterTemplate> <ConnectionPool minPoolSize="%{idp.pool.LDAP.minSize:3}" maxPoolSize="%{idp.pool.LDAP.maxSize:10}" blockWaitTime="%{idp.pool.LDAP.blockWaitTime:PT3S}" validatePeriodically="%{idp.pool.LDAP.validatePeriodically:true}" validateTimerPeriod="%{idp.pool.LDAP.validatePeriod:PT5M}" expirationTime="%{idp.pool.LDAP.idleTime:PT10M}" /> </DataConnector> <DataConnector id="staticAttributes" xsi:type="Static" exportAttributes="o schacHomeOrganization"> <!-- Der Name Ihrer Einrichtung wird hier statisch für alle Accounts gesetzt. --> <Attribute id="o"> <Value>Beispiel-Hochschule</Value> </Attribute> <!-- Die Domain Ihrer Einrichtung wird hier statisch gesetzt, entspricht i.d.R. dem Scope --> <Attribute id="schacHomeOrganization"> <Value>uni-beispiel.de</Value> </Attribute> </DataConnector> </AttributeResolver>
Laden Sie das Servlet neu, um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):
root@idp:~# touch /opt/shibboleth-idp/war/idp.war
Die zentrale Konfigurationsdatei für die Freigabe von Attributen an Service Provider ist ./conf/attribute-filter.xml. Unsere Beispieldatei regelt, welche Attribute an unsere öffentlichen Test-SPs freigegeben werden. Für den späteren Produktivbetrieb beachten Sie bitte die vertiefende Dokumentation.
(Ein Klick auf den Dateinamen startet den Download)
<?xml version="1.0" encoding="UTF-8"?> <AttributeFilterPolicyGroup id="ShibbolethFilterPolicy" xmlns="urn:mace:shibboleth:2.0:afp" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:afp http://shibboleth.net/schema/idp/shibboleth-afp.xsd"> <!-- Verlässlichkeitsinformationen sind nicht personenbeziehbar und sollten grundsätzlich an jeden SP übertragen werden --> <AttributeFilterPolicy id="ReleaseAssuranceToAnyone"> <PolicyRequirementRule xsi:type="ANY" /> <AttributeRule attributeID="eduPersonAssurance" permitAny="true" /> </AttributeFilterPolicy> <!-- Attribute an die DFN-Test-SPs freigeben --> <AttributeFilterPolicy id="dfn_test_sps"> <PolicyRequirementRule xsi:type="OR"> <!-- Als Requester wird die jeweilige EntityID des Service Providers angegeben. --> <Rule xsi:type="Requester" value="https://testsp2.aai.dfn.de/shibboleth" /> <Rule xsi:type="Requester" value="https://testsp3.aai.dfn.de/shibboleth" /> </PolicyRequirementRule> <!-- Liste der Attribute, die an den/die Requester übermittelt werden dürfen. --> <AttributeRule attributeID="uid" permitAny="true"/> <AttributeRule attributeID="eduPersonPrincipalName" permitAny="true"/> <AttributeRule attributeID="mail" permitAny="true"/> <AttributeRule attributeID="sn" permitAny="true"/> <AttributeRule attributeID="givenName" permitAny="true"/> </AttributeFilterPolicy> </AttributeFilterPolicyGroup>
Laden Sie wieder die Konfiguration neu:
root@idp:~# touch /opt/shibboleth-idp/war/idp.war
Bitte testen Sie jetzt die Attribute-Freigabe gegen unsere Test-SPs, siehe hierzu unter Funktionstest.
Erst wenn diese Tests erfolgreich sind und Sie die Attribute uid, eduPersonPrincipalName, mail, sn und givenName angezeigt bekommen, sollten Sie mit der IdP-Konfiguration weiter machen!
Sie können den Resolvertest im Browser aufrufen. Ersetzen Sie den Anfang entsprechend Ihres Identity Providers:
https://<IHR-IDP>/idp/profile/admin/resolvertest?principal=test-clt&requester=https://testsp3.aai.dfn.de/shibboleth # Rückgabe: { "requester": "https://testsp3.aai.dfn.de/shibboleth", "principal": "test-clt", "attributes": [ { "name": "eduPersonEntitlement", "values": [ "urn:mace:dir:entitlement:common-lib-terms" ] }, { "name": "eduPersonScopedAffiliation", "values": [ "member@testscope.aai.dfn.de" ] } ] }
Alternativ können Sie das Kommandozeilenwerkzeug aacli verwenden, um die Attributfreigabe zu testen: Geben Sie mit -n den Principal/die User ID an und mit -r den Requester/den SP, der die simulierte Anfrage stellt:
root@idp:~# /opt/shibboleth-idp/bin/aacli.sh -n test-clt -r https://testsp3.aai.dfn.de/shibboleth (http://localhost/idp/profile/admin/resolvertest?requester=https%3A%2F%2Ftestsp3.aai.dfn.de%2Fshibboleth&principal=test-clt) http://localhost/idp/profile/admin/resolvertest?requester=https%3A%2F%2Ftestsp3.aai.dfn.de%2Fshibboleth&principal=test-clt
Die aacli-Dokumentation finden Sie im Shibboleth-Wiki.