Spring Security SAML - Response.isSigned = false - spring-security

When asking if my assertion is signed it always returns false, making it hard to do a second validation after the SP filter finish. My IDP is ADFS 2.0 and I have tried to sign the entire samlresponse and only the assertion, but with the same result.
We want to get the assertion out of our ticket in the web application that is protected by the spring SP module. So when the user is authenticated we want to forward our assertion to a service that will validate it and do something if it is a valid assertion. In this service we do not want Spring security and the spring SP. We simply want the assertion forwarded and verified with openSaml library.
Our problem is that when we got the assertion out of Spring sec and forwarded to our service, validation is started with the following line, which always return false:
assertion.isSigned()
The above line of code is derived from:
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
SAMLCredential credential = (SAMLCredential) authentication.getCredentials();
credential.getAuthenticationAssertion().isSigned();
This also generates 'false' when called in our top tier webapp.
Overriding the SAMLAuthenticationProvider adding the above code yields 'false' as well.
If we add following code snippet to our webapp:
Configuration.getMarshallerFactory().getMarshaller(credential.getAuthenticationAssertion());
marshaller.marshall(credential.getAuthenticationAssertion());
And then run the
assertion.isSigned();
We get 'true' as a response.
We're using spring-security-saml2-core version 1.0.1.RELEASE.
Logs:
10:07:19,413 DEBUG [org.springframework.security.saml.websso.WebSSOProfileConsumerImpl] (http-/0.0.0.0:8443-3) Verifying issuer of the Response
10:07:19,414 DEBUG [org.springframework.security.saml.websso.WebSSOProfileConsumerImpl] (http-/0.0.0.0:8443-3) Verifying signature
10:07:19,417 DEBUG [org.springframework.security.saml.websso.WebSSOProfileConsumerImpl] (http-/0.0.0.0:8443-3) Processing Bearer subject confirmation
10:07:19,418 DEBUG [org.springframework.security.saml.websso.WebSSOProfileConsumerImpl] (http-/0.0.0.0:8443-3) Verifying received AuthnContext org.opensaml.saml2.core.impl.AuthnContextImpl#3efbe08d against requested null
10:07:19,418 DEBUG [org.springframework.security.saml.websso.WebSSOProfileConsumerImpl] (http-/0.0.0.0:8443-3) Validation of authentication statement in assertion _79ec0857-148d-49ca-8df4-25e685fdc5b9 was successful
10:07:19,422 INFO [org.springframework.security.saml.log.SAMLDefaultLogger] (http-/0.0.0.0:8443-3) AuthNResponse;SUCCESS;172.172.176.103;IAMDemoAppADFS;https://ADFSdomain.test.se/adfs/services/trust;XXX;;
10:07:19,422 DEBUG [org.springframework.security.saml.SAMLProcessingFilter] (http-/0.0.0.0:8443-3) Authentication success. Updating SecurityContextHolder to contain: org.springframework.security.providers.ExpiringUsernameAuthenticationToken#2cb1c6f2: Principal: XXX; Credentials: [PROTECTED]; Authenticated: true; Details: null; Not granted any authorities
Here is our SAML response:
<samlp:Response Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
Destination="https://domain.test.se:8443/IAMDemoAppADFS/saml/SSO"
ID="_a97d2515-6160-4370-8e85-a34143a1e2fb" InResponseTo="a3jdaigh6671c3g5464d3ff472jffdd"
IssueInstant="2015-10-28T09:52:34.745Z" Version="2.0"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://ADFSdomain.test.se/adfs/services/trust</Issuer>
<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
<Assertion ID="_574cd222-ec33-4f3d-b77b-a3ab2f16d33d" IssueInstant="2015-10-28T09:52:34.745Z"
Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>https://ADFSdomain.test.se/adfs/services/trust</Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_574cd222-ec33-4f3d-b77b-a3ab2f16d33d">
<Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>gk/c0lTTLw8zXdKuvkZi48eY4sA=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>kU7WfGIEIQul40i9jObZ2uyb0rnJaEr2n2bBI6E/IS8Dr52quUR8nrMG5jwmGFxgdD63odpo4605SmQVlPKxOAD2GbIOSzgNDG8u/axH8JEEAhzfC5CGfE6i775WkkZ1+LsOrmrWCAJnXjejo/Zrg6z7rSi/USgeB4TmxipwF7twMunnNFKgaPntzv3dVAQjc+zglCR0A3QQwo1orM14mFcrcYlsD6sIGWd1LmumgScWE6iNt5Fif/hPirtcF0K0YpNBPbhiDwxpPZ8NgAZIjliZU8b5Qem6Vi50ysH9lj57r7hMmUD9IjgHS1wpOfZuII2if+BcddUp7aqA+GWmw7Fw==</SignatureValue>
<KeyInfo>
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Certificate>MIIC/jCCAeagAwIBAgIQepmcj017xa9GmDEoyznQHjANBgkqhkiG9w0BAQsFADA7MTkwNwYDVQQDEzBBREZTIFNpZ25pbmcgLSBhZGZzLm1zYWQubGFiLm1pZ3JhdGlvbnN2ZXJrZXQuc2UwHhcNMTUwODI5MTkzNjE5WhcNMTYwODI4MTkzNjE5WjA7MTkwNwYDVQQDEzBBREZTIFNpZ25pbmcgLSBhZGZzLm1zYWQubGFiLm1pZ3JhdGlvbnN2ZXJrZXQuc2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDb27miaTa+9Kpdj3kPbno8IqypRQq/NI3shIhtYyAbbaiKYQEs0C6AxFoowpo13MB1yKO9g0EmgmDHsIHE1Gl+tc8NvNC03Dr6izsOb1ePChdi/oJ10BoAS1zmrOuHDoa31HwfqkXwRRIUIE70DZxmroAtyE/GeDGxqGwmtZWRqdPXY5q7MKkfVqUe0e8jbod76ymZpA773n5ka0NxyFu5N8/W+dEAcUqlCBDSu140KEnE6sCG4QqEth9GPom3ttqNb+qvBsDnC8UZ05chv5tHS3xXQ1u8Q2vqdtTX8hrK5ZQMr+Hd/mtNpb/65X3uHTGsemR9sSVmyrcZWX/9oAKbHjAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAD/vJqoPm5FsRzuzWbf1F4FE9s2Cs84KM/UgjIJeIfP35EAW8v2SIbCXAOs2rW+s25Y8X+U4whPxDlGiZ8aO8E7KIq/Mm4AOpmXKMCzahxNyD1MqeRUMZNsuFv4ciw8cNtIDDecqDqSCjDeTMg/asppVEuzTREKw7tP2a5KJgfJrmFM/92tUzqpIfO3gqrJkJsbHz53g4CbwwyleHY8NuSxXYwncw8qzgHvBlPRzpn0GkMSZXJxSRDKH1QXJeaf2jUddaF6S+7FsalPzHyMf/jG0YugDVinrR+6fEeERlA/zM8JYC7CVsZRn/OHmvxFXJpiayrVZTom+N5701DihuzA=</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID>XXX</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData InResponseTo="a3jdaigh6671c3g5464d3ff472jffdd"
NotOnOrAfter="2015-10-28T09:57:34.745Z"
Recipient="https://domain.test.se:8443/IAMDemoAppADFS/saml/SSO"/></SubjectConfirmation>
</Subject>
<Conditions NotBefore="2015-10-28T09:52:34.745Z" NotOnOrAfter="2015-10-28T09:53:34.745Z">
<AudienceRestriction>
<Audience>IAMDemoAppADFS</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2015-10-28T09:52:34.558Z"
SessionIndex="_574cd222-ec33-4f3d-b77b-a3ab2f16d33d">
<AuthnContext>
<AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>

