Shibboleth

Admin

=Identity Provider IdP3=

Vorbereiten
root@idp:~# apt-get install ntp openjdk-8-jdk root@idp:~# update-alternatives --config java

Wählen Sie OpenJDK-8 aus oder deinstallieren Sie die anderen Java-Versionen.

Java Cryptography Extension (JCE) installiert?
Bei Verwendung von OpenJDK (Debian/Ubuntu) ist alles nötige enthalten! Bei anderen Systemen muss u.U. nachgearbeitet werden.

apt-get install oracle-java8-unlimited-jce-policy

Tomcat
root@idp:~# apt-get install tomcat8

Hinweis: Sofern Sie tomat8 aus Debian-Backports verwenden (nicht unbedingt nötig) brauchen Sie auch das Paket 'libservlet3.1-java' um den IdP betreiben zu können.

Java-Konfiguration
Einige globale Java-Parameter müssen beim Tomcat-Start festgelegt werden. Das IdP-Servlet benötigt mehr Speicher, als gemäß den Voreinstellungen vorgesehen ist und Zugriff auf das Filesystem:

# den Tomcat mit genug Speicher starten: JAVA_OPTS="-Djava.awt.headless=true -XX:+UseConcMarkSweepGC -Xms1024m -Xmx2048m    # Zugriff auf das File-System:    TOMCAT8_SECURITY=no
 * 1) /etc/default/tomcat8

Port-Konfigurtion
In der Tomcat-Configuration wird dann
 * aus Sicherheitsgründen der Default-Port 8080 abgeschaltet
 * auf Port 8009 der AJP-Connector aktiviert über den der vorgelagerte Webserver Anfragen an Tomcat weiterleitet.

    
 * 1) /etc/tomcat8/server.xml

Um das IdP-Servlet im Tomcat zu aktivieren, erstellen Sie folgende Datei im Tomcat-localhost-Context:


 * 1) /etc/tomcat8/Catalina/localhost/idp.xml

IdP-Sessions gehen bei einem Tomcat-Neustart in jedem Fall verloren. Daher macht es keinen Sinn (bzw. führt nur zu unnötigen IdP-Fehlermeldungen) wenn alte Sessions bei einen Tomcat-Neustart weiter existieren. Deaktivieren Sie daher dieses Tomcat-Feature:

  WEB-INF/web.xml ${catalina.base}/conf/web.xml  
 * 1) /etc/tomcat8/context.xml

Java Server Tag Library (JSTL)
Als letztes muss noch die Java Server Tag Library heruntergeladen und in das Tomcat-Verzeichnis $CATALINA_BASE/lib gelegt werden (unter Debian/Unbuntu ist das /var/lib/tomcat8/lib, bei anderen Distributionen bitte entsprechend anpassen):

root@idp:~# wget https://build.shibboleth.net/nexus/service/local/repositories/thirdparty/content/javax/servlet/jstl/1.2/jstl-1.2.jar \ -O /var/lib/tomcat8/lib/jstl-1.2.jar

HTTP-Server
root@idp:~# apt-get install apache2

Module aktivieren:

root@idp:~# a2enmod ssl root@idp:~# a2enmod headers root@idp:~# a2enmod proxy_ajp

VirtualHosts
# # # # # # # # # #  ServerName             idp.uni-beispiel.de  SSLEngine on  SSLCertificateFile      /etc/ssl/localcerts/idp.uni-beispiel.crt.pem SSLCertificateKeyFile  /etc/ssl/private/idp.uni-beispiel.key.pem SSLCACertificateFile   /etc/ssl/chains/uni-beispiel-chain.pem AddDefaultCharset UTF-8  Require all granted ProxyPass ajp://localhost:8009/idp # "SAMEORIGIN" vermeidet etwaige Fehlermeldungen # im Browser beim Logout über mehrere SPs, # da hierbei mit iframes gearbeitet wird Header always append X-FRAME-OPTIONS "SAMEORIGIN" </Location> # Support für favicon.ico, robots.txt und ggfs. Info-Seiten DocumentRoot /opt/shibboleth-idp/htdocs <Directory /opt/shibboleth-idp/htdocs> Require all granted </Directory> </VirtualHost> # # # # Listen IDP-IP-ADRESSE:8443 Listen [IDP-IPv6-ADRESSE]:8443 <VirtualHost IDP-IP-ADRESSE:8443 [IDP-IPv6-ADRESSE]:8443> ServerName             idp.uni-beispiel.de  SSLEngine on  SSLCertificateFile      /etc/ssl/localcerts/idp.uni-beispiel.crt.pem SSLCertificateKeyFile  /etc/ssl/private/idp.uni-beispiel.key.pem SSLCACertificateFile   /etc/ssl/chains/uni-beispiel-chain.pem # hier muss wegen veralteten SP-Clients (z.B. Thomson Reuters) # eine etwas weniger strikte Konfiguration genommen werden # als von bettercrypto.org empfohlen wird: SSLCipherSuite 'EECDH+ECDSA+AESGCM+AES128:AES128:EECDH+ECDSA+AESGCM+AES256:AES256:!aNULL:!eNULL:!PSK:!SRP:!DH' # Diese drei SSL-Optionen sind zwingend notwendig # damit SP-Abfragen auf diesen Port funktionieren! # Details siehe Shibboleth-Wiki SSLVerifyClient      optional_no_ca SSLVerifyDepth       10 SSLOptions           +StdEnvVars +ExportCertData <Location /idp> Require all granted ProxyPass ajp://localhost:8009/idp </Location> </VirtualHost>
 * 1) /etc/apache2/sites-enabled/idp.uni-beispiel.de.conf
 * 1) Bitte im Folgenden 'IDP-IP-ADRESSE' und ggf. 'IDP-IPv6-ADRESSE'
 * 2) jeweils durch die entsprechende IP und 'idp.uni-beispiel.de' durch
 * 3) den FQDN Ihres IdPs ersetzen!
 * 1) Die Angabe der Portnummer bei 'ServerName' ist wichtig falls
 * 2) für den SSO auf Port 443 ein anderes Zertifikat verwendet werden
 * 3) soll als für die Attribute Authority auf Port 8443
 * 1) SingleSignOnService
 * 1) https://idp.uni-beispiel.de/idp/profile/SAML2/POST/SSO
 * 2) https://idp.uni-beispiel.de/idp/profile/SAML2/Redirect/SSO
 * 3) https://idp.uni-beispiel.de/idp/profile/Shibboleth/SSO
 * 1) Sofern der Port 443 nicht von der Distribution angeschaltet wird
 * 2) (bei Debian in /etc/apache2/ports.conf, bei openSUSE in /etc/apache2/listen.conf)
 * 3) können Sie das hier manuell machen:
 * 1) Listen 443
 * 1) SingleSignOnService auf Port 443
 * 1) ArtifactResolutionService und AttributeService
 * 1) https://idp.beispiel-uni.de:8443/idp/profile/SAML2/SOAP/ArtifactResolution
 * 2) https://idp.beispiel-uni.de:8443/idp/profile/SAML1/SOAP/ArtifactResolution
 * 1) https://idp.beispiel-uni.de:8443/idp/profile/SAML2/SOAP/AttributeQuery
 * 2) https://idp.beispiel-uni.de:8443/idp/profile/SAML1/SOAP/AttributeQuery

