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:38] wolfgangde:shibidp3troubleshoot [2019/07/31 15:59] Silke Meyer
Zeile 1: Zeile 1:
-======Troubleshooting======+====== Troubleshooting ====== 
   * Shibboleth Wiki: [[https://wiki.shibboleth.net/confluence/display/IDP30/Troubleshooting|Seite]] ist im Aufbau begriffen   * Shibboleth Wiki: [[https://wiki.shibboleth.net/confluence/display/IDP30/Troubleshooting|Seite]] ist im Aufbau begriffen
   * 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]].   * 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]].
Zeile 5: Zeile 6:
  
 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 xml /opt/shibboleth-idp/system/conf/global-system.xml+ 
-<!-- ... --> +<file properties /opt/shibboleth-idp/conf/idp.properties
-<property name="builderAttributes"> +... 
-  <map> +idp.xml.securityManager=org.apache.xerces.util.SecurityManager 
-    <!-- Sun/Oracle is the default, for Xerces, set property to org.apache.xerces.util.SecurityManager --> +...
-    <entry key="http://apache.org/xml/properties/security-manager"> +
-    <!-- orginal +
-      <bean class="%{idp.xml.securityManager:com.sun.org.apache.xerces.internal.util.SecurityManager}" /> +
-    --> +
-      <bean class="org.apache.xerces.util.SecurityManager" /> +
-    </entry> +
-  </map> +
-</property>+
 </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.
 +
 +