| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| de:shibidp:troubleshooting [2023/01/12 17:45] – [IdP wird vom Discovery Service nicht angezeigt] Wolfgang Pempe | de:shibidp:troubleshooting [2023/06/07 11:02] (aktuell) – [Problem mit Scripted Attributes] Link zum Plugin ergänzt Silke Meyer |
|---|
| * Beim Eintragen von Werten in ''.properties''-Dateien vermeiden Sie bitte Leerzeichen am Zeilenende! Ein Blank hinter einem Passwort macht dieses ungültig! Beim LDAP-Fehler ''Invalid Credentials'' stellen Sie bitte sicher, dass Sie **bei den Zugangsdaten keine Leerzeichen an den Zeilenenden** stehen haben. Das Passwort steht //nicht// in Hochkommata oder Anführungszeichen. | * Beim Eintragen von Werten in ''.properties''-Dateien vermeiden Sie bitte Leerzeichen am Zeilenende! Ein Blank hinter einem Passwort macht dieses ungültig! Beim LDAP-Fehler ''Invalid Credentials'' stellen Sie bitte sicher, dass Sie **bei den Zugangsdaten keine Leerzeichen an den Zeilenenden** stehen haben. Das Passwort steht //nicht// in Hochkommata oder Anführungszeichen. |
| * Achten Sie auf Präzision bei der Konfiguration, etwa bei der **Schreibweise von Entity IDs**. Entity IDs mit und ohne **Schrägstrich am Ende** des URL (trailing slash) sind zwei verschiedene Entity IDs! | * Achten Sie auf Präzision bei der Konfiguration, etwa bei der **Schreibweise von Entity IDs**. Entity IDs mit und ohne **Schrägstrich am Ende** des URL (trailing slash) sind zwei verschiedene Entity IDs! |
| | |
| | ===== Der IdP schreibt keine Logs ===== |
| | |
| | Wenn Ihr IdP gar keine Logfiles nach ''/opt/shibboleth-idp/logs/'' (oder in ein von Ihnen eingestelltes abweichendes Verzeichnis) schreibt, dann schauen Sie bitte die Logdateien des Tomcat an. Auf Debian-Systemen finden Sie in ''/var/log/tomcat9'' verschiedene Dateien. Beobachten Sie //alle//, etwa mit <code bash>root@idp:~# tail -f /var/log/tomcat9/*.log</code> und starten Sie in einem anderen Terminalfenster den Tomcat neu. |
| |
| ===== Welche Attribute und Attribut-Werte werden an einen SP übertragen? ===== | ===== Welche Attribute und Attribut-Werte werden an einen SP übertragen? ===== |
| Um die komplette SAML-Assertion einzusehen, setzen Sie - wie oben beschrieben - das Loglevel für idp, messages und encryption auf DEBUG. Im idp-process.log sehen Sie dann die Assertion. Suchen Sie nach **"Assertion before encryption"**. In dieser SAML Assertion sehen Sie, dass die persistentId mit dem Wert "NMTR6SVZOCUWF5MNGDDIYQQBY4QCB76N" und die Attribute ''eduPersonScopedAffiliation'' (mit drei Werten) und ''eduPersonEntitlement'' (mit einem Wert) von dem IdP mit der EntityId https://idp.local/idp/shibboleth and den SP mit der EntityId https://sp1.local/shibboleth übertragen wurden: | Um die komplette SAML-Assertion einzusehen, setzen Sie - wie oben beschrieben - das Loglevel für idp, messages und encryption auf DEBUG. Im idp-process.log sehen Sie dann die Assertion. Suchen Sie nach **"Assertion before encryption"**. In dieser SAML Assertion sehen Sie, dass die persistentId mit dem Wert "NMTR6SVZOCUWF5MNGDDIYQQBY4QCB76N" und die Attribute ''eduPersonScopedAffiliation'' (mit drei Werten) und ''eduPersonEntitlement'' (mit einem Wert) von dem IdP mit der EntityId https://idp.local/idp/shibboleth and den SP mit der EntityId https://sp1.local/shibboleth übertragen wurden: |
| |
| <file xml /opt/shibboleth-idp/logs> | <file xml /opt/shibboleth-idp/logs/idp-process.log> |
| 2020-10-27 14:54:07,079 - 127.0.0.2 - DEBUG [org.opensaml.saml.saml2.encryption.Encrypter:339] - Assertion before encryption: | 2020-10-27 14:54:07,079 - 127.0.0.2 - DEBUG [org.opensaml.saml.saml2.encryption.Encrypter:339] - Assertion before encryption: |
| <?xml version="1.0" encoding="UTF-8"?><saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_3a89275f3cd179685b22a3cf616c518a" IssueInstant="2020-10-27T13:54:06.179Z" Version="2.0"> | <?xml version="1.0" encoding="UTF-8"?><saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_3a89275f3cd179685b22a3cf616c518a" IssueInstant="2020-10-27T13:54:06.179Z" Version="2.0"> |
| * Prüfen Sie, woher der IdP die Metadaten kennen müsste: | * Prüfen Sie, woher der IdP die Metadaten kennen müsste: |
| * aus den Föderationsmetadaten? | * aus den Föderationsmetadaten? |
| * aus den lokalen Metadaten Ihrer Einrichtung? (Ist der SP als lokaler SP bei Ihnen in der Metadatenverwaltung eingetragen?) | * aus den [[de:metadata_local|lokalen Metadaten]] Ihrer Einrichtung? (Ist der SP als lokaler SP bei Ihnen in der Metadatenverwaltung eingetragen?) |
| * aus einem manuell hinzugefügten xml-Metadatensatz, der in ''./conf/metadata-providers.xml'' eingebunden ist? Prüfen Sie den Inhalt der Datei. | * aus einem manuell hinzugefügten xml-Metadatensatz, der in ''./conf/metadata-providers.xml'' eingebunden ist? Prüfen Sie den Inhalt beider Dateien. |
| * Bedenken Sie bei den ersten beiden, dass Sie nach Änderungen in der Metadatenverwaltung 60-90 Minuten warten müssen, bis die neuen Metadaten aggregiert und verteilt sind. | * Bedenken Sie bei den ersten beiden, dass Sie nach Änderungen in der Metadatenverwaltung 60-90 Minuten warten müssen, bis die neuen Metadaten aggregiert und verteilt sind. |
| |
| Ein Service Provider kann über seinen Metadatensatz bekannt geben, dass er die Authentication Requests an einen Identity Provider signiert und/oder dass er gerne signierte SAML Assertions zurückbekommen möchte. Unsere Metadatenverwaltung kann beides nur anzeigen, wenn es bereits beim Einlesen der xml-Datei vorhanden ist. Erweitern Sie die SP-Metadaten dazu bei ''md:SPSSODescriptor'' wie folgt:<code xml><md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"></code> | Ein Service Provider kann über seinen Metadatensatz bekannt geben, dass er die Authentication Requests an einen Identity Provider signiert und/oder dass er gerne signierte SAML Assertions zurückbekommen möchte. Unsere Metadatenverwaltung kann beides nur anzeigen, wenn es bereits beim Einlesen der xml-Datei vorhanden ist. Erweitern Sie die SP-Metadaten dazu bei ''md:SPSSODescriptor'' wie folgt:<code xml><md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"></code> |
| | |
| | ===== Problem mit Scripted Attributes ===== |
| | Wenn die ScriptedAttributes aus Ihrer ''conf/attribute-resolver.xml''-Datei nicht mehr ausgeführt werden und Sie die Fehlermeldung "No scripting engine associated with scripting language javascript" bekommen, dann haben Sie wahrscheinlich auf Java 17 (bzw. JDK 15 oder höher) aktualisiert. Die Scripting Engine "Nashorn", mit der Javascript ausgeführt werden kann, muss in dem Fall über ein [[https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1374027996/Nashorn|IdP-Plugin]] ergänzt werden: Ab der IdP-Version 4.2 können Sie das direkt mit folgendem Befehl tun:<code bash>root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -I net.shibboleth.idp.plugin.nashorn</code> |
| | Weder eine Konfiguration noch das Aktivieren eines Modules sind nötig. |
| | |
| ===== JPAStorage mit PostgreSQL ===== | ===== JPAStorage mit PostgreSQL ===== |
| |