Vertrauenswürdige Zertifikat-Einträge sind nicht Passwort-geschützt Frühling SAML
Habe ich generiert testIdp.cer-Datei durch kopieren 509-Eintrag der IDP ich bin Planung zu verbinden. Dann erstellte ich JKS-Datei durch Ausführung des folgenden Befehls
keytool -importcert -alias adfssigning -keystore C:\Users\user\Desktop\samlKeystore.jks -file C:\Users\user\Desktop\testIdp.cer
Ausgeführt, wenn Sie es hat Sie gebeten, ein Passwort einzugeben, für die ich mit einem Passwort versehen. Für die Frage "Vertrauen Sie diesem Zertifikat? [keine]:" ich habe gegeben "y" als Eingabe. Meldung kam wie "Certificate was added to keystore".
Dann habe ich Folgendes konfiguriert details securityContext.xml
<bean id="keyManager" class="org.springframework.security.saml.key.JKSKeyManager">
<constructor-arg value="classpath:security/samlKeystore.jks"/>
<constructor-arg type="java.lang.String" value="mypassword"/>
<constructor-arg>
<map>
<entry key="adfssigning" value="mypassword"/>
</map>
</constructor-arg>
<constructor-arg type="java.lang.String" value="adfssigning"/>
</bean>
<bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
<property name="alias" value="adfssigning" />
<property name="signingKey" value="adfssigning"/>
</bean>
Aber wenn ich die Anwendung ausführen möchte, bekomme ich folgende zwei Ausnahmen, wenn der server gestartet und wenn ich laden Sie die homepage der Anwendung. Kann jemand lassen Sie mich wissen, wenn ich bin fehlt etwas anderes.
Diese Ausnahme auftreten, wenn ich den server starten
Caused by: org.opensaml.saml2.metadata.provider.FilterException: Signature trust establishment failed for metadata entry
at org.opensaml.saml2.metadata.provider.SignatureValidationFilter.verifySignature(SignatureValidationFilter.java:327)
at org.opensaml.saml2.metadata.provider.SignatureValidationFilter.processEntityGroup(SignatureValidationFilter.java:240)
at org.opensaml.saml2.metadata.provider.SignatureValidationFilter.doFilter(SignatureValidationFilter.java:158)
at org.opensaml.saml2.metadata.provider.AbstractMetadataProvider.filterMetadata(AbstractMetadataProvider.java:493)
at org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider.processNonExpiredMetadata(AbstractReloadingMetadataProvider.java:395)
Diese Ausnahme auftreten, wenn ich die Startseite meiner Anwendung
java.lang.UnsupportedOperationException: trusted certificate entries are not password-protected
at java.security.KeyStoreSpi.engineGetEntry(Unknown Source)
at java.security.KeyStore.getEntry(Unknown Source)
at org.opensaml.xml.security.credential.KeyStoreCredentialResolver.resolveFromSource(KeyStoreCredentialResolver.java:132)
InformationsquelleAutor SM KUMAR | 2014-10-02
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ihre
.cer
Zertifikat enthält nur einen öffentlichen Schlüssel, darf man Sie nicht definieren<entry key="adfssigning" value="mypassword"/>
für öffentliche Schlüssel; es kann nur verwendet werden, für die privaten. Nehmen Sie einfach dieadfssigning
Eintrag und stellen Sie sicher, dass Sie einen privaten Schlüssel, anstatt - gerade wie im Frühjahr SAML-Beispiel-Anwendung.Den SAML-keystore enthalten kann zwei grundlegende Typen von Schlüsseln: einen öffentlichen und einen privaten (sowie deren Zertifikate). Jede Taste hat einen alias, die verwendet wird, zu verweisen. Der keystore selbst kann durch ein Kennwort geschützt (im zweiten parameter des Konstruktors), plus jeder private Schlüssel kann auch durch ein zusätzliches Passwort geschützt (diese sind definiert in Dritter parameter des Konstruktors in einer Karte von alias->Passwort). Die öffentlichen Schlüssel, die Sie importieren, um den keystore (genauso wie Sie es mit dem Befehl oben) darf nicht definiert werden in dieser Karte. Sie werden automatisch zur Verfügung, nachdem Sie importiert ohne weitere Erklärungen. Für das Frühjahr SAML funktioniert, muss der Schlüsselspeicher muss mindestens einen privaten Schlüssel (die Beispielanwendung enthält die privaten Schlüssel mit dem alias apollo) und Ihrem alias werden muss (in der Dritte parameter des Konstruktors.
Ihre obigen Beispiel versagt, weil Sie importiert haben einen öffentlichen Schlüssel, sondern gehörten in die Karte, die ausschließlich für den privaten Schlüssel.
Willst du damit sagen, dass nalle123 zugeordnet zu argument 2 und 3 der Konstruktor im Frühjahr SAML-Beispiel-Anwendung entsprechen den gleichen privaten Schlüssel? Als pro-Dokumentation argument 2 entspricht das Kennwort der keystore-Datei. Im Frühjahr saml-Beispiel-Anwendung, ich glaube, dass es nur ein Zufall, dass das Kennwort der keystore-Datei und der private Schlüssel identisch sind. Wie kann ich JKS? Ich habe derzeit nur das öffentliche Zertifikat, das Hinzugefügt wird, in eine .cer-Datei, und ich bin mit dem Befehl keytool -importcert -alias adfssigning -keystore samlKeystore.jks -Datei testIdp.cer
Ich habe aktualisiert die Antwort mit zusätzlichen Erklärungen. Für details über, wie man erstellen JKS und importieren Sie die Schlüssel bitte in der Frühjahr SAML-die manuelle oder die Java-Dokumentation.
Ich habe verwiesen den Frühling SAML-Handbuch. Aber ich bin immer noch Probleme mit dem privaten Schlüssel. Habe ich einen JKS-Datei mit dem Befehl wie bereits erwähnt in der Anleitung, die ist wie folgt
keytool -genkeypair -alias some-alias -keypass changeit -keystore samlKeystore.jks
Welche Art von Problemen sind Sie konfrontiert - alle exceptions, Fehler - wo hast du Sie gepostet?
InformationsquelleAutor Vladimír Schäfer
Vladimir richtig beantwortet die Frage warum tritt der Fehler auf.
In meiner Antwort möchte ich zeigen, wie Sie können ein Zertifikat importieren, um den keystore um dieses problem zu lösen:
Haben Sie zum importieren des Zertifikats und privaten Schlüssel, die nicht getan werden konnte, die direkt durch das Dienstprogramm keytool.
Den detailliert beschriebenen Lösung ist hier zu finden: https://stackoverflow.com/a/8224863/1909531
Hier ist ein Auszug:
InformationsquelleAutor Matthias M
Dieser Fehler tritt auf, auch wenn Sie nicht über einen privaten Schlüssel in Ihrem Schlüsselspeicher. SAML verwendet den privaten Schlüssel zum generieren der Service-provider meta-Daten verwendet, um die Kommunikation mit dem IDP.
Fügen Sie einfach ein, um den Keystore wie diese: keytool -genkey -v -keystore some_key_store.jks -alias some_alias -keyalg RSA -keysize 2048 -validity 36500
Füllen Sie die Fragen und legen die Gültigkeit auf eine entsprechende Anzahl von Tagen. (In meinem Beispiel ist gültig für 100 Jahre)
Vergessen Sie nicht, das öffentliche Zertifikat von IDP. Dann sollten Sie bereit sein zu gehen.
InformationsquelleAutor Jakob Hemicke Greve