IdP herunterladen
Shib IdP herunterladen, Signatur überprüfen und entpacken. Die aktuelle IdP-Version findet sich stets unter http://shibboleth.net/downloads/identity-provider/latest/ root@idp-dev:~# mkdir /opt/install root@idp-dev:~# cd /opt/install root@idp-dev:/opt/install# wget https://shibboleth.net/downloads/identity-provider/latest/shibboleth-identity-provider-3.3.1.tar.gz root@idp-dev:/opt/install# wget https://shibboleth.net/downloads/identity-provider/latest/shibboleth-identity-provider-3.3.1.tar.gz.asc root@idp-dev:/opt/install# wget https://shibboleth.net/downloads/PGP_KEYS root@idp-dev:/opt/install# gpg --import PGP_KEYS root@idp-dev:/opt/install# gpg --verify shibboleth-identity-provider-3.3.1.tar.gz.asc shibboleth-identity-provider-3.3.1.tar.gz root@idp-dev:/opt/install# tar -xzf shibboleth-identity-provider-3.3.1.tar.gz

IdP installieren
root@idp-dev:~# cd /opt/install/shibboleth-identity-provider-3.3.1 Das Installationsskript findet sich unter bin/install.sh. Beim Ausführen werden die wichtigsten Angaben zum IdP abgefragt, wie der FQDN und das Zielverzeichnis, in das der IdP installiert werden soll. Der Default hierfür ist /opt/shibboleth-idp. Falls abweichend, muss der Pfad z.B. als idp.home Parameter beim Tomcat-Start angegeben werden, Details siehe Dokumentation im Shibboleth Wiki.

Im Gegensatz zum IdP 2.x werden alle Anpassungen (IdP-Layout oder Einstellungen in der web.xml) lokal im Installationsverzeichnis gemacht und danach das build.sh-Script aufgerufen um das WAR-File zu aktualisieren. Das Sourceverzeichnis /opt/install/shibboleth-identity-provider-3.3.0 wird also nach der Installation nicht mehr gebraucht.

root@idp-dev:/opt/install/shibboleth-identity-provider-3.3.1# JAVA_HOME=/usr bin/install.sh Source (Distribution) Directory (press to accept default: [/opt/install/shibboleth-identity-provider-3.3.0] Installation Directory: [/opt/shibboleth-idp] Hostname: [idp-dev.hochschule-XY.de] SAML EntityID:  Attribute Scope: [hochschule-XY.de] Backchannel PKCS12 Password:  Re-enter password:  Cookie Encryption Key Password:  Re-enter password: Warning: /opt/shibboleth-idp/bin does not exist. Warning: /opt/shibboleth-idp/dist does not exist. Warning: /opt/shibboleth-idp/doc does not exist. Warning: /opt/shibboleth-idp/system does not exist. Warning: /opt/shibboleth-idp/webapp does not exist. Generating Signing Key, CN = idp-dev.hochschule-XY.de URI = https://idp-dev.hochschule-XY.de/idp/shibboleth ... ...done Creating Encryption Key, CN = idp-dev.hochschule-XY.de URI = https://idp-dev.hochschule-XY.de/idp/shibboleth ... ...done Creating Backchannel keystore, CN = idp-dev.hochschule-XY.de URI = https://idp-dev.hochschule-XY.de/idp/shibboleth ... ...done Creating cookie encryption key files... ...done Rebuilding /opt/shibboleth-idp/war/idp.war ... ...done BUILD SUCCESSFUL Total time: 1 minute 12 seconds

Die beiden abgefragten Passwörter werden in die IdP-Config geschrieben, müssen also nicht notiert oder gemerkt werden. Wählen Sie daher möglichst starke Passwörter (12 Zeichen aus Ziffern, Gross- und Klein-Buchstaben). Der IdP wird dann im angegebenen Zielverzeichnis installiert.

Nachdem die IdP-Files installiert sind, versucht der Tomcat das Servlet automatisch zu starten (siehe Tomcat-Log). Das scheitert überlicherweise aber erstmal da einige Dateien für den Tomcat-User nicht lesbar abgelegt wurden. Korrigieren Sie dies mit:

root@idp-dev:/opt/install/shibboleth-identity-provider-3.3.1# cd /opt/shibboleth-idp root@idp-dev:/opt/shibboleth-idp# chgrp -R tomcat8 conf credentials root@idp-dev:/opt/shibboleth-idp# chmod -R g+r conf credentials

Ausserdem müssen Log-Verzeichnis und Metadata-Verzeichnis für den Tomcat-User schreibbar gemacht werden:

root@idp-dev:/opt/shibboleth-idp# chown tomcat8:tomcat8 logs metadata

