Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Nächste ÜberarbeitungBeide Seiten der Revision
de:shibidp3troubleshoot [2015/07/30 11:41] wolfgangde:shibidp3troubleshoot [2019/08/29 17:30] Silke Meyer
Zeile 1: Zeile 1:
-======Troubleshooting====== +~~NOTOC~~ 
-  * Shibboleth Wiki: [[https://wiki.shibboleth.net/confluence/display/IDP30/Troubleshooting|Seite]] ist im Aufbau begriffen +====== Troubleshooting ====== 
-  * Loglevel hochsetzen und Appender definieren in conf/logback.xml (wird alle 5 Minuten neu geladen), siehe auch im Shibboleth Wiki unter [[https://wiki.shibboleth.net/confluence/display/IDP30/LoggingConfiguration|LoggingConfiguration]] und [[https://wiki.shibboleth.net/confluence/display/IDP30/AdvancedLogging|AdvancedLogging]]. +{{INLINETOC 2}} 
-  * Werte in Property Files: Trailing Space Characters (Blank) unbedingt vermeiden. Ein Blank hinter einem Passwort macht dieses ungültig!+ 
 +===== Links ===== 
 + 
 +  * [[https://wiki.shibboleth.net/confluence/display/IDP30/Troubleshooting|Troubleshooting-Seite]] im Shibboleth Wiki 
 + 
 +===== Grundsätzliche Vorgehensweise bei der Fehlersuche ===== 
 +  * Beobachten Sie die fortlaufenden Logdateien ''idp-process.log'' (Standardpfad: ''/opt/shibboleth-idp/logs/'') und das Tomcat-Log. 
 +  * Setzen Sie das Loglevel auf DEBUG hoch. Warnungen und Fehler bekommen Sie auch so zu sehen, aber z.B. die Inhalte der übertragenen SAML-Assertions nicht. In vielen Fällen reicht es, dies für idp, ldap und opensaml zu tun:<file properties /opt/shibboleth-idp/conf/logback.xml> 
 +    <variable name="idp.loglevel.idp" value="DEBUG" /> 
 +    <variable name="idp.loglevel.ldap" value="DEBUG" /> 
 +    <variable name="idp.loglevel.messages" value="INFO" /> 
 +    <variable name="idp.loglevel.encryption" value="INFO" /> 
 +    <variable name="idp.loglevel.opensaml" value="DEBUG" /> 
 +</file> 
 +  * Stoßen Sie das Neuladen des Servlets manuell an (''touch /opt/shibboleth-idp/war/idp.war'') oder warten Sie bis zum automatischen Reload der Logging-Konfiguration. Die Reload-Intervalle sind in ''/opt/shibboleth-idp/conf/services.properties'' konfigurierbar. Für die ''conf/logback.xml'' sind standardmäßig 5 Minuten eingestellt. 
 +  * Wenn Sie im idp-process.log Warnungen oder Fehler sehen, **lesen Sie das Log von oben nach unten ab dem letzten IdP-Neustart**. Dies ist wichtig, denn die ersten Fehlermeldungen benennen häufig Gründe (z.B. Syntaxfehler in Konfigurationsdateien mit Zeile o.ä.), während die letzten Fehler oft Folgefehler sind, die immer gleich aussehen. Ein Beispiel für einen solchen Folgefehler:<code>'shibboleth.metrics.RegisterMetricSets$child#0' defined in file [C:\Program Files (x86)\shibboleth\idp\system\conf\..\..\conf\admin\metrics.xml]: Cannot resolve reference to bean 'shibboleth.metrics.AttributeResolverGaugeSet' while setting bean property 'arguments' with key [7]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.metrics.AttributeResolverGaugeSet' defined in file [C:\Program Files (x86)\shibboleth\idp\system\conf\general-admin-system.xml]: Invocation of init method failed; nested exception is net.shibboleth.utilities.java.support.component.ComponentInitializationException: Injected service was null or not an AttributeResolver</code>Scrollen Sie hoch und suchen Sie nach Fehlern beim Laden der Datei ''conf/attribute-resolver.xml''
 +  * Appender definieren in conf/logback.xml (wird alle 5 Minuten neu geladen), siehe auch im Shibboleth Wiki unter [[https://wiki.shibboleth.net/confluence/display/IDP30/LoggingConfiguration|LoggingConfiguration]] und [[https://wiki.shibboleth.net/confluence/display/IDP30/AdvancedLogging|AdvancedLogging]]. 
 +  * 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.
  
 Bei Java-Installationen, die nicht aus dem Sun/Oracle-Kontext stammen, muss ggf. eine alternative Xerces Bean Class konfiguriert werden: Bei Java-Installationen, die nicht aus dem Sun/Oracle-Kontext stammen, muss ggf. eine alternative Xerces Bean Class konfiguriert werden:
-<file properties /opt/shibboleth-idp/system/conf/idp.properties> + 
-# ... +<file properties /opt/shibboleth-idp/conf/idp.properties> 
 +# ...
 idp.xml.securityManager=org.apache.xerces.util.SecurityManager idp.xml.securityManager=org.apache.xerces.util.SecurityManager
 # ... # ...
 </file> </file>
 +
 +===== opensaml::SecurityPolicyException =====
 +
 +"opensaml::SecurityPolicyException Message was signed, but signature could not be verified."
 +
 +Diese Fehlermeldung erscheint, wenn das Zertifikat, das Sie beim IdP in der Metadatenverwaltung publiziert haben, nicht mit dem Zertifikat übereinstimmt, das am IdP für die SAML-Kommunikation verwendet wird. Bei der IdP-Installation wird automatisch ein selbstsigniertes Zertifikat generiert und in ''conf/idp.properties'' vorkonfiguriert. Dort müssen Sie die Pfadangaben zu Ihrem PKI-Zertifikat einstellen.
 +
 +Übrigens: Die Datei ''metadata/idp-metadata.xml'' wird ebenfalls automatisch angelegt und mit den initialen Metadaten des IdP befüllt. In der DFN-AAI wird diese Datei aber ignoriert. Was dort drinsteht, ist also irrelevant. Für den IdP "gelten" die Metadaten, die Sie in der Verwaltung einpflegen und aktuell halten.
 +
 +===== JPAStorage mit PostgreSQL =====
 +
 +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 PostgeSQL die Werte als 'large Objects' in der Systemtabelle und schreibt in die Spalte 'value' nur die Link ID.
 +
 +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.
 +
 +