Try setting releaseDOMto false in WebSSOProfileConsumerImpl. This use-case is documented in the manual with additional details - it doesn't explicitly state that the signature will be removed by default, but it's likely the case.

Related

IBM API Connect - Cannot pass the meaningful message from response of Authentication URL to oAuth/token Client

I have an oAuth Provider which uses Authentication URL. In some cases, my Authentication URL returns "non-200" with meaning messages e.g. incorrect username, incorrect password, user locked etc.
I wonder how to pass the meaningful message from Authentication URL to the client who is requesting the token via API (oauth2/token)??
I have tried many ways, the API Connect always results 401 - invalid grant only.
Here is my oAuth Provider Code
x-ibm-configuration:
testable: true
enforced: true
phase: realized
oauth2:
client-type: confidential
scopes:
weather: Weather Information
openid: Enable OIDC
grants:
- password
identity-extraction:
type: basic
authentication:
x-ibm-authentication-url:
url: 'https://8hxovobj7g.execute-api.eu-west-2.amazonaws.com/Prod/auth'
authorization:
type: authenticated
access-token:
ttl: 1500
refresh-token:
count: 2048
ttl: 2682000
gateway: datapower-gateway
assembly:
execute:
...
...
when authen fail due to incorrect username, the authentication URL return
401 Unauthorized
{
"error": "incorrect username"
}
However, when I use postman to post a request to API Connect Gatwatway to the oAuth Provider (path: /oauth2/token)
if correct username password (authen URL user registry return 200-OK, I will get
{
"token_type": "bearer",
"access_token": "AAIkNTU4M2RlMzktODY1NS00ZDQ1LTgyMjctODEyMDM4MDUzMTE2m7lBYXfx73OVPONAHoLT5VNdtSVD40Hu-M3nAQPu6wdviOxcIfbsOXBwt-Iy8EAgLzuATlZB7RBME_U5Ymd5fDkRTwy05G9zGmV7mIkawaELtiOj4xdzQr7Vn-indlv-y1NFEjvRv2VrK0d3TOqZnTEj5heDdY7Q0X9BFeydV4MtS-gCpnj-9l6TU3XqyeiK5hGnBZkZRAWOIskLm4KCyf8n_mnsi42vN9GLxlxoO9EmuHAwXOxr_aocKaaVlLKK5vDMHBRws2Vguqk3eVuoh9EnkRZvjbTurmW57bCgX3nMTd6MwcEYFkAGh-cOcEDyydZR6BI_pLuwaUM9RN8Vnb7EATQjzW2d_eHKQyjShcyM0TqxzhYq3q90fLfJLo08WxDgTFaKpGHA6qoZmUpYRLeyyImhOPtyd9p1l9z87g52duHbL1cyVGErHktTVpeXsmIRtn-QTTvI4jWmjxPZnSYj_rEeR9S8QAxYpHSEPmJQQmsjISf2SIRLABwuhG9dKyrrzs3UTotVyIotxmJjc9lfEsEtDTz9Ej--yQFw97ESHCVEvOkifeyIJ9F5MyPFh7fMEoGGwyDmWEfZSYRpkLg4_ib3dbjkGAuthiwjdA0",
"metadata":
...
}
if incorrect username/ password (authen URL user registry return 401-Unauthorized with response-body (error message), I will get
401-Unauthorized
{
"error": "invalid_grant"
}
The Authentication URL is custom made. I have tried to make different returns in authentication URL (different http response code/ body/ headers) which all cannot affect the end-user's oauth's oauth/token result which always return the msg "invalid grant". what I really want to pass the authentication URL result message to the end-users to let the users know what is wrong such as incorrect username
Thanks for your kindly help
Unfortunately, it seems that in APIC v5 it is not possible to adjust OAuth error based on the response from Authentication URL call.
You can check DataPower XSLT code which handles this case (local:/isp/aaa-ldap-lib.xsl) to see more details. For any non-200 response code returned by an authentication URL, the same hardcoded error is produced. Only a response code is checked and all response information is discarded after that check - including a response code.
In the case of non-200 response code returned by authentication URL following XSLT code is executed:
<xsl:call-template name="error">
<xsl:with-param name="code" select="'401'"/>
<xsl:with-param name="reason" select="'Unauthorized'"/>
<xsl:with-param name="challenge" select="'Basic'" />
</xsl:call-template>
That means it is not possible to distinguish between errors caused by different authentication URL responses in OAuth API assembly catch. You can catch UnauthorizedError in the created assembly in OAuth API but you would have no additional information based on which you could create custom error response.
However, if you are using on-premise APIC v5 and you have access to the DataPower Gateway you could:
change mentioned xsl file to propagate status code/reason from authentication URL (possibly using gateway extensions)
info necessary, add a custom assembly to your OAuth API where you would catch UnauthorizedError and add GatewayScript code to adjust behavior
GatewayScript code to adjust behavior in case of UnauthorizedError caught would be something like:
let p = session.name('policy');
let e = p.getVariable('fw/exception');
let statusCode = e.httpCode;
let statusReason = e.httpReasonPhrase;
...

Integrating Spring SAML as SP and SimpleSAMLphp as IdP (HoK profile)

I am trying to get HoK profile work with Spring SAML as the SP and SimpleSAMLphp as the IdP.
The SP gets the client certificate and then sends the following authentication request to the IdP without problem:
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:AuthnRequest
AssertionConsumerServiceURL="https://sp.com/saml/HoKSSO"
Destination="https://localhost:8443/simplesaml/saml2 /idp/SSOService.php"
ForceAuthn="false" ID="a5ba2704fgc63887442i9i1298904fh"
IsPassive="false" IssueInstant="2015-10-04T11:26:47.393Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.com/saml/metadata</saml2:Issuer>
</saml2p:AuthnRequest>
In response, the IdP requests for the client certificate during TLS handshake and then gets his username/password and authenticates him successfully. It sends the following response:
<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response Destination="https://sp.com/saml/HoKSSO"
ID="_94c3201b7ae79d95f8ef289705c406bd61b8ed81f1"
InResponseTo="a5ba2704fgc63887442i9i1298904fh"
IssueInstant="2015-10-04T11:26:47Z" 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>https://localhost:8443/simplesaml/saml2/idp/metadata.php</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion ID="_b703fd12c6692e7a5d431d539888fcb01171a41f92"
IssueInstant="2015-10-04T11:26:47Z" Version="2.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saml:Issuer>https://localhost:8443/simplesaml/saml2/idp/metadata.php</saml:Issuer>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" SPNameQualifier="https://sp.com/saml/metadata">b9bdc06e4c25f5a464c6d5586394d6922031bd1d</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml:SubjectConfirmationData
InResponseTo="a5ba2704fgc63887442i9i1298904fh"
NotOnOrAfter="2015-10-04T11:31:47Z" Recipient="https://sp.com/saml/HoKSSO">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIFiDCCA3CgAwIBAgIQbAEaDQN5v8UJ7CM03ArefzANBgkqhkiG9w0BAQsFADBJMQswCQYDVQQGEwJJUjEYMBYGA1UECgwPSXJhbiBHb3Zlcm5tZW50MSAwHgYDVQQDDBdUZXN0QmVkMiBJUkFOIEFkbWluIENBMTAeFw0xMzExMTExMjQyNTdaFw0xNTExMTExMjQyNTdaMEsxCzAJBgNVBAYTAklSMQ0wCwYDVQQKDAROT0NSMRYwFAYDVQQDDA1oIGFtaXJpIC0gU0NMMRUwEwYDVQQFEwxpcjA1Njk5NTk1OTQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSTKy+pttM92iH9EIo5eBiI8aJRTfLAUrjY7Wsts4qJjj08CCrYsFdw6PLVFRhOCG8xK1YXQ+vgl3FBFDrJVj3Gg43izirUoDANCGIvABMrOekRfR62YRDpah7A8e4tA27Uo7WBPqhISClyUvRifDZSYVsf08vQZCE48jEUpaxDhhLW1gED82a5dGDbR9S6PauVLsSR4z4mkPGMxLiERIgTimcpUyt1bMRcFGAQIQs0NGNssH6CHOWWBfPICFwixvoejWjMjgwWCNGBuQduuIu2nqYIJ5eoNh+8kUIcS77RTcNZnUki8fkbIvZpl9yuS85L8OADfThf+AZpPCXar0RAgMBAAGjggFoMIIBZDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQogn5DJWYIWEPWrkh1e7hZWqBApDAfBgNVHSMEGDAWgBQgILBuWsWyApOxBN+fWtk5GuDPjjAOBgNVHQ8BAf8EBAMCBaAwCQYDVR0gBAIwADAfBgNVHSUEGDAWBggrBgEFBQcDAgYKKwYBBAGCNxQCAjA9BgNVHREENjA0gRRpcjA1Njk5NTk1OTRAaXJhbi5pcqAcBgorBgEEAYI3FAIDoA4MDGlyMDU2OTk1OTU5NDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vQ1JMRFBUb0JlRGVmaW5lZC9BUkwvVGVzdEJlZDJJUkFOQWRtaW5DQTEuY3JsMFIGCCsGAQUFBwEBBEYwRDBCBggrBgEFBQcwAoY2aHR0cDovL3BrZC5pcmFuaWQuaXIvL0NBQ2VydHMvVGVzdEJlZDJJUkFOQWRtaW5DQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQBoxP6xmLLdNCsdQ1S6cP/ZhadtCXiVdnvjnQOr43iTHRwdHIcGuQyMpmOQFAi/IhvPMWXK2DAnCW3UQi4csZpAl0MtRQU+BpCOzb47sihqxJX69hKXQQUHRYpyzAXBoA0yFfqKM/Q1MoqqZD/z4y3Anma7vF1vlGqWYRqHSY/jSa+10IlEw4WHC24FCw06Tz8w2h3MFfrzB+vDBZ6jndy5c2+XEFdIGdk/8QFYndkC9lfrpfVDEl8Qq6P+dyZPIA8fFCfE/4qadhMsytU9bmwq92K3/wXKjg0dnJJte+zC9O8qqCU5aBmIIGiaB5NIQaSmZXMFeFcgwKzPtyUZVOosTyeDwrhDiSaup2EU2UapGlPyl6FM6BrGu1gdSRSjOJd2YOM0y7GFP/2TqImLC7wREI5eK/zjDZyNjE5XOA7eZkODgZy+sD5Zj9pKsZYCQxRSZe16awnIZ5QWERVUNKjQgm9BPx1evLE4rCxj6e1aorecR/uJjKtUjuJNxF+DI83Rnj3TBIzyxPM0YEB8iro0qBzEO6MVnVR251qYpN0Mu3qHJk9kHa+RwK7gpIiC/gqN/u/O+D4h0tFJ/dfE6UP3SR0et/Hs3Yby0hhyt3C7UgXHEyVGSkyr1yYUrdQK2Qyoktv9xCqUwZ+OFiHECBC9ZaF8kqPi9VsVqf5OjX9TQg==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</saml:SubjectConfirmationData>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2015-10-04T11:26:17Z" NotOnOrAfter="2015-10-04T11:31:47Z">
<saml:AudienceRestriction>
<saml:Audience>https://sp.com/saml/metadata</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2015-10-04T11:08:06Z"
SessionIndex="_2e1ddd44e4b2215a074312dc7a1e31865dd940f49f" SessionNotOnOrAfter="2015-10-04T19:26:47Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">student</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">member</saml:AttributeValue>
<saml:AttributeValue xsi:type="xs:string">student</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
Everything seems OK but Spring SAML throws the following exception:
org.springframework.security.authentication.AuthenticationServiceException: Error validating SAML message
at org.springframework.security.saml.SAMLAuthenticationProvider.authenticate(SAMLAuthenticationProvider.java:95)
at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:167)
at org.springframework.security.saml.SAMLProcessingFilter.attemptAuthentication(SAMLProcessingFilter.java:87)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:217)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:213)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:184)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:64)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:53)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:91)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at org.springframework.security.web.access.channel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:152)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at org.springframework.security.saml.metadata.MetadataGeneratorFilter.doFilter(MetadataGeneratorFilter.java:87)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:213)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:176)
at org.springframework.security.web.debug.DebugFilter.invokeWithWrappedRequest(DebugFilter.java:75)
at org.springframework.security.web.debug.DebugFilter.doFilter(DebugFilter.java:62)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:221)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:107)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:76)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:934)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:90)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:515)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1012)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:642)
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1597)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1555)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: org.opensaml.common.SAMLException: Response doesn't have any valid assertion which would pass subject validation
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:229)
at org.springframework.security.saml.SAMLAuthenticationProvider.authenticate(SAMLAuthenticationProvider.java:84)
... 43 more
Caused by: org.opensaml.common.SAMLException: Assertion invalidated by subject confirmation - can't be confirmed by holder-of-key method
at org.springframework.security.saml.websso.WebSSOProfileConsumerHoKImpl.verifySubject(WebSSOProfileConsumerHoKImpl.java:150)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOProfileConsumerImpl.java:296)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:214)
... 44 more
Spring SAML debugging logs here:
8532 [http-nio-443-exec-9] DEBUG - Evaluating security policy of type 'org.opensaml.ws.security.provider.BasicSecurityPolicy' for decoded message
8532 [http-nio-443-exec-9] DEBUG - Evaluating simple signature rule of type: org.opensaml.saml2.binding.security.SAML2HTTPPostSimpleSignRule
8532 [http-nio-443-exec-9] DEBUG - HTTP request was not signed via simple signature mechanism, skipping
8532 [http-nio-443-exec-9] INFO - SAML protocol message was not signed, skipping XML signature processing
8532 [http-nio-443-exec-9] DEBUG - Successfully decoded message.
8532 [http-nio-443-exec-9] DEBUG - Checking SAML message intended destination endpoint against receiver endpoint
8533 [http-nio-443-exec-9] DEBUG - Intended message destination endpoint: https://cmks.irannid.ir/saml/HoKSSO
8533 [http-nio-443-exec-9] DEBUG - Actual message receiver endpoint: https://cmks.irannid.ir/saml/HoKSSO
8533 [http-nio-443-exec-9] DEBUG - SAML message intended destination endpoint matched recipient endpoint
8533 [http-nio-443-exec-9] DEBUG - Found endpoint org.opensaml.saml2.metadata.impl.AssertionConsumerServiceImpl#38620660 for request URL https://cmks.irannid.ir/saml/HoKSSO based on location attribute in metadata
8534 [http-nio-443-exec-9] DEBUG - Authentication attempt using org.springframework.security.saml.SAMLAuthenticationProvider
8534 [http-nio-443-exec-9] DEBUG - Verifying issuer of the Response
8535 [http-nio-443-exec-9] DEBUG - Processing Holder-of-Key subject confirmation
8535 [http-nio-443-exec-9] DEBUG - HoK SubjectConfirmation invalidated by confirmation data not being of KeyInformationDataType type
8535 [http-nio-443-exec-9] DEBUG - Validation of authentication statement in assertion failed, skipping
The error is: HoK SubjectConfirmation invalidated by confirmation data not being of KeyInformationDataType type. It seems that Spring SAML could not find KeyInfo in the response!!
Can anybody help me resolve this problem?
Thank you
Edit:
By comparing with sample HoK SSO responses, it sees that SimpleSAMLphp has not added xsi:type="saml:KeyInfoConfirmationDataType" to the SubjectConfirmationData tag. Can it be the reason of the above exception?
Is it a mandatory attribute for the SubjectConfirmationData tag in SAML2.0 HoK profile?
Finally I found the solution:
SimpleSAMLphp does not add xsi:type="saml:KeyInfoConfirmationDataType" to the "SubjectConfirmationData" tag, because the standard does not mandate it:
329 3.1 Holder of Key
330 URI: urn:oasis:names:tc:SAML:2.0:cm:holder-of-key
331 One or more <ds:KeyInfo> elements MUST be present within the <SubjectConfirmationData>
332 element. An xsi:type attribute MAY be present in the <SubjectConfirmationData> element and, if
333 present, MUST be set to saml:KeyInfoConfirmationDataType (the namespace prefix is arbitrary but
334 must reference the SAML assertion namespace).
I changed the simplesamlphp code and added the missing attribute manually. (I'm still not sure whether I added in the right place or not but it works by now!)
But the new question is who must resolve this problem? Spring SAML or simpleSAMLphp?
By this change, Spring SAML detects that SubjectConfirmationData tag contains one or more elements, then it finds the client certificate embedded in the response and tries to compare it with the one received during TLS client authentication.
Although the two certificates are identical, Spring SAML says they don't match, since one of them has break lines and the other does not.
My only remaining my question is:
which approach is compatible with standard? adding break lines in base64-encoded certificates or removing them or even comparing with and without break lines?

Spring SAML integration with WSO2 Identity server, SAML Message ID not reconised

I have taken the Spring SAML example (see section 4.2 in this guide) which works with the Open source login page SSO, and tried to add support to use WSO2 Identity Server as an additional IDP service.
To do this I changed the spring SAML sample project by adding a metadata xml file for IS, and added an entry for the IS metadata to the securityContext.xml.
On running the spring application I now get presented with an option to login using IS, and I can successfully login in on WSO2 when I'm redirected to it. However the spring application throws an exception on the IS SAML response about it not matching the InResponseToField.
2015-01-05 09:54:12,845 line="org.springframework.security.saml.log.SAMLDefaultLogger.log(SAMLDefaultLogger.java:127)" thread="http-nio-8080-exec-4" class="org.springframework.security.saml.log.SAMLDefaultLogger" AuthNResponse;FAILURE;0:0:0:0:0:0:0:1;com:vdenotaris:spring:sp;localhost;;;org.opensaml.common.SAMLException: InResponseToField of the Response doesn't correspond to sent message ae2dab0fb8b0g8e49971b91a73e91i
From debugging the application it appears the response message is not recognised as belonging to the same session as the request message. I say that from these 2 log messages, 1st is logged when sending the AuthRequest and the 2nd is when the response is received:
2015-01-05 09:53:20,867 line="org.springframework.security.saml.storage.HttpSessionStorage.storeMessage(HttpSessionStorage.java:93)" thread="http-nio-8080-exec-1" class="org.springframework.security.saml.storage.HttpSessionStorage" Storing message ae2dab0fb8b0g8e49971b91a73e91i to session 26D3B7D9E33F26A7A5092BF6909B9D13
...
2015-01-05 09:54:10,731 line="org.springframework.security.saml.storage.HttpSessionStorage.retrieveMessage(HttpSessionStorage.java:117)" thread="http-nio-8080-exec-4" class="org.springframework.security.saml.storage.HttpSessionStorage" Message ae2dab0fb8b0g8e49971b91a73e91i not found in session BBF256F284F55D774E6997600E9B3388
The IS SAML response is:
<?xml version="1.0" encoding="UTF-8"?><saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="http://localhost:8080/saml/SSO" ID="adlbklpnldoanfphalcaahhacooinnldcejjjioe" InResponseTo="ae2dab0fb8b0g8e49971b91a73e91i" IssueInstant="2015-01-05T09:53:38.063Z" 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">localhost</saml2:Issuer>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="ebhfkdhlgbhclcklefjigfddoikklhjlanlbolel" IssueInstant="2015-01-05T09:53:38.065Z" Version="2.0">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">localhost</saml2:Issuer>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">smit005</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="ae2dab0fb8b0g8e49971b91a73e91i" NotOnOrAfter="2015-01-05T09:58:38.063Z" Recipient="http://localhost:8080/saml/SSO"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2015-01-05T09:53:38.065Z" NotOnOrAfter="2015-01-05T09:58:38.063Z">
<saml2:AudienceRestriction>
<saml2:Audience>com:vdenotaris:spring:sp</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2015-01-05T09:53:38.068Z" SessionIndex="406d4530-6fcf-4edf-b876-a68de4b4ea79">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement/>
</saml2:Assertion>
</saml2p:Response>
For reference I attach the metadata xml file I added for WSO2 IS (I had to give it an entityID of 'localhost' as this was what WSO2 IS insists on returning (it uses the host name by default)).
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="localhost"
validUntil="2023-09-23T06:57:15.396Z">
<md:IDPSSODescriptor WantAuthnRequestsSigned="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>MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UE
CAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxv
Y2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQsw
CQYDVQQIDAJDQTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzENMAsGA1UECgwEV1NPMjESMBAGA1UE
AwwJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUp/oV1vWc8/TkQSiAvTou
sMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5
HpwvnH/DW8ZccGvk53I6Orq7hLCv1ZHtuOCokghz/ATrhyPq+QktMfXnRS4HrKGJTzxaCcU7OQID
AQABoxIwEDAOBgNVHQ8BAf8EBAMCBPAwDQYJKoZIhvcNAQEFBQADgYEAW5wPR7cr1LAdq+IrR44i
QlRG5ITCZXY9hI0PygLP2rHANh+PYfTmxbuOnykNGyhM6FjFLbW2uZHQTY1jMrPprjOrmyK5sjJR
O4d1DeGHT/YnIjs9JogRKv4XHECwLtIVdAbIdWHEtVZJyMSktcyysFcvuhPQK8Qc/E/Wq8uHSCo=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://localhost:9443/samlsso" ResponseLocation="https://localhost:9443/samlsso"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://localhost:9443/samlsso"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://localhost:9443/samlsso"/>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
</md:IDPSSODescriptor>
</md:EntityDescriptor>
As requested I've saved a log of the browser HTTP messages on dropbox.
Both Spring SAML and your IDP WSO2 server are deployed on the same domain - localhost. This is what happens:
Spring SAML creates an HTTP session (JSESSIONID - 82F3ECD1A1E4F9B7DB0134F3129267A5) and initializes single sign-on
WSO2 accepts the request and authenticates the user, but creates its own session (JSESSIONID -C34B21931C53080487B5B9BA6EB490D2) and redirects user back to Spring SAML
container running Spring SAML receives the cookie with JSESSIONID (C34B21931C53080487B5B9BA6EB490D2), but as it doesn't recognize such session it creates a new one (E712A8422009613F6FD3901327690726)
Spring SAML tries to verify received SAML message based on the original request, but it cannot be found because the original session is now gone
The easiest way to fix this is to change session cookie name for Spring SAML or WSO2. You could also deploy your applications on different domains (for example by giving your localhost an alias in the hosts file - /etc/hosts or %systemroot%\system32\drivers\etc\hosts)

"HTTP Status 401 - Authentication Failed: Incoming SAML message is invalid" with Salesforce as IdP for implementating SSO

I've implemented SSO using Spring SAML and everything is working fine. It worked with the following IDP's till now:
1) idp.ssocircle.com
2) openidp.feide.no
Now I'm testing with salesforce.com as my Identity Provider. As there is no provision to upload Service Provider Metadata I've done the following configuration settings at its IdP:
Gave my entityID and Assertion Consumer Service URL. I also uploaded my SP certificate. I've downloaded its metadata (idp metadata) which is as follows (hiding the sensitive information):
<?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://ABC-dev-ed.my.salesforce.com" validUntil="2024-04-11T13:55:57.307Z">
<md:IDPSSODescriptor WantAuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>XXXXXXXXX</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ABC-dev-ed.my.salesforce.com/idp/endpoint/HttpPost"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://ABC-dev-ed.my.salesforce.com/idp/endpoint/HttpRedirect"/>
Now when I tried to test my SP, first it redirected me to the IDP(salesforce) asking for credentials where I entered them but then after that I was redirected back to my Assertion consumer Service URL(which is my SP) but here an exception was generated saying that
HTTP Status 401 - This request requires HTTP authentication(Authentication Failed: Incoming SAML message is invalid).
I've tried the following but didn't work :( -
Though not necessary, I've downloaded the certificate file from the salesforce and imported it to my keystore.jks so that to make sure that key is used for signature validation.(Not necessary due to the certificate info already present in IDP metadata).
Here is what I found in my log file(Adding necessary info only after successful AuthnRequest):
AuthNRequest;SUCCESS;127.0.0.1
.....STARTED_FAILING_HERE.....
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
Registry could not locate evaluable criteria for criteria class org.opensaml.xml.security.keyinfo.KeyInfoCriteria
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 validated with key from supplied credential
Signature validation using candidate credential was successful
Successfully verified signature using KeyInfo-derived credential
Attempting to establish trust of KeyInfo-derived credential
Failed to validate untrusted credential against trusted key
Failed to establish trust of KeyInfo-derived credential
Failed to verify signature and/or establish trust using any KeyInfo-derived credentials
Attempting to verify signature using trusted credentials
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
org.opensaml.xml.validation.ValidationException: Signature did not validate against the credential's key
at org.opensaml.xml.signature.SignatureValidator.validate(SignatureValidator.java:79)
at org.opensaml.xml.signature.impl.BaseSignatureTrustEngine.verifySignature(BaseSignatureTrustEngine.java:142)
at org.opensaml.xml.signature.impl.ExplicitKeySignatureTrustEngine.validate(ExplicitKeySignatureTrustEngine.java:110)
at org.opensaml.xml.signature.impl.ExplicitKeySignatureTrustEngine.validate(ExplicitKeySignatureTrustEngine.java:49)
at org.opensaml.ws.security.provider.BaseTrustEngineRule.evaluate(BaseTrustEngineRule.java:104)
at org.opensaml.ws.security.provider.BaseTrustEngineRule.evaluate(BaseTrustEngineRule.java:91)
at org.opensaml.common.binding.security.SAMLProtocolMessageXMLSignatureSecurityPolicyRule.doEvaluate(SAMLProtocolMessageXMLSignatureSecurityPolicyRule.java:128)
at org.opensaml.common.binding.security.SAMLProtocolMessageXMLSignatureSecurityPolicyRule.evaluate(SAMLProtocolMessageXMLSignatureSecurityPolicyRule.java:107)
at org.opensaml.ws.security.provider.BasicSecurityPolicy.evaluate(BasicSecurityPolicy.java:51)
at org.opensaml.ws.message.decoder.BaseMessageDecoder.processSecurityPolicy(BaseMessageDecoder.java:132)
at org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:83)
at org.opensaml.saml2.binding.decoding.BaseSAML2MessageDecoder.decode(BaseSAML2MessageDecoder.java:70)
at org.springframework.security.saml.processor.SAMLProcessorImpl.retrieveMessage(SAMLProcessorImpl.java:105)
at org.springframework.security.saml.processor.SAMLProcessorImpl.retrieveMessage(SAMLProcessorImpl.java:172)
at org.springframework.security.saml.SAMLProcessingFilter.attemptAuthentication(SAMLProcessingFilter.java:77)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:195)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:166)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:403)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:301)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:162)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:140)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Failed to verify signature using either KeyInfo-derived or directly trusted credentials
Validation of protocol message signature failed for context issuer 'https://ABC-dev-ed.my.salesforce.com', message type: {urn:oasis:names:tc:SAML:2.0:protocol}Response
Authentication request failed: org.springframework.security.authentication.AuthenticationServiceException: Incoming SAML message is invalid
Updated SecurityContextHolder to contain null Authentication
Delegating to authentication failure handler org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler#153a591
Can someone please tell me what is going wrong by looking at the above log. Any help would be highly appreciated.
Thanks,
Abhilash
Your IDP is using a different key for digital signatures than it defines in metadata.
You should inspect the SAML message you received and look for element X509Certificate inside element Signature. Extract the content of the certificate into a separate file, e.g. sales-force-sign.cer
You then need to import the certificate into your samlKeystore.jks, you can find details on how to do it in chapter 4.5 (Key management) of the Spring SAML manual. Make sure to note the alias you import the key with.
As last step you need to tell Spring SAML to use the newly imported key for signature verifications for your IDP, for that you should update your securityContext.xml and update your ExtendedMetadta for your IDP with property signingKey and value of the alias you used earlier to import the key. It will look similar to:
<bean class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
<constructor-arg>
<bean class="org.opensaml.saml2.metadata.provider.FilesystemMetadataProvider">
<constructor-arg>
<value type="java.io.File">classpath:salesforce_metadata.xml</value>
</constructor-arg>
<property name="parserPool" ref="parserPool"/>
</bean>
</constructor-arg>
<constructor-arg>
<bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
<property name="signingKey" value="sf-proxy"/>
</bean>
</constructor-arg>
</bean>
Again you can find details on all of this in the manual.
Alternatively you can simply add the key you extracted from the message into your IDP metadata. Just manualy update the XML file and add another KeyDescriptor with use="signing". It might be faster to do.