IdP Status URL
Zur Darstellung der Status-Seite muss


 * die Java Server Tag Library (JSTL) im Tomcat bereit stehen (siehe Vorarbeiten).
 * die IdP Status URL für Ihr eigenes Netz und das Monitoring-Netz des DFN freigegeben werden:


 * 1) /opt/shibboleth-idp/conf/access-control.xml

<beans ...> <util:map id="shibboleth.AccessControlPolicies"> <entry key="AccessByIPAddress"> <bean parent="shibboleth.IPRangeAccessControl" p:allowedRanges="#{ {'127.0.0.1/32', '::1/128', 'IHR-NETZ/IHRE-NM', '193.174.247.0/24', '2001:638:206:1::/64'} }" /> </util:map>

Jetzt kann Tomcat neu gestartet werden: root@idp-dev:/opt/shibboleth-idp# systemctl restart tomcat8

Dabei lassen Sie am besten in drei Terminalfenstern den Tomcat- und die beiden relevanten IdP-Logs mitlaufen:

root@idp-dev:/opt/shibboleth-idp# tail -f /var/log/tomcat8/catalina.out

root@idp-dev:/opt/shibboleth-idp# tail -f logs/idp-process.log

root@idp-dev:/opt/shibboleth-idp# tail -f logs/idp-warn.log

Finden sich dort keine Fehler ist der IdP erfolgreich gestartet. Überprüfen Sie als erstes ob sie die Status-Seite sehen können:

https://idp-dev.hochschule-XY.de/idp/status

Vorbereitung Metadaten
...       <Extensions> <shibmd:Scope regexp="false">hochschule-XY.de</shibmd:Scope> <mdui:UIInfo> <mdui:DisplayName xml:lang="en">XY University (Development)</mdui:DisplayName> <mdui:DisplayName xml:lang="de">Hochschule XY (Development)</mdui:DisplayName> <mdui:Description xml:lang="en">Identity Provider of XY University</mdui:Description> <mdui:Description xml:lang="de">Identity Provider der Hochschule XY</mdui:Description> <mdui:Logo height="16" width="16">https://idp-dev.hochschule-XY.de/favicon.ico</mdui:Logo> <mdui:Logo height="80" width="80">https://idp-dev.hochschule-XY.de/idp/images/logo.png</mdui:Logo> </mdui:UIInfo> </Extensions> ...       <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="..."/> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="..."/> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="..."/> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="..."/> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="..."/> <SingleSignOnService Binding="urn:mace:...       <SingleSignOnService Binding="urn:oasis:...        <SingleSignOnService Binding="urn:oasis:...        <SingleSignOnService Binding="urn:oasis:... <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.hochschule-XY.de/idp/profile/SAML2/SOAP/ECP"/> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat> ...   </IDPSSODescriptor> <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> ...       <AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="..."/> <AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="..."/> <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat> </AttributeAuthorityDescriptor> </EntityDescriptor>
 * 1) ./metadata/idp-metadata.xml

Föderationsmetadaten
<?xml version="1.0" encoding="UTF-8"?> <MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata" xmlns:resource="urn:mace:shibboleth:2.0:resource" xmlns:security="urn:mace:shibboleth:2.0:security" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd           urn:mace:shibboleth:2.0:resource http://shibboleth.net/schema/idp/shibboleth-resource.xsd            urn:mace:shibboleth:2.0:security http://shibboleth.net/schema/idp/shibboleth-security.xsd            urn:oasis:names:tc:SAML:2.0:metadata http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd"> <MetadataProvider id="DFN_AAI_Test" xsi:type="FileBackedHTTPMetadataProvider" backingFile="%{idp.home}/metadata/DFN-AAI-Test-metadata.xml" metadataURL="http://www.aai.dfn.de/fileadmin/metadata/dfn-aai-test-metadata.xml" maxRefreshDelay="PT2H"> <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true" certificateFile="/etc/ssl/aai/dfn-aai.g2.pem"/> <MetadataFilter xsi:type="EntityRoleWhiteList"> <RetainedRole>md:SPSSODescriptor</RetainedRole> </MetadataFilter> </MetadataProvider> <MetadataProvider id="DFN_AAI" xsi:type="FileBackedHTTPMetadataProvider" backingFile="%{idp.home}/metadata/DFN-AAI-sp-metadata.xml" metadataURL="http://www.aai.dfn.de/fileadmin/metadata/dfn-aai-sp-metadata.xml" maxRefreshDelay="PT2H"> <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true" certificateFile="/etc/ssl/aai/dfn-aai.g2.pem"/> </MetadataProvider> </MetadataProvider>
 * 1) ./conf/metadata-providers.xml

Logging
Das Default-Logging sollte in folgenden Punkte angepasst werden:


 * Loghistory aus Datenschutzgründen nur 14 Tage aufbewahren
 * LDAP-Client-Log von WARN auf INFO damit mehr LDAP-Meldungen kommen
 * Client-IP-Adresse im Log mit protokollieren zur Vorbereitung der Brute-Force-Abwehr

...   <variable name="idp.loghistory" value="14" /> <variable name=idp.loglevel.idp" value="INFO" />   <variable name="idp.loglevel.ldap" value="INFO" />    ...    <appender name="IDP_PROCESS" class="...        <File>...        <rollingPolicy class="...           <fileNamePattern>...           <maxHistory>...        </rollingPolicy>        <encoder class="...            ... <Pattern>%date{ISO8601} - %level [%logger:%line] - IP:%mdc{idp.remote_addr:-n/a} - %msg%n%ex{short}</Pattern>
 * 1) ./conf/logback.xml

Anbindung IdM (LDAP/AD)
Bei einem Login-Vorgang des Users am IdP macht der IdP im Hintergrund zwei LDAP-Abfragen:
 * Authentisierung des Users
 * Abruf der Attribute des Users

Diese beiden Schritte werden in ldap.properties unabhängig voneinander konfiguriert:

