Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp:troubleshooting [2022/05/24 10:19] – [Metadaten des eigenen IdP/SP herunterladen] Screenshot MD-Download in neuer MDV Silke Meyer
+++ de:shibidp:troubleshooting [2024/09/17 08:00] (aktuell) – veraltete Info zu Postgres & JPA Storage entfernt Doreen Liebenau
@@ Zeile 7: / Zeile 7: @@
 ===== Metadaten des eigenen IdP/SP herunterladen =====
-Um den aktuell in der Föderation publizierten xml-Metadatensatz Ihres IdP oder SP herunterzuladen, melden Sie sich an der Metadatenverwaltung an. In der Übersicht wählen Sie den entsprechenden Eintrag aus und klicken - wie hier gezeigt - auf das blaue "XML". Die Metadaten werden Ihnen im Browser angezeigt, so dass Sie sie sich herauskopieren und speichern können.
+Um den aktuell in der Föderation publizierten xml-Metadatensatz Ihres IdP oder SP herunterzuladen, melden Sie sich an der Metadatenverwaltung an. In der Übersicht wählen Sie den entsprechenden Eintrag aus und klicken rechts unter Aktionen auf das Download-Symbol.
-**aktuelle/alte Metadatenverwaltung:**\\
-{{:de:aai:ll9.png?800|}}
-**zukünftige/neue Metadatenverwaltung:**\\
 {{:de:metadata_admin_tool:metadaten-runterladen-de.png?800|}}
 ===== Grundsätzliche Vorgehensweise bei der Fehlersuche =====
@@ Zeile 29: / Zeile 25: @@
   * 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!
+===== 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? =====
@@ Zeile 34: / Zeile 34: @@
 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>
 -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">
@@ Zeile 103: / Zeile 103: @@
   * Prüfen Sie, woher der IdP die Metadaten kennen müsste:
     * 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.
@@ Zeile 148: / Zeile 148: @@
 <code bash>java.lang.IllegalArgumentException: {urn:oasis:names:tc:SAML:2.0:assertion}NameID is
 already the child of another XMLObject and may not be inserted into this list</code>
+===== IdP/SP ist nicht mehr in den eduGAIN Metadaten =====
+Die vom DFN-Verein herausgegebenen Metadatensätze mit den eduGAIN-Entitäten haben noch nie die Entitäten aus der DFN-AAI enthalten. Wir filtern sie heraus, weil Ihre Systeme sie ja bereits aus den DFN-AAI-Metadaten kennen und wir keine Doubletten verteilen möchten. Sie prüfen, ob eine Entität in eduGAIN ist, suchen Sie sie bitte in der [[https://technical.edugain.org/entities|eduGAIN Entities Database]].
 ===== IdP wird vom Discovery Service nicht angezeigt =====
@@ Zeile 154: / Zeile 159: @@
   * **Der SP hat die aktuellsten Metadaten noch nicht geholt**. Warten Sie bei den DFN-AAI-Föderationen (auch DFN-AAI-Test) 60-90 Minuten, bei eduGAIN 24 Stunden, bevor Sie testen. Sie können vorab prüfen, ob Ihr IdP schon in den eduGAIN-Metadaten angekommen ist: https://technical.edugain.org/entities
-  * Sie haben in der Metadatenverwaltung das Häkchen bei "hide from recovery" gesetzt. Entfernen Sie das Häkchen und warten Sie 60-90 Minuten.
+  * Sie haben in der Metadatenverwaltung das Häkchen bei "hide from discovery" gesetzt. Entfernen Sie das Häkchen und warten Sie 60-90 Minuten.
-  * Der SP ist nur für IdPs der Verlässlichkeitsklasse Advanced ("DFN-AAI") verfügbar, Ihr Identity Management System ist aber der Verlässlichkeitsklasse Basic ("DFN-AAI-Basic") zugeordnet. Lesen Sie unter [[de:degrees_of_reliance| Verlässlichkeitsklassen]] nach, unter welchen Bedingungen bestimmte Nutzer*innen Ihrer Einrichtung trotzdem auf den SP zugreifen können, solange Ihr IdM nicht komplett den Anforderungen der Verlässlichkeitsklasse Advanced entspricht.
 ===== SP-Metadaten: AuthnRequestsSigned und WantAssertionsSigned =====
@@ Zeile 161: / Zeile 165: @@
 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>
-===== JPAStorage mit PostgreSQL =====
+===== 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>
-Ohne zusätzliche Konfiguration (ORM Workaround), wie beschrieben von den Schweizer Kollegen [[https://www.switch.ch/aai/guides/idp/installation/#ormxmlworkaround|https://www.switch.ch/aai/guides/idp/installation/#ormxmlworkaround]] speichert PostgreSQL die Werte als 'large Objects' in der Systemtabelle und schreibt in die Spalte 'value' nur die Link ID.
+Weder eine Konfiguration noch das Aktivieren eines Modules sind nötig.
-Um die korrekte Funktion sicher zu stellen, **muss obiger Workaround dringend angewendet werden**.
-Leider sind hinterher die Daten der Datenbank nicht mehr kompatibel. D.h. vor dem Neustart des IdP müssen die Werte der Spalte ''value''  in der Tabelle ''storagerecords''  konvertiert werden.
-Eine Möglichkeit geht wie folgt direkt auf der schon vorhandenen Datenbank:
-DB als postgres Nutzer öffnen, da die Daten in der Systemtabelle ''pg_largeobject''  liegen:<code>
-psql -Upostgres shibboleth
-</code>
-Temporär werden die Werte decodiert mit den ID's in eine neue Tabelle geschrieben. Diese neue Tabelle gehört postgres, daher evtl. danach den Owner aktualisieren:
-<code>
-shibboleth=> create table new_table as (select context, id, value, encode(data, 'escape') as new_value from storagerecords left join pg_largeobject on oid(value) = loid);
-shibboleth=> alter table new_table owner to shibboleth;
-</code>
-Jetzt anhand der values die ID's durch deren Inhalte aus der neuen Tabelle ersetzen:
-<code>
-shibboleth=> update storagerecords set value = new_table.new_value from new_table where storagerecords.value = new_table.value;
-</code>
-Die Temporäre Tabelle wieder löschen:
-<code>
-shibboleth=> drop table new_table;
-</code>
-Danach den IdP (tomcat) neu starten. Die Session und Attribute-Constent Daten sind weiterhin (wieder) verfügbar.
-{{tag>idp4 troubleshooting debugging debug logging mdvdoku}}
+{{tag> troubleshooting debugging debug logging }}

troubleshooting debugging debug logging