spring-security-saml, IdP не может зашифровать утверждение?

Я пытаюсь протестировать нашу настройку Spring-Security-SAML для Shibboleth с помощью testshib.org.

Сгенерированные нами метаданные (после передачи xmllint --format для удобства чтения) включены ниже:

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="https___sforge0.york.ac.uk_sf_saml_" entityID="https://sforge0.york.ac.uk/sf/saml/">
  <md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIDNjCCAvOgAwIBAgIEUESd6DALBgcqhkjOOAQDBQAwbDEQMA4GA1UEBhMHVW5rbm93bjEQMA4G
A1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4GA1UEChMHVW5rbm93bjEQMA4GA1UE
CxMHVW5rbm93bjEQMA4GA1UEAxMHVW5rbm93bjAeFw0xNDEwMjMxNTM2MTJaFw0xNTAxMjExNTM2
MTJaMGwxEDAOBgNVBAYTB1Vua25vd24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25v
d24xEDAOBgNVBAoTB1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xEDAOBgNVBAMTB1Vua25vd24w
ggG4MIIBLAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlF
XUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fG
qKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL
8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkW
cSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD
3+Fa5Z8GkotmXoB7VSVkAUw7/s9JKgOBhQACgYEAlmBZaPGCOx/qBr/sGxjkb+FA1SPfMj2ys2OQ
joauGh53ORS8AolmE3Cwc3S2B0qA9ldhL4I2cv0ShOIz7x+JYTnrIqXtqS6essY6jG1Kpwhy4YCB
UJRwKfcyYfq1+meLbZ/vAqgvMA7/rJOQnRi/HnqzqW7wdH9BItPR6G451vmjITAfMB0GA1UdDgQW
BBQANR5pMdkq/O47PEgTBUuMQPFrtzALBgcqhkjOOAQDBQADMAAwLQIUYlj1QoLS6JGlnjsTYl/l
vFmVFL0CFQCQ/jwl1chFdPvHvzTeo+LvsOynrw==</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:KeyDescriptor use="encryption">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIDNjCCAvOgAwIBAgIEUESd6DALBgcqhkjOOAQDBQAwbDEQMA4GA1UEBhMHVW5rbm93bjEQMA4G
A1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4GA1UEChMHVW5rbm93bjEQMA4GA1UE
CxMHVW5rbm93bjEQMA4GA1UEAxMHVW5rbm93bjAeFw0xNDEwMjMxNTM2MTJaFw0xNTAxMjExNTM2
MTJaMGwxEDAOBgNVBAYTB1Vua25vd24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25v
d24xEDAOBgNVBAoTB1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xEDAOBgNVBAMTB1Vua25vd24w
ggG4MIIBLAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlF
XUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fG
qKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL
8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkW
cSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD
3+Fa5Z8GkotmXoB7VSVkAUw7/s9JKgOBhQACgYEAlmBZaPGCOx/qBr/sGxjkb+FA1SPfMj2ys2OQ
joauGh53ORS8AolmE3Cwc3S2B0qA9ldhL4I2cv0ShOIz7x+JYTnrIqXtqS6essY6jG1Kpwhy4YCB
UJRwKfcyYfq1+meLbZ/vAqgvMA7/rJOQnRi/HnqzqW7wdH9BItPR6G451vmjITAfMB0GA1UdDgQW
BBQANR5pMdkq/O47PEgTBUuMQPFrtzALBgcqhkjOOAQDBQADMAAwLQIUYlj1QoLS6JGlnjsTYl/l
vFmVFL0CFQCQ/jwl1chFdPvHvzTeo+LvsOynrw==</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sforge0.york.ac.uk:443/sf/saml/SingleLogout"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://sforge0.york.ac.uk:443/sf/saml/SingleLogout"/>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sforge0.york.ac.uk:443/sf/saml/SSO" index="0" isDefault="true"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Мы загружаем это на testshib.org через опцию «Регистрация», а затем нажимаем на нашу работающую службу по адресу $ contextPath / saml / login, которая правильно перенаправляет нас на testshib.org, который принимает учетные данные «я: я» и перенаправляет обратно на наш сайт.

Затем мы видим (в наших журналах):

2014-10-29 10:12:52,002 278662 [1817318774@qtp-1246086685-8] INFO  o.s.security.saml.log.SAMLDefaultLogger - AuthNResponse;FAILURE;144.32.136.27;https://sforge
0.york.ac.uk/sf/saml/;https://idp.testshib.org/idp/shibboleth;;;org.opensaml.common.SAMLException: Response has invalid status code urn:oasis:names:tc:SAML:2.0
:status:Responder, status message is Unable to encrypt assertion
        at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:113)
        at org.springframework.security.saml.SAMLAuthenticationProvider.authenticate(SAMLAuthenticationProvider.java:82)
        at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)

Удаление журналов с testshib.org показывает:

06:12:51.694 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:927] - Could not resolve a key encryption credential for peer entity: https://sforge0.york.ac.uk/sf/saml/
06:12:51.695 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:289] - Unable to construct encrypter
org.opensaml.xml.security.SecurityException: Could not resolve key encryption credential
    at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.getEncrypter(AbstractSAML2ProfileHandler.java:928) ~[shibboleth-identityprovider-2.4.0.jar:na]
    at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.buildResponse(AbstractSAML2ProfileHandler.java:286) ~[shibboleth-identityprovider-2.4.0.jar:na]

Как было предложено в других вопросах, я обеспечил наличие тега KeyDescriptor в метаданных (фактически, два, каждый с атрибутом «использовать»). Я также пробовал вручную изменять метаданные, чтобы использовать один KeyDescriptor, с атрибутом use и без него, все из которых, похоже, дают аналогичные результаты.

Я могу предоставить дополнительную информацию, например, больше содержимого журнала, конфигурацию spring xml и т. Д. По запросу, но я не уверен, насколько это актуально, поэтому я решил пока оставить их.

Я не уверен, как убедить testshib.org использовать ключ, указанный в метаданных, или что-то не так с метаданными, которые мы предоставляем testshib.org? Есть идеи относительно того, как заставить работать наш логин testshib?


spring-saml shibboleth
person Tinned_Tuna    schedule 29.10.2014    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я разместил сообщение в списке рассылки Shibboleth.net, и Ян Янг предположил, что мои сертификаты могут быть виноваты.

В конце концов, вот мой полный ответ на список рассылки, включая то, что Я сделал, чтобы исправить:

Повторное создание хранилища ключей, похоже, исправило это. Keytool вёл себя очень странным образом, пытаясь получить информацию из keytool в этом случае (keytool -printcert -alias Skillsforgetrustfabrickey -keystore sfTestKeyStore.jks), казалось, зависал процесс keytool (!).

Я удалил старое хранилище ключей и воссоздал его:

keytool -genkeypair -keysize 2048 -keyalg rsa -validity 730 -keystore sfTestKeyStore.jks -alias skillsforgeTrustFabricKey

Использовал те же пароли и т. Д., Как указано в моей конфигурации, и он загадочным образом ожил после перезапуска Jetty и повторного запроса / повторной регистрации моих метаданных.

Хотя у меня нет данных о том, как именно я сгенерировал пару ключей ранее, я вполне уверен, что раньше использовал тот же (или, по крайней мере, очень похожий) метод. Очевидно, я, должно быть, что-то неправильно набрал, когда настраивал хранилище ключей в прошлом.

person Tinned_Tuna    schedule 30.10.2014