# bitte entsprechend den Möglichkeiten Ihres IdM-Systems anpassen, im Beispiel # eine Konfiguration wie Sie für OpenLDAP und auch Active Directory funktionieren kann: idp.authn.LDAP.authenticator                   = bindSearchAuthenticator idp.authn.LDAP.ldapURL                         = ldaps://ldap.hochschule-XY:636 idp.authn.LDAP.useStartTLS                     = false idp.authn.LDAP.useSSL                          = true idp.authn.LDAP.sslConfig                       = certificateTrust #   # Pfad zum Root-Zertifikat der verwendeten PKI, dieser sollte folgendermassen überprüft werden # bevor er im IdP konfiguriert wird (Beispiel für DFN-PKI): #   #  openssl s_client -connect ldap.uni-beispiel.de:ldaps -showcerts \ #             -CAfile /etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem #   # Wichtig ist dass der Hostnamen des LDAP/AD-Servers im Zertifikat eingetragen ist, oder anders herum, # dass der LDAP/AD-Server unter dem Zertifikatsnamen erreichbar ist. Sollte dies aus irgend welchen # Gründen nicht der Fall sein, kann die Zertifikatsüberprüfung mit folgender Konfiguration doch noch # erfolgreich gemacht werden: #   # * zu den JAVA-Start-Optionen von Tomcat hinzufügen: "-Djdk.tls.trustNameService=true" # * in /etc/hosts den Zertifikatsnamen mit der IP des LDAP/AD-Server verknüpfen: #   #     192.168.0.13 ldap1.hochschule-XY.intra #   # 'alte' DFN-PKI-Hierarchie: idp.authn.LDAP.trustCertificates               = /etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem # 'neue' DFN-PKI-Hierarchie: #idp.authn.LDAP.trustCertificates               = /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem #   # sofern während der Auth-Phase festgestellt werden  soll, ob der Account aktiv ist, müssen # hier die entsprechenden Attribute angegeben werden # (FIXME: konkretes Beispiel für OpenLDAP und AD heraussuchen) idp.authn.LDAP.returnAttributes                = passwordExpirationTime,loginGraceRemaining #   # LDAP-Verbindungsparameter, diese sollten folgendermassen überprüft werden bevor Sie im IdP # konfiguriert werden: #   #  ldapsearch -H ldaps://ldap.hochschule-XY.de \ #            -b "ou=people,dc=hochschule-XY=de" \ #            -D cn=idp,cn=systemusers,dc=hochschule-XY,dc=de \ #            -x -w 'geheim007' \ #            uid=irgendeinExistierenderUser #   idp.authn.LDAP.baseDN                           = ou=people,dc=hochschule-XY,dc=de # statt "(uid={user})" nehmen Sie bei AD üblicherweise "(cn={user})" oder "(sAMAccountName={user})" idp.authn.LDAP.userFilter                      = (uid={user}) idp.authn.LDAP.bindDN                          = cn=idp,cn=systemusers,dc=hochschule-XY,dc=de idp.authn.LDAP.bindDNCredential                = geheim007 # sofern die User im LDAP in Sub-Bäumen verteilt sind bitte das hier aktivieren: #idp.authn.LDAP.subtreeSearch                   = true
 * 1) /opt/shibboleth-idp/conf/ldap.properties

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp-dev:/opt/shibboleth-idp# systemctl restart tomcat8

Bevor Sie weiter machen müssen Sie unbedingt die LDAP-Verbindung testen!
 * tragen Sie Ihren idP in der Metadatenverwaltung ein
 * warten Sie 90 min bis der neue Eintrag auf den DFN-Testsystemen angekommen ist
 * machen Sie mithilfe unserer Test-SPs einen ersten Login-Versuch, siehe https://www.aai.dfn.de/teilnahme/funktionstest/.

Es werden Ihnen jetzt noch keine Attribute angezeigt, was aber nicht weiter tragisch ist.

Sollten Sie nicht erfolgreich zum SP zurückgeleitet werden, achten Sie darauf, von welchem System die Fehlermeldung im Browser generiert wird. Entsteht die Fehlermeldung am IdP, schauen Sie bitte in idp-process.log nach, was die Ursache ist. Generiert unser Test-SP die Fehlermeldung, schauen Sie bitte im Online-Log https://testsp2.aai.dfn.de/ShibLogViewer2/SPLogViewer.html des SP. Mithilfe dieser Meldung und des Shib-Wiki unter https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTroubleshootingCommonErrors sollten Sie in den meisten Fällen die Ursache bestimmen können. Sollten Sie damit nicht weiterkommen, senden Sie uns bitte einen Screenshot der Fehlermeldung und den genauen Zeitpunkt, zu dem der Fehler aufgetreten ist, damit wir mithilfe unseres SP-Logs die Ursache bestimmen können.

Konfiguration Attribut-Generierung und -Freigabe
Erzeugung und Freigabe der SAML-Attribute wird weiterhin über die Dateien attribute-resolver.xml und attribute-filter.xml gesteuert. Diese unterscheiden sich syntaktisch und semantisch leicht von den gewohnten Dateien im IdP 2.x.

Mit den folgenden beiden Konfigurationsdateien sollte ein erster Test gegen die DFN-Test-SPs schnell gelingen: Minimal-attribute-resolver.xml Laden Sie unsere Beispieldatei herunter und legen Sie diese nach ./conf/attribute-resolver.xml

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# systemctl restart tomcat8

Attribute-Test mithilfe der Test-SPs in der DFN-AAI-Test

Bitte testen Sie jetzt die Attribute-Freigabe gegen unsere Test-SPs, siehe dazu https://www.aai.dfn.de/teilnahme/funktionstest/

Erst wenn diese Tests erfolgreich sind und Sie die Attribute 'uid', 'eduPersonPrincipalName', 'mail', 'surname' und 'givenName' angezeigt bekommen, sollten Sie mit der IdP-Konfiguration weiter machen! Optional: Attribute-Test mithilfe aacli

