PingFederate Single Log-Off: My IdP issues only one LogoutRequest - single-sign-on

Building off of #Scott T.'s answer:
...PingFederate (acting as an IdP) knows which SPs you have
federated with in a given session. When the user kicks off SLO (from
the example you gave - at the IdP - it could also be initiated from an
SP) the users browser (assuming a Redirect or POST binding) is sent to
each SP with a SAML LogoutRequest.
When I request https://[PingFederateInstance]/idp/startSLO.ping?PartnerSpId=[PartnerSpId], according to server.log, PingFederate issues only one LogoutRequest.
<samlp:LogoutRequest Destination="https://[PingFederateServerInstance]:[PortNumber]/sp/SLO.saml2" NotOnOrAfter="2011-11-22T23:02:37.812Z" IssueInstant="2011-11-22T22:57:37.812Z" ID="NEDH4Khn4TvWsOwfAZxK_XiEc6f" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer>XXX:IDP</saml: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="#NEDH4Khn4TvWsOwfAZxK_XiEc6f">
<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>Hnec0X3qfYlE2Z9+ooujtD1HKQk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>L6wmw7RF82s8W2s4YSkwHpnQFo6tFRKUZ3pyK7JEl/7CZyJsxJ5lnfpdaaogm/Gl3S3Y7WoSjbp4
ssaNjtQ3x/nHsYI0zill66yhQ/DNaXAdRuKw6jDi9vqXemkYGx9cNxLkLvc14CUdn9qRA0gZcjyj
ncaZvvWL5Kzy9JOuWSg=</ds:SignatureValue>
</ds:Signature>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">10072824</saml:NameID>
<samlp:SessionIndex>dWh6bd58GRgnbLgeYsTWSVXT7pO</samlp:SessionIndex>
</samlp:LogoutRequest>
My Question:
If I've federated with more than one SP, how should I configure PingFederate so that it issues one request per federated SP?
I'm inclined to believe that:
I need to configure something on this screen.
In agreement with the idea that the multiple SP logout requests are "chained together", the last endpoint URL should be /idp/SLO.saml2.

