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
de:shibidp3troubleshoot [2016/07/04 14:59]
Petra Berg
de:shibidp3troubleshoot [2019/07/31 15:59] (aktuell)
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 properties /​opt/​shibboleth-idp/​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>​
  
-===== JPAStorage mit PostgreSQL ​===== +===== opensaml::​SecurityPolicyException ​=====
-Ohne zusätzliche Konfiguration (ORM Workaround),​ wie beschrieben von den Schweizer Kollegen [[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.+
  
 +"​opensaml::​SecurityPolicyException Message was signed, but signature could not be verified."​
  
-Um die korrekte Funktion sicher ​zu stellen, **muss obiger Workaround dringend angewendet werden**+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.
  
-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.+===== 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: 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: +DB als postgres Nutzer öffnen, da die Daten in der Systemtabelle ''​pg_largeobject'' ​ liegen:<​code>​ 
-  psql -Upostgres shibboleth +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:​ 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:​
-  ​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>​ 
-  +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: Jetzt anhand der values die ID's durch deren Inhalte aus der neuen Tabelle ersetzen:
-  ​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: ​  +shibboleth=>​ update storagerecords set value = new_table.new_value from new_table where storagerecords.value = new_table.value;​ 
-  shibboleth=>​ drop table new_table;​ +</​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. Danach den IdP (tomcat) neu starten. Die Session und Attribute-Constent Daten sind weiterhin (wieder) verfügbar.
 +
  
  • Zuletzt geändert: vor 3 Jahren