Mit dem Resolvertest (aacli) besteht die Möglichkeit, die Attributfreigabe für eine(n) bestimmte(n) Nutzer(in) gegenüber einem bestimmten SP zu testen. Der Aufruf von bin/aacli.sh generiert einen URL, der dann z.B. im Browser eingegeben werden kann (auch hier Zugriffskontrolle über conf/access-control.xml):

root@idp# ./aacli.sh -n test-clt -r https://testsp3.aai.dfn.de/shibboleth

(-n principal = user id; -r requester = entityId des anfragenden SP)

Zertifikate
Sofern Sie erfolgreich Attribute übertragen konnten sollten Sie jetzt als nächstes auf DFN-PKI-Zertifikate wechseln.

Die bei der Installation erzeugten Private Keys und zugehörigen selbst-signierten Zertifikate müssen für den späteren Produktionsbetrieb gegen DFN-PKI-Zertifikate ausgetauscht werden. Wir empfehlen die Verwendung der selben Key- und Zertifikats-Files, die bereits für den Webserver verwendet werden, damit das Key-Handling nicht zu unübersichtlich wird.

Unter Debian/Ubuntu liegen diese Files typischerweise unter /etc/ssl:

idp.signing.key= /etc/ssl/private/idp-dev.uni-beispiel.de.key.pem idp.signing.cert= /etc/ssl/localcerts/idp-dev.uni-beispiel.de.crt.pem idp.encryption.key= /etc/ssl/private/idp-dev.uni-beispiel.de.key.pem idp.encryption.cert= /etc/ssl/localcerts/idp-dev.uni-beispiel.de.crt.pem
 * 1) /opt/shibboleth-idp/conf/idp.properties
 * 2) Settings for public/private signing and encryption key(s)
 * 3) During decryption key rollover, point the ".2" properties at a second
 * 4) keypair, uncomment in credentials.xml, then publish it in your metadata.
 * 1) keypair, uncomment in credentials.xml, then publish it in your metadata.
 * 1) idp.encryption.key.2 = /etc/ssl/private/idp-dev.uni-beispiel.de.key.pem.old
 * 2) idp.encryption.cert.2 = /etc/ssl/localcerts/idp-dev.uni-beispiel.de.crt.pem.old


 * das Format der Zert-Datei muss PEM sein, DER funktioniert nicht!
 * in den PEM-Dateien dürfen keine Kommentare enthalten, sie müssen in der ersten Zeile mit „—–BEGIN“ anfangen
 * in den PEM-Dateien dürfen am Ende der Zeilen keine Blanks oder andere unsichtbare Zeichen sein
 * die private-key-Datei darf nicht mit einer Passphrase verschlüsselt sein!

Bitte darauf achten, dass die PEM-Dateien vom Tomcat-User gelesen werden dürfen

Damit der IdP (der im Tomcat und damit mit den Berechtigungen des Tomcat-Users läuft) Zugriff auf die Dateien unterhalb von /etc/ssl/private bekommt muss er (unter Debian und Ubuntu) in die Gruppe 'ssl-cert' aufgenommen werden:

root@idp:~# usermod -aG ssl-cert tomcat8

Wichtig:


 * Denken Sie daran, das neue Zertifikat in der DFN-AAI-Metadatenverwaltung einzutragen. Dort sind zunächst die bei der Installation generierten selbst-signierten Zertifikate eingetragen worden. Am besten löschen Sie dort alle (sechs!) Zertifikatsinstanzen und tragen danach das neue Zertifikat nur noch zweimal ein: einmal im Abschnitt „IdP Single Sign On Descriptor“ und einmal im Abschnitt „Attribute Authority Descriptor“. In beiden Fällen lassen Sie dabei das Feld „Verwendungszweck“ leer. Dieses wird nur für Spezialfälle gebraucht.
 * Warten Sie dann zwei Stunden bis die neuen Zertifkate in die DFN-AAI-Test-Metadaten aufgenommen worden sind und testen Sie nochmal die Attribut-Freigaben mithilfe der DFN-Test-SPs!
 * Die Datei./metadata/idp-metadata.xml enthält nach wie vor die selbst-signierten Zertifikate, die bei der Installation automatisch generiert wurden. Diese Datei wird nicht automatisch aktualisiert. Allerdings ist das kein Problem, als sie für den Betrieb des IdP nicht erforderlich ist, sondern lediglich als Hilfsmittel zur initialen Registrierung des IdP in einer Föderation gedacht ist. Wir empfehlen diese Datei „in Ruhe“ zu lassen.

Einrichtungs-Logo
Legen Sie das Logo Ihrer Einrichtung nach

./edit-webapp/images/logo.png

Erzeugen Sie das IdP-WAR-File neu (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# JAVA_HOME=/usr ./bin/build.sh

Weiterführende Hinweise:


 * alle IdP-Seiten können über die Templates in ./views/ angepasst
 * Für Fortgeschrittene: Die Kolleg(inn)en von SWITCHaai bieten einige vorgefertigte Templates und Stylesheets an, die sich mit geringem Aufwand den eigenen Bedürfnissen anpassen lassen. Mehr dazu in der Anleitung von SWITCH.

favicon.ico und robots.txt

 * spendieren Sie dem IdP das gleiche Web-Iconwie der Einrichtungs-Home-Page
 * vermeiden Sie Zugriffsfehler am IdP durch Suchmaschinen

root@idp:/opt/shibboleth-idp# mkdir htdocs root@idp:/opt/shibboleth-idp# wget http://www.beispiel-uni.de/favicon.ico -O ./htdocs/favicon.ico root@idp:/opt/shibboleth-idp# echo -e 'User-agent: *\nDisallow: /idp/profile/' > ./htdocs/robots.txt

Sofern die Apache-Vhost-Config unserem Vorschlag unter HTTP-Server entspricht sollten jetzt beide Dateien aktiv sein. Logos in der Metadatenverwaltung

Damit das Logo und das favicon.ico auf in diversen Auswahllisten und Info-Seiten automatisch verwendet werden sollten Sie diese in der DFN-AAI-Metadatenverwaltung eintragen, als Beispiel der Eintrag für den DFN-Development-IdP, bitte durch Ihren IdP-Hostnamen ersetzten:

Testen Sie nochmal einen Login mithilfe der DFN-Test-SP(s) und überzeugen Sie sich dass die Layout-Anpassungen wirksam geworden sind.

Nutzungsbedingungen (Terms of Use)
Diese können, sofern relevant (bitte mit den Kollegen von der Rechtsabteilung bzw. Datenschutz klären) in zwei Schritten aktiviert werden:

Erstens modifizieren Sie:


 * 1) ./conf/intercept/consent-intercept-config.xml