Let me revise that first answer:
PingFederate knows which SPs you have federated with in a given session.
Should be:
PingFederate acting as the IdP knows which SPs a user has signed into in a given session.
The configuration at PingFederate acting as the IdP would include SLO protocol configuration for each SP connection you have. The screenshot you linked to in (1.) is actually an IdP connection screen, that would be done at PingFederate playing the SP role (maybe that's what you're acting as - it wasn't clear to me in your original query, so I assumed IdP from the nature of your question). You will want to ensure you have configured each SP connection with appropriate SLO endpoints following these instructions. If PingFederate is the IdP it will know to redirect to all SP's that support SLO (and where the user has a session) when a user initiates SLO.
WRT to (2.): If users start the SLO process at the IdP, then yes - users will be redirected back to /idp/SLO.saml2 as the last step. In fact, each SP that you redirect to for logout, will redirect back to the IdP to logout of the next SP. If you start the SLO process from an SP, then the last place users will end up is at that SP's SLO endpoint.

Related

Apache Knox for SAML2 authentication keeps using NameIDFormat entity instead of what is configured

I am trying to enable SSO capabilities for Apache Zeppelin, using Apache Knox, which is configured to redirect auth requests to a Siteminder IdP.
The issue I am having is related to the NameID format configuration, and the signing configuration.
No matter what I configure in the sp/idp metadata, the NameID format used is
urn:oasis:names:tc:SAML:2.0:nameid-format:entity
And the requests are always being sent with Signed requests set to true.
My SP configuration is as follows:
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client">
<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol http://schemas.xmlsoap.org/ws/2003/07/secext">
<NameIDFormat>
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
</NameIDFormat>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client"/>
<AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" index="1" isDefault="true" Location="https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client"/>
</SPSSODescriptor>
I activated a SAML tracer and attempted the logon user journey. The AuthNRequest being sent to the Siteminder IdP based on this configuration looks like this:
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client"
Destination="https://test-siteminder.com/test/saml2sso"
ForceAuthn="false"
ID="_yp52mio0oj4ho2niijmnnaikgbkid9tnc5h5ear"
IsPassive="false"
IssueInstant="2020-02-17T10:19:24.279Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
ProviderName="pac4j-saml"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
NameQualifier="https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client"
>https://knox.test.com/gateway/knoxsso/api/v1/websso?pac4jCallback=true%26client_name=SAML2Client</saml2:Issuer>
I can see a signature value in the Parameters section of the request, which is why I'm assuming that the AuthNRequest is signed (though my understanding of this is minimal, so that could be a wrong assumption!).
Can anyone help explain why the NameIDFormat is coming through as entity, as opposed to unspecified?
Does Apache knox support SAML1 protocols?
Thanks in advance!
You mentioned NameID format to be urn:oasis:names:tc:SAML:2.0:nameid-format:entity in your post but in the code you pasted it is urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, just a copy paste error ? Looks like protocolSupportEnumeration is also referencing SAML 1 protocol. Knox uses Pac4J under the hood which does not support SAML 1, this might be the reason.

SAML logout not working in ADFS

I have written a Service Provider and testing the same with some IDPs. When I tested with ADFS, login works fine but have a problem during logout. When I set a logout request, I am getting a valid logout response from the ADFS but when I send a new AuthNRequest after successful logout, ADFS is not asking for any credentials and making the user previous logged-in as the current user and sending a valid Auth Response with the same. Here is the LOGOUT RESPONSE sent by ADFS :
<samlp:LogoutResponse ID="_4b1507e9-85c6-4aab-8a20-9bf420f15057" Version="2.0" IssueInstant="2018-01-24T10:16:46.793Z" Destination="https://manoj-3374:9876/mc/SamlLogoutResponseServlet" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="ME_7d8bc526-b585-460e-a677-cab2c9f4c43b" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://hostname/adfs/services/trust</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/2001/04/xmldsig-more#rsa-sha256" /><ds:Reference URI="#_4b1507e9-85c6-4aab-8a20-9bf420f15057"><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/2001/04/xmlenc#sha256" /><ds:DigestValue>pLbKQReWhLBgYkDMe4ets84pnQq21NexmofA/49bBXQ=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>oq60dpAGnAUdjmLFUFZDIcc/LZo5dhxVgc12nMUdAmffl3CgMXXOUvdprUaAWkf84gTZ2zaHb0iIHDRIjjicrfR1NunmgT9/dpP0rHvDJ5ViCyb6Lf7eWomyDqAAvpWGL9MwHIpW0tQZj04DxYbMzRJrwyvCClKO8IQ+xin09wSXcU5Ibm7l/75FZB/ZNI35e/PietCL6Rt8uf/YjH4sYthIYzTBn70iYAElO87YFvVBP0RtK0vv5WpcvnxaGh0eWDnYAYJHEIZQ/EjZFCEVfuneqL2F9n3uXQR9FW2N9Kb3mdKy74PSh/Qbsosq3efZ7sC5DXUcVseJIrJTynpBrw==</ds:SignatureValue><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIC/jCCAeagAwIBAgIQMQknUWY/VZtEgNVEh0GpgjANBgkqhkiG9w0BAQsFADA7MTkwNwYDVQQDEzBBREZTIFNpZ25pbmcgLSBzZHBvZC1rMTJyMi0xLmNzZXouem9ob2NvcnBpbi5jb20wHhcNMTcwNzExMTMwNjAwWhcNMTgwNzExMTMwNjAwWjA7MTkwNwYDVQQDEzBBREZTIFNpZ25pbmcgLSBzZHBvZC1rMTJyMi0xLmNzZXouem9ob2NvcnBpbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8DceRgiArTb0H5EgBA35fjOKFz5yP/t76u2bWJCnaNw7qwUjssy/vt4XH7H8nJ3O0nMSkaTAQZJp4LTHIe3fqnKNzqWsJFtYoG/d7YW22O7rOGfgtDQdcZXbvFZYc41tP77vQ4i/FsEm9t/QZAQdqGkzMQtF1JymvdfJ/e4Ui+JCmHwyDkzkgPmdPjJM3Rz1KwJxgW3fAFaORBnaXySIW0D6bwZgSO3JMohSGtOk3hJ4+ykW/A5dwhBeSL00+6n/KjrCCRavoZX6oATLpj+000mhhFmjibo/jOh24rtRqz7r9h0LHpWXzSiApFxTEiH2SsBsfKXFEzvgRjj/0LftFAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAJCuMIcGs8tTVPqiYwU7G1ZSyBQ2jbL58Qml+O2zrvCWtlBrkRnybvOd9SQPKSD4xklwJA2dkFk0tUrziyw8C23yuwUusMpnvHQnrLTumzcxwUpM8wPJvnkCcwPf2ECjRkSVHJyFr7vODn7tusVL0yVjLeGqUk8QdvFdwj1TV7wLTNSanQlKlPQarVdN+k6q8GVWVxcv1ljbpDrGnBK6aE+91ypuwz/NQOIyI/qCwMZaEi2bbxbWRHe2en4IkuE6KSOq/nDbqQsXOYjRjOjXGz2nxgJxIu9/Jv391RsSF7OooMJ0SByO53BkDix+LZnu5WvyzrCyYhxODwomy/jTSy4=</ds:X509Certificate></ds:X509Data></KeyInfo></ds:Signature><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status></samlp:LogoutResponse>
How did the user login? Were they a domain user and they used Windows integrated authentication?
If so, the logout response will indicate success even though the user wasn't logged out from Windows.
If they used forms authentication then they should have been logged out.
In that case, you should check the ADFS Windows event log for more details.

SAML Single logout through OKTA

I have got the following SP's Request and IDP's reponse:
<samlp:LogoutRequest xmlns="urn:oasis:names:tc:SAML:2.0:metadata" Destination="https://dev-nnn.oktapreview.com/app/somename_hped800eportal_1/exk8dlkd0tCutHWlj0h7/slo/saml" ID="_af6eaa4a-9d5b-41ce-b265-d39dfdc5248e" Version="2.0" IssueInstant="2016-10-14T12:31:59Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><saml:Issuer xmlns:saml="http://www.w3.org/2005/Atom">https://HPED800E:444/SynPortal/login.aspx</saml:Issuer><saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified">CDA_Main\hjami</saml:NameID><samlp:SessionIndex>_d9f07562-3a7f-4c03-a62d-8a985f34058f</samlp:SessionIndex><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue>bBbMvzSjRc0zc1jtIxmqmkO4bYo=</DigestValue></Reference></SignedInfo><SignatureValue>...5g==</SignatureValue><KeyInfo><X509Data><X509Certificate>...Cw==</X509Certificate></X509Data></KeyInfo></Signature></samlp:LogoutRequest>
<?xml version="1.0" encoding="UTF-8"?><saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://hped800e:444/SynPortal/logout.aspx" ID="id50277036872307661186452042" InResponseTo="_1eef2809-b49e-412e-a0c5-3596e3c0b158" IssueInstant="2016-10-14T00:32:05.949Z" Version="2.0"><saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://www.okta.com/exk8dlkd0tCutHWlj0h7</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="#id50277036872307661186452042"><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>3k7z8GF3kBemyYm+6+mEbZMSAYw=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>...MA==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>...VNm</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2p:Status xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed"/></saml2p:Status></saml2p:LogoutResponse>
the request is encoded base-64 and then sent via post binding.
I am getting the AuthnFailed response.
I have set up only one sp for the IDP for simplicity.
Does anyone know what I am doing wrong here?
This information is insufficient to determine as what has gone wrong in your implementation for single logout. Can you please provide following information
1) Your single logout settings in Okta that can be found under SAML Settings -> Advanced Settings under General tab of your app?
2) Based on above settings please make sure you have uploaded certificate to Okta?
3) Which SAML toolkit are you using? Can you provide toolkit settings for your toolkit?
See the working SLO request below.
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_d2be8c5de3aeeeac27c8xxxxyyyy"
Version="2.0"
IssueInstant="2016-04-27T16:15:06Z"
Destination="https://org-name.okta.com/app/simplesamlphpexample/exk4xxyyPcvdVq70x7/slo/saml"
>
<saml:Issuer>http://localhost:8888/simplesamlphp/www/module.php/saml/sp/metadata.php/example-okta-com</saml: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="#_d1be8c5dc2aeeeac27c8daf04b7xxxyyy6b36287bd6">
<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>{{some_value}}</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>{{some_value}}</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>{{some_value}}</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">{{email}}</saml:NameID>
<samlp:SessionIndex>{{some_value}}</samlp:SessionIndex>
Comparing the SLO settings for your request and mine few things stood out.
1) CanonicalizationMethod Algorithm in my case is set to http://www.w3.org/2001/10/xml-exc-c14n#. Yours is http://www.w3.org/TR/2001/REC-xml-c14n-20010315.
2) Name ID in your case is "CDA_Main\hjami". Can you please let me know which attribute in Okta is this? Also, have you overridden the userName of your app using the mappings from Okta to app (under profile editor -> your app mappings). For example, I am overriding the app userName from Okta login/email to be custom attribute.
If you are using another attribute (whose value is set to CDA_Main\hjami) from Okta as the username of the app, please make sure that you are overriding it like I am doing in the screenshot above.
I also had a hard time in making this Logout request successfully.
Here is the solution that worked for me:
You'll need the following keys:-
(a) Service provider's (your application's) private key, e.g. sp-pvt-key.pem
(b) Service provider's public key, e.g. sp-pub-key.pem
Note: You can generate these keys via openssl from your terminal.
Steps:
Provide SP's private key on SAML's configuration strategy in you application's code.
Upload SP's public key on okta's logout configuration.
Now you'll get successful logout response.

