SAML Secured AuthnRequest не удается
Я не могу сделать защищенный запрос ECP AuthnRequest на мой Shibboleth IdP. У меня есть небольшое доказательство того, что концепция SP работает в значительной степени на основе примера приложения Spring SAML. Мои метаданные SP были сгенерированы с использованием генератора метаданных примера приложения Spring SAML. Используемый ключ подписи - это ключ apollo, включенный в пример хранилища ключей samlKeystore.jks, который также находится в моем собственном небольшом SP-приложении.
В моих метаданных SP для атрибута AuthnRequestsSigned установлено значение true, например:
<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
Если я установлю для AuthnRequestsSigned значение false и установлю ECP SOAP POST для IdP, все будет работать нормально. Я получаю правильное сообщение SOAP от IdP. Но если это значение истинно, я получаю неописательное сообщение об ошибке:
<env:Fault>
<faultcode>env:Client</faultcode>
<faultstring>An error occurred processing the request.</faultstring>
<detail/>
</env:Fault>
Я смотрю в журналах Shibboleth (IdP) и вижу:
Attempting to extract credential from an X509Data
Found 1 X509Certificates
Found 0 X509CRLs
Single certificate was present, treating as end-entity certificate
Credentials successfully extracted from child {http://www.w3.org/2000/09/xmldsig#}X509Data by provider org.opensaml.xml.security.keyinfo.provider.InlineX509DataProvider
A total of 1 credentials were resolved
Это отображается дважды в журнале для моей транзакции. Мое предположение заключается в том, что он находит сертификат в запросе и в моих метаданных SP. Далее в журнале во время этой же транзакции я вижу, что за этим следует трассировка стека:
Attempting to validate signature using key from supplied credential
Creating XMLSignature object
Validating signature with signature algorithm URI: http://www.w3.org/2000/09/xmldsig#rsa-sha1
Validation credential key algorithm 'RSA', key instance class 'sun.security.rsa.RSAPublicKeyImpl'
Signature did not validate against the credential's key
Signature validation using candidate validation credential failed
Signature did not validate against the credential's key
Я сравнил сертификат, который находится в ECP POST AuthnRequest, с сертификатом в моих метаданных SP, который используется для "подписи", и они совпадают. Так что я не уверен, почему я получаю эту ошибку.
Насколько я понимаю, IdP примет сертификат, найденный в <ds:X509Certificate> тег запроса (который является открытым ключом) и убедитесь, что он тот же, что определен в метаданных SP. Затем используйте этот сертификат для проверки значения подписи, которое также содержится в запросе в <ds:SignatureValue> элемент. Если он проверяется, он продвигается вместе с AuthnRequest. Это точно?
Какой кусок мне не хватает?
Обновление 1: я добавил строки регистрации, как было предложено, и вот все, что он показывает для запросов ECP:
signatureMethodURI = http://www.w3.org/2000/09/xmldsig#rsa-sha1
jceSigAlgorithm = SHA1withRSA
jceSigProvider = SunRsaSign
PublicKey = Sun RSA public key, 2048 bits
modulus: <long value here>
public exponent: 65537
Signature verification failed.
Стоит отметить, что если я отправляю запрос своему SP через браузер, и я не вошел в систему, меня перенаправляют на страницу входа в IdP, как и ожидалось. Я проверяю журналы IdP и вижу, что этот запрос также подписан, и он проверяется. Я посмотрел на данные формы, отправленные в IdP от SP и вижу, что AuthnRequest также подписан с использованием того же сертификата, но SignatureValue Ценности разные конечно. Этот XML-запрос данных, не относящихся к ECP, очень похож на SOAP-XML-запрос ECP, но ECP-запрос не выполняется.
ОБНОВЛЕНИЕ 2: я использую spring-security-saml-1.0.0.RELEASE и Shibboleth IdP v2.4.0. Вот пример сообщения, которое я отправляю в IdP:
<?xml version="1.0" encoding="UTF-8"?>
<soap11:Envelope
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
<soap11:Header>
</soap11:Header>
<soap11:Body>
<saml2p:AuthnRequest
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="http://1XP21VRS.mydomain.com:8080/proofofconceptapp-sso/saml/SSO/alias/conceptSSO" ForceAuthn="false" ID="a3j6fd01d0ciahe25b56i326bhe212" IsPassive="false" IssueInstant="2014-10-24T19:37:43.207Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Version="2.0">
<saml2:Issuer
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://1XP21VRS.mydomain.com:8080/proofofconceptapp-sso
</saml2:Issuer>
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#a3j6fd01d0ciahe25b56i326bhe212">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>mMJbjpmWr6OMP9eU70RA9TtfXGY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>I6rHpgjWgl5l5sjst+VHuSUnjUaOBnPIbUrWwcAfdTDSFY2wxUuNdHpXt/YqBfP9ZKdTWZV1IjbTR666T7sa1bZawgT3UO07FoBVAc5z+AH0nCvIz+UNSqpunPTaEdUhSaGmNHSItvFtvz2fDmvZl18GwXrTz4g6vvxKkdo/FijgvYldfYYuO+obcjof1SJmpOOr1iRNvpyGQMxcaH9e07QfJO9SDcLP2elvPvwbJsGGl/n/3sIG+kIm0MECU3hv/4pLx6+SyHDXjdhdOD2HyxGL1t7iIYG1AaDX4dkIt2wH2WOyzhfO2MyykqChhRcYWFdEdgqaQW/IBLPxsVjN9g==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDUjCCAjqgAwIBAgIEUOLIQTANBgkqhkiG9w0BAQUFADBrMQswCQYDVQQGEwJGSTEQMA4GA1UE
CBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kxGDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEM
MAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8wHhcNMTMwMTAxMTEyODAxWhcNMjIxMjMwMTEy
ODAxWjBrMQswCQYDVQQGEwJGSTEQMA4GA1UECBMHVXVzaW1hYTERMA8GA1UEBxMISGVsc2lua2kx
GDAWBgNVBAoTD1JNNSBTb2Z0d2FyZSBPeTEMMAoGA1UECwwDUiZEMQ8wDQYDVQQDEwZhcG9sbG8w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXqP0wqL2Ai1haeTj0alwsLafhrDtUt00E
5xc7kdD7PISRA270ZmpYMB4W24Uk2QkuwaBp6dI/yRdUvPfOT45YZrqIxMe2451PAQWtEKWF5Z13
F0J4/lB71TtrzyH94RnqSHXFfvRN8EY/rzuEzrpZrHdtNs9LRyLqcRTXMMO4z7QghBuxh3K5gu7K
qxpHx6No83WNZj4B3gvWLRWv05nbXh/F9YMeQClTX1iBNAhLQxWhwXMKB4u1iPQ/KSaal3R26pON
UUmu1qVtU1quQozSTPD8HvsDqGG19v2+/N3uf5dRYtvEPfwXN3wIY+/R93vBA6lnl5nTctZIRsyg
0Gv5AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFQwAAYUjso1VwjDc2kypK/RRcB8bMAUUIG0hLGL
82IvnKouGixGqAcULwQKIvTs6uGmlgbSG6Gn5ROb2mlBztXqQ49zRvi5qWNRttir6eyqwRFGOM6A
8rxj3Jhxi2Vb/MJn7XzeVHHLzA1sV5hwl/2PLnaL2h9WyG9QwBbwtmkMEqUt/dgixKb1Rvby/tBu
RogWgPONNSACiW+Z5o8UdAOqNMZQozD/i1gOjBXoF0F5OksjQN7xoQZLj9xXefxCFQ69FPcFDeEW
bHwSoBy5hLPNALaEUoa5zPDwlixwRjFQTc5XXaRpgIjy/2gsL8+Y5QRhyXnLqgO67BlLYW/GuHE=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</saml2p:AuthnRequest>
</soap11:Body>
</soap11:Envelope>
Я просто копирую ответ из первоначального запроса PAOS в SP (Spring SAML), удаляю внутренности заголовка и отправляю его в Shibboleth IdP. Заголовки, которые я отправляю:
Content-Type: text/xml
Authorization: Basic <base64 encoded credential string here>
Обновление 3: Подписанные не-ECP AuthnRequests проверяют просто отлично. Так что это только SOAP ECP AuthnRequest в IdP, где подпись не удается. Есть идеи?
Обновление 4: все еще не могу заставить это работать. Любая помощь будет оценена.