How to get SAML2 Bearer Assertion profile for OAuth within WSO2 API Manager to work?

I have problems getting work "SAML2 Bearer Assertion profile for Oauth" within WSO2 API Manager. I'm trying to apply "Johann's Wall" How-to on API Manager (ver. 1.5) but running in the following error.
[2013-11-08 17:44:35,930] DEBUG - SAML2BearerGrantTypeHandler SAML Assertion Audience Restriction validation failed
[2013-11-08 17:44:36,024] DEBUG - AccessTokenIssuer Invalid Grant provided by the client, id=enfKWsilmCxdIwhYiINcoA2JKwka, user-name=admin to application=MyFlowChart
[2013-11-08 17:44:36,025] DEBUG - AccessTokenIssuer OAuth-Error-Code=invalid_grant client-id=enfKWsilmCxdIwhYiINcoA2JKwka grant-type=urn:ietf:params:oauth:grant-type:saml2-bearer scope=
Checking the code of org.wso2.carbon.identity.oauth2.token.handlers.grant.saml.SAML2BearerGrantTypeHandler this error should only come up if none of the "Identity Provider Audience" entries in the configured "Trusted Identity Provider" matches the <saml:Audience> values within SAML assertion. But comparing the configuration and the SAML assertion (see below) for me everthing looks good.
Hopefully someone can help me out or give me hint want's going wrong...
Setup / Configuration
1.) Setup "Trusted Identity Providers" in API Manager (see screenshot)
2.) Creating a SAML2 Assertion via SAML2AssertionCreator.jar
<?xml version="1.0" encoding="UTF-8"?>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="mkfeiofmkjmjpicmdllnaapcmjlimjmajdiejiip" IssueInstant="2013-11-08T16:43:41.877Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">OAuthPlayground</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="#mkfeiofmkjmjpicmdllnaapcmjlimjmajdiejiip">
<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#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds saml xs xsi"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>bNaQFYpcakb07xbUpUdVuSidvuA=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>gUe0mXTRPD79HTz7[...]</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIFrDCCBJSgAwIBA[...]</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">admin</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="0" NotOnOrAfter="2013-11-08T16:48:41.877Z" Recipient="https://sl02502.apps.eon.com:9443/oauth2endpoints/token"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2013-11-08T16:43:41.877Z" NotOnOrAfter="2013-11-08T16:48:41.877Z">
<saml:AudienceRestriction>
<saml:Audience>restriction</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2013-11-08T16:43:41.945Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute>
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">a</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
3.) Running "curl" with base64 encoded SAML assertion against OAuth endpoint of API Manager
curl -k -X POST -u "enfKWsilmCxdIwhYiINcoA2JKwka:eEfmtoFRFyl3JIhMH1jM0bbXbkMa" -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -d "grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer&assertion=PD94bWwgdm[...]0aW9uPg%3D%3D" https://sl02502.apps.eon.com:9445/oauth2/token
The problem is in your SAML2 Assertion. You cannot find a Audience element which has the OAuth2 token endpoint as an audience. The only audience you have is "restriction". For the saml2-bearer grant type to work you need to have the OAuth2 token endpoint as an audience for the assertion.
What you need to do is when generating the SAML2 assertion using "SAML2AssertionCreator.jar" you need to specify multiple audiences using comma separated values.
E.g. https://sl02502.apps.eon.com:9445/oauth2/token,restriction
In fact the only audience you need to get saml2-bearer grant type working is the token endpoint. I.e. you don't need to specify any audience at all in the 'Trusted Identity Provider' configuration. If you do specify any audience here, then you need to make sure those audiences are coming in the SAML2 Assertion. This is useful in scenarios where this SAML2 Assertion will be used by other relying parties in addition to the token endpoint. In your case if you don't have such requirement you could remove the audience called 'restriction' from both the 'Trusted Identity Provider' configuration and the assertion or if you need such an audience you must have it in both places.

Resources