...   <bean id="shibboleth.consent.terms-of-use.Key" class="com.google.common.base.Functions" factory-method="constant"> <constructor-arg value="my-terms"/> <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty"> <property name="profileConfigurations"> <bean parent="Shibboleth.SSO" p:postAuthenticationFlows="#{ {'terms-of-use', 'attribute-release'} }" /> <bean parent="SAML2.SSO" p:postAuthenticationFlows="#{ {'terms-of-use', 'attribute-release'} }" /> <ref bean="...

Um die Nutzungsbedingungen auch nach dem ersten Mal noch einsehen zu können gibt es einen Link im Footer der IdP-Seiten. Damit dieser Link funktioniert legen Sie bitte folgende Datei an:

./edit-webapp/tou.jsp <%@ page pageEncoding="UTF-8" %> <%@ taglib uri="http://www.springframework.org/tags" prefix="spring" %> <!DOCTYPE html> <meta charset="utf-8"> <spring:message code="root.title" text="Shibboleth IdP" /> - <spring:message code="my-tou.title" text="Terms of Use" /> <link rel="stylesheet" type="text/css" href="<%= request.getContextPath%>/css/consent.css"> <a href="<spring:message code="idp.logo.target.url" />" target="_blank"> <img src="<%= request.getContextPath %><spring:message code="idp.logo" />" alt="<spring:message code="idp.logo.alt-text" text="logo" />"> </a> <spring:message code="my-tou.text" text="Terms of Use" /> <p class="footer-text"> &copy; <spring:message code="idp.logo.alt-text" /> <spring:message code="idp.url.copyyear" /> | <a title="Impressum" href="<spring:message code="idp.url.imprint" />" target="_blank"> Impressum </a> und erzeugen danach das IdP-War file neu (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# JAVA_HOME=/usr ./bin/build.sh

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# service tomcat8 restart

Benutzer-Einwilligung zur Attributfreigabe (User Consent)
Damit auf der dynamisch generierten Seite, auf der die Informationen zum Attribute Release dargestellt werden, der OrganizationDisplayName des Service Providers angezeigt wird (standardmäßig ist es der OrganizationName, der im Fall der DFN-AAI Metadaten nur ein Kürzel ist), muss in /views/intercept/attribute-release.vm die Definition im oberen Teil der Datei angepasst werden:

#set ($rpOrganizationName = $rpUIContext.organizationDisplayName)
 * 1) /opt/shibboleth-idp/views/intercept/attribute-release.vm

Standardmäßig werden die Entscheidungen der/des Nutzerin/Nutzers clientseitig als Cookies gespeichert, was für den initialen Test-Betrieb ausreichend ist.

Server-Side-Storage und Persistent Identifier
Per default werden Informationen zu User Consent (ehemals uApprove) und Persistent IDs client-seitig in Cookies abgelegt. Dies kann aber nur als initiale „Notlösung“ betrachtet werden, damit der IdP auch ohne angeschlossene SQL-Datenbank funktioniert. In einem fertigen Produktivszenario ist das Abspeichern dieser Informationen auf Serverseite unbedingt zu empfehlen, da nur damit erweiterte SAML-Funktionalitäten möglich sind (z.B. persistentId, Single-Logout). Installation Datenbanksoftware

MySQL
root@idp:~# apt-get install mysql-server mysql-client libmysql-java

Damit der Tomcat die MySQL-Java-Library beim Starten einliest (d.h. der IdP sie dann verwenden kann), wird diese üblicherweise in /etc/tomcat8/catalina.properties in den „common.loader“ aufgenommen. Dies hat den Nachteil, dass diese Datei dann bei jedem Upgrade manuell mit einer neuen catalina.properties verglichen werden muss. Man kann sich die Arbeit ersparen (sofern man dort nicht sowieso Anpassungen machen muss, was beim Einsatz des IdPs als einziges Servlet im Tomcat aber nicht nötig sein sollte!), indem man die mysql-Datei in das Runtime-Lib-Verzeichnis von Tomcat verlinkt. Dort wird sie dann automatisch eingelesen:

root@idp:~# ln -s /usr/share/java/mysql.jar /var/lib/tomcat8/lib/mysql.jar

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:~# service tomcat8 restart

Datenbank-Konfiguration
Zunächst ist eine logische Datenbank zu erstellen. Hierzu müssen, wie vom IdP 2.x gewohnt, zunächst nur die Tabellen für die Angaben zur Persistent Id angelegt werden, die Tabelle „StorageRecords“ (u.a. für die User Consent Informationen) wird automatisch generiert.

Hier ein Beispiel für MySQL, wobei hier vorausschauend auch gleich eine Tabelle für die persistentId angelegt wird, welche später noch gebraucht wird (siehe später in dieser Anleitung):

mysql> SET NAMES 'utf8'; SET CHARACTER SET utf8; CHARSET utf8; CREATE DATABASE IF NOT EXISTS shibboleth CHARACTER SET=utf8; USE shibboleth; mysql> CREATE TABLE IF NOT EXISTS shibpid (   localEntity VARCHAR(255) NOT NULL,    peerEntity VARCHAR(255) NOT NULL,    persistentId VARCHAR(50) NOT NULL,    principalName VARCHAR(50) NOT NULL,    localId VARCHAR(50) NOT NULL,    peerProvidedId VARCHAR(50) NULL,    creationDate TIMESTAMP NOT NULL,    deactivationDate TIMESTAMP NULL,    PRIMARY KEY (localEntity, peerEntity, persistentId) ); mysql> CREATE USER 'shibboleth'@'localhost' IDENTIFIED BY 'GeHEIM007'; mysql> GRANT ALL PRIVILEGES ON shibboleth.* TO 'shibboleth'@'localhost'; mysql> FLUSH PRIVILEGES;