SAML Secured AuthnRequest Fails

I'm not able to make a secured ECP AuthnRequest to my Shibboleth IdP. I've got a small proof of concept SP running which is based heavily on the Spring SAML extension sample app. My SP metadata was generated using the Spring SAML extension sample app's metadata generator. The signing key being used is the apollo one included with the sample app samlKeystore.jks key store, all of which is also in my own small SP app.
In my SP metadata, I have the AuthnRequestsSigned attribute set to true like so :
<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
If I set AuthnRequestsSigned to false and make the ECP SOAP POST to the IdP, it works just fine. I get the proper SOAP message back from the IdP. But if that value is true, I get a non-descriptive error message:
<env:Fault>
<faultcode>env:Client</faultcode>
<faultstring>An error occurred processing the request.</faultstring>
<detail/>
</env:Fault>
I look in the Shibboleth (IdP) logs and see:
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
This displays twice in the log for my transaction. My assumption is because it's finding the certificate in the request and in my SP metadata. Further down in the log during this same transaction I see this followed by a stack trace:
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
I compared the certificate that is in the ECP POST AuthnRequest to the one in my SP metadata used for "signing" and they are the same. So I'm not sure why I'm getting this error.
My understanding is that the IdP will take the certificate found in the <ds:X509Certificate> tag of the request (which is the public key) and make sure that's the same one defined in the SP metadata. Then use that cert to verify the signature value which is also in the request in the <ds:SignatureValue> element. If it validates then it moves forward with the AuthnRequest. Is this accurate?
What piece am I missing?
Update 1: I've added the logging lines as suggested and here's all it shows for the ECP requests:
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.
One thing of note, if I make a request to my SP via a browser and I'm not signed in, I get redirected to my IdP login page as expected. I check the IdP logs and see that that request was also signed and it validates. I looked at the form data sent to the IdP from the SP and see that AuthnRequest is also signed using the same certificate but the SignatureValue value are different of course. That non-ECP request data XML looks very similar to the ECP request SOAP XML yet the ECP one fails.
UPDATE 2: I'm using spring-security-saml-1.0.0.RELEASE, and Shibboleth IdP v2.4.0. Here's a sample message I'm sending to the 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>
I'm pretty much just copying the response from the initial PAOS request to the SP (Spring SAML), removing the header innards, and sending that along to the Shibboleth IdP. The headers that I send are:
Content-Type: text/xml
Authorization: Basic <base64 encoded credential string here>
Update 3: Signed non-ECP AuthnRequests validate just fine. So it's only SOAP ECP AuthnRequests to the IdP where the signature fails. Any ideas?
Update 4: Still can't get this working. Any help would be appreciated.

SAML 2.0 SP metadata: Purpose and the use of certificate

Here is the part of SP metadata.
Reference: Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0
...
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
</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>
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
...
Are there any benefits to choose same (or different) certificate in both signing and encryption certificate ?
What is the purpose of including signing certificate here ?
If the message is sent through https, a transport layer encryption is provided. Do we still need to include encryption certificate here ?
In SAML 2.0 Web SSO's metadata providers typically declare the same certificate for both signing and encryption usage.
There are some use-cases where usage of different keys makes sense - e.g. when SP itself is not supposed to be able to decrypt data provided by IDP (e.g. nameID or attributes), but this is only done by the ultimate recipient of the Assertion; or when a different party provides content for creation of assertion than the party who actually creates the SAML messages - but those use-cases are rare and more relevant for other profiles than Web SSO.
The signing certificate is included in order to inform users of the metadata on how to verify messages provided by the issuer of the metadata. For example, when SP receives a message from IDP, it uses signing certificate defined in IDP's metadata in order to verify whether the message was created by the IDP and wasn't tampered with during transport.
You typically don't need to include the encryption certificate in case encryption is done on transport layer and you don't perform any encryption on message level (e.g. of whole message, assertion, nameID or attributes).