Der DB-Zugriff wird über den JPAStorageService gekapselt. Dieser wird in ./conf/global.xml definiert. Diese Datei ist im Auslieferungszustand leer (bis auf Kommentare). Ersetzen Sie sie durch die hier bereitgestellte Version.

Starten Sie Tomcat neu, um sicherzustellen, dass die global.xml ohne Probleme eingelesen werden kann (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# service tomcat8 restart

Hinweis: bei älteren Java Versionen führt der Parameter „p:validationQueryTimeout“ zu einer Fehlermeldung, in dem Fall einfach weglassen und Tomcat neu starten.

Die Properties für den DB-Zugriff werden jetzt noch in idp.properties ergänzt (bitte auf die Tomcat-Version achten!):


 * 1) /opt/shibboleth-idp/conf/idp.properties

# Tomcat7 #mysql.class  = org.apache.commons.dbcp.BasicDataSource # Tomcat8 mysql.class   = org.apache.tomcat.jdbc.pool.DataSource mysql.url     = jdbc:mysql://localhost:3306/shibboleth mysql.username = shibboleth mysql.password = GeHEIM007

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# service tomcat8 restart

PersistentId Konfiguration
Die persistentId wird in drei Schritten aktiviert:

Erstens wird festgelegt, wie die Id generiert und abgelegt werden soll:


 * 1) /opt/shibboleth-idp/conf/saml-nameid.properties

# ein Attribut aus attribute-resolver.xml als unique Identifier, dabei wird hier der Wert der "id" # dieses Attributes aus attribute-resolver.xml referenziert und _nicht_ der Attribut-Name aus dem IdM! # in den allermeisten Fällen wird das immer 'uid' sein, auch bei Microsoft AD (dort dient das IdM-   # Attribut 'sAMAccountName' bzw. neuerdings 'cn' als Quelle fur das IdP-Attribut 'uid') idp.persistentId.sourceAttribute = uid #idp.persistentId.useUnfilteredAttributes = true # Do *NOT* share the salt with other people, it's like divulging your private key. #idp.persistentId.algorithm = SHA idp.persistentId.salt = MöglichstBeliebigUndGeHeim-mindestens-16bytes # To use a database, use shibboleth.StoredPersistentIdGenerator idp.persistentId.generator = shibboleth.StoredPersistentIdGenerator # For basic use, set this to a JDBC DataSource bean name: idp.persistentId.dataSource = shibboleth.MySQLDataSource

Hinweise zur Wahl des Quellatributs:


 * Als Quellattribut aus dem IdM für die persistentId muss man ein IdM-Attribut nehmen, welches auch über die Zeit für alle Benutzer eindeutig ist. Oft ist dies das IdM-Attribut 'uid' (oder bei AD 'sAMAccountName' bzw. neuerdings 'cn'). Sollte dies bei Ihnen nicht der Fall sein, d.h. diese Attribute werden für neue User recycled (auch aus anderen Gründen nicht zu empfehlen!), dann muss ein anderes IdM-Attribut gefunden werden.
 * Eine Möglichkeit, dieses Problem zu umgehen, besteht darin, sich ein neues Attribut in attribute-resolver.xml zu definieren. Dieses Attribut könnte zum Beispiel aus einem Hash aus uid und dem Anlegedatum des Accounts bestehen.
 * Beispiele zur Generierung finden Sie unter Persistent ID - Sonderfälle.

Zweitens wird die Java-Bean für die Generierung aktiviert indem der Eintrag für shibboleth.SAML2PersistentGenerator ent-kommentieren wird:


 * 1) /opt/shibboleth-idp/conf/saml-nameid.xml

<beans ...> <util:list id="shibboleth.SAML2NameIDGenerators"> </util:list>

Drittens wird die Verarbeitung der Id aktiviert:


 * 1) /opt/shibboleth-idp/conf/c14n/subject-c14n.xml

<beans ...> <util:list id="shibboleth.SAMLSubjectCanonicalizationFlows"> </util:list>

Viertens: meist sind Usernamen im IdM-System unabhängig von Gross- und Kleinschreibung. D.h. die User können Ihren Loginnamen sowohl in Gross- als auch Kleinschreibung angeben und damit einen erfolgreichen Login durchführen. Allerdings führt dieses später zu Problemen beim Verwalten der Usernamen in der lokalen IdP-Datenbank da diese Gross- und Kleinschreibung unterscheidet. Wir empfehlen daher den Usernamen in diesen Fällen im IdP in Kleinbuchstaben umzuwandeln:


 * 1) ./conf/c14n/simple-subject-c14n-config.xml

...      <util:constant id="shibboleth.c14n.simple.Lowercase" static-field="java.lang.Boolean.TRUE"/> ...

Damit werden die Usernamen vom IdP nur noch in Kleinbuchstabenform verarbeitet und in die Datenbank geschrieben.

Session-Informationen und User Consent in DB ablegen
Nachdem Datenbankverbindung und persistentId aktiviert sind, können diese nun für die Speicherung von Session- und User Consent-Informationen genutzt werden. Dadurch wird als netter Nebeneffekt auch SingleLogout- Unterstützung im IdP ermöglicht:

...   # Set to "shibboleth.StorageService" for server-side storage of user sessions idp.session.StorageService = shibboleth.JPAStorageService # Set to "shibboleth.StorageService" or custom bean for alternate storage of consent idp.consent.StorageService = shibboleth.JPAStorageService # Set to "shibboleth.consent.AttributeConsentStorageKey" to use an attribute # to key user consent storage records (and set the attribute name) idp.consent.userStorageKey = shibboleth.consent.AttributeConsentStorageKey idp.consent.userStorageKeyAttribute = %{idp.persistentId.sourceAttribute} # Flags controlling how built-in attribute consent feature operates #idp.consent.allowDoNotRemember = true # damit der User für jeden SP mindestens einmal einwilligen muß sollte # die Möglichkeit für eine globale Einwilligung abgeschaltet werden: idp.consent.allowGlobal = false #idp.consent.allowPerAttribute = false # Damit auch bei neuem Wert eines Attributes und bei neuem Terms-Of-Use-Text der # User erneut abnicken muss. Da jetzt statt Browser-Cookies eine lokale DB zur # Verfügung steht sollte dieses sinnvolle Feature aktiviert werden! idp.consent.compareValues = true
 * 1) /opt/shibboleth-idp/conf/idp.properties

Starten Sie Tomcat neu, um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# service tomcat8 restart

Weitergabe der Persistent ID
Um die persistentId für alle SPs freizugeben muss die SAML2.SSO-Bean-Definition erweitert werden:


 * 1) /conf/relying-party.xml

<beans ...> <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty"> <property name="profileConfigurations"> <bean parent="SAML2.SSO" p:postAuthenticationFlows="#" p:nameIDFormatPrecedence="#"/>

Starten Sie Tomcat neu, um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# service tomcat8 restart

Testen Sie nochmals einen Login mithilfe der DFN-Test-SP(s) und überzeugen Sie sich, dass die persistentId übertragen wird.

Single Logout
Da wir im vorherigen Schritt das Speichern von Session-Informationen so umgestellt haben dass eine lokale SQL-Datenbank verwendet wird, kann nun auch SLO im IdP aktiviert werden:


 * 1) /opt/shibboleth-idp/conf/idp.properties

# Track information about SPs logged into idp.session.trackSPSessions = true # Support lookup by SP for SAML logout idp.session.secondaryServiceIndex = true # damit der User eine ausführliche Logout-Rückmeldung vom IdP bekommt: # Whether to lookup metadata, etc. for every SP involved in a logout # for use by user interface logic; adds overhead so off by default. idp.logout.elaboration = true

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:~# service tomcat8 restart

Die Logout-Seite enthält eine Bemerkung der Shibboleth-Entwickler dass die Seite angepasst werden soll. Diese Bemerkung sollte ersetzt oder zumindest deaktiviert werden. Löschen Sie die entsprechenden Zeilen oder kommentieren Sie diese aus wie folgt aus (oder ersetzen Sie den Text durch einen eigenen sofern Sie Ihren Usern an dieser Stelle etwas mitteilen möchten):


 * 1) ./views/logout.vm

#if ( $logoutContext and !$logoutContext.getSessionMap.isEmpty )

Diese Änderung wird ohne Neustart wirksam.

Testen Sie den Logout mithilfe des DFN-Test-SP2. Nach dem Login finden Sie unterhalb der Attribute den „Logout“-Link welcher Sie zum IdP zurückleiten sollte. Dort sollte dann die Erfolgsmeldung für den Logout angezeigt werden.

Achtung: Sollte trotz vermeintlich richtiger Konfiguration das Logout nicht funktionieren bitte in der Apache-Konfiguration prüfen, dass die richtige X-FRAME-OPTION „SAMEORIGIN“ gesetzt ist, siehe auch HTTP Server.

Secret Key Management
Der IdP sichert Cookies und andere flüchtige Daten per Verschlüsselung. Die bei dieser Verschlüsselung zur Anwendung kommenden Schlüssel (Keys) sollten aus Sicherheitsgründen regelmäßig erneuert werden.

Laden Sie das Beispiel-Script herunter und legen es nach

/opt/shibboleth-idp/bin/update-sealer.sh

Vergessen Sie nicht das Script ausführbar zu machen:

root@idp:~# chmod 755 /opt/shibboleth-idp/bin/update-sealer.sh

Dieses Script liest die Sealer-relevanten Einstellungen aus ./conf/idp-properties und erzeugt damit neue Schlüsselwerte. Dazu legen Sie am besten einen täglichen Cron-Job an:

01 01 * * * root /opt/shibboleth-idp/bin/update-sealer.sh >/dev/null
 * 1) /etc/cron.d/shibboleth-idp

Hinweis: falls Sie bei der IdP-Installation am Anfang ein zu einfaches Sealer-Passwort vergeben haben können Sie dieses problemlos ändern indem Sie die Dateien ./credentials/sealer.* löschen und in ./conf/idp.properties neue Passwörter (idp.sealer.storePassword und idp.sealer.keyPassword) vergeben. Danach rufen Sie einfach obigen Cron-Job manuell auf, das Script erstellt die fehlenden Dateien unter Verwendung der neuen Passwörter wieder neu. Achten Sie nur darauf dass Sie beim Passwort keine Sonderzeichen verwenden da diese erfahrungsgemäß in Java-properties-Dateien Probleme machen können.

Referenz zum Shib-Wiki: https://wiki.shibboleth.net/confluence/display/IDP30/SecretKeyManagement Aufnahme in DFN-AAI-Produktivumgebung

Die Basis-Konfiguration des IdPs ist damit abgeschlossen. Jetzt können Sie den IdP über die Metadatenverwaltung in die Produktivumgebung der DFN-AAI aufnehmen lassen indem Sie


 * auf der „Edit“-Seite des IdP in der letzten Tabelle („Föderationen“) den Produktivbetrieb anklicken.
 * das Kästchen bei „DFN-AAI-Test“ entfernen. Prinzipiell könnte der IdP weiter in der DFN-AAI-test bleiben, wir empfehlen aber stattdessen ein dauerhaftes Entwicklungs-System zu erstellen und dieses dauerhaft in der DFN-AAI-Test zu belassen. Dieses System sollte identisch zum Produktivsystem sein (also auch auf das gleiche IdM-System zugreifen) damit Sie dort Configurations- und Versions-Änderungen testen können bevor Sie diese auf dem Produktiven vornehmen.
 * warten bis von uns die Rückmeldung kommt dass Ihr IdP produktiv geschaltet wurde.

=Service Provider=