I have an error with Cas when i try login, the logs fron the error are the next, i've self signed certificate and already add these to my keystore and and the keystore to the cacerts
thx for the help
These is the log from CAS
ServiceValidateController [ERROR] TicketException generating ticket for: [callbackUrl: https://localhost:8443/receptor]
org.jasig.cas.ticket.TicketCreationException: error.authentication.credentials.bad
at org.jasig.cas.CentralAuthenticationServiceImpl.delegateTicketGrantingTicket(CentralAuthenticationServiceImpl.java:291)
at org.jasig.cas.web.ServiceValidateController.handleRequestInternal(ServiceValidateController.java:126)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.jasig.cas.web.init.SafeDispatcherServlet.service(SafeDispatcherServlet.java:115)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.inspektr.common.web.ClientInfoThreadLocalFilter.doFilterInternal(ClientInfoThreadLocalFilter.java:48)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:722)
Caused by: error.authentication.credentials.bad
at org.jasig.cas.authentication.handler.BadCredentialsAuthenticationException.<clinit>(BadCredentialsAuthenticationException.java:25)
at org.jasig.cas.authentication.AuthenticationManagerImpl.authenticate(AuthenticationManagerImpl.java:113)
at org.jasig.cas.CentralAuthenticationServiceImpl.delegateTicketGrantingTicket(CentralAuthenticationServiceImpl.java:262)
... 26 more
These is the log from Ldap
geobolivia slapd[3024]: conn=1003 op=3 SRCH base="ou=users,dc=geobolivia,dc=gob,dc=bo" scope=2 deref=3 filter="(uid=geobolivia)"
geobolivia slapd[3024]: conn=1003 op=3 SEARCH RESULT tag=101 err=0 nentries=0 text=
geobolivia slapd[3024]: conn=1003 op=4 SRCH base="ou=users,dc=geobolivia,dc=gob,dc=bo" scope=2 deref=3 filter="(uid=_cas_stateful_)"
geobolivia slapd[3024]: conn=1003 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text=
And these is the log from Security-proxy
ProxyGrantingTicketStorageImpl [INFO] No Proxy Ticket found for
FilterBasedLdapUserSearch [DEBUG] Searching for user 'geobolivia', with user search [ searchFilter: '(uid={0})', searchBase: 'ou=users', scope: subtree, searchTimeLimit: 0, derefLinkFlag: false ]
AbstractContextSource [DEBUG] Got Ldap context on server 'ldap://localhost:389/dc=geobolivia,dc=gob,dc=bo'
SpringSecurityLdapTemplate [DEBUG] Searching for entry in under DN 'dc=geobolivia,dc=gob,dc=bo', base = 'ou=users', filter = '(uid={0})'
ProviderManager [DEBUG] Authentication attempt using org.springframework.security.ldap.authentication.LdapAuthenticationProvider
LdapAuthenticationProvider [DEBUG] Processing authentication request for user: _cas_stateful_
FilterBasedLdapUserSearch [DEBUG] Searching for user '_cas_stateful_', with user search [ searchFilter: '(uid={0})', searchBase: 'ou=users', scope: subtree, searchTimeLimit: 0, derefLinkFlag: false ]
AbstractContextSource [DEBUG] Got Ldap context on server 'ldap://localhost:389/dc=geobolivia,dc=gob,dc=bo'
SpringSecurityLdapTemplate [DEBUG] Searching for entry in under DN 'dc=geobolivia,dc=gob,dc=bo', base = 'ou=users', filter = '(uid={0})'
2013-08-29 18:29:15 CasAuthenticationFilter [DEBUG] Authentication request failed: org.springframework.security.authentication.BadCredentialsException: Bad credentials
2013-08-29 18:29:15 CasAuthenticationFilter [DEBUG] Updated SecurityContextHolder to contain null Authentication
CasAuthenticationFilter [DEBUG] Delegating to authentication failure handlerorg.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler#1e6ba8ee
SimpleUrlAuthenticationFailureHandler [DEBUG] No failure URL set, sending 401 Unauthorized error
HttpSessionSecurityContextRepository [DEBUG] SecurityContext is empty or anonymous - context will not be stored in HttpSession.
SecurityContextPersistenceFilter [DEBUG] SecurityContextHolder now cleared, as request processing completed
This is very similar to: CAS credentials bad
Basically CAS is trying to call the client app because it is trying to deliver a PGT, but the client app isn't answering on the callback url.
Related
I am using IdentityServer3 with EF. I have API project and i want to authenticate its access using access token.
So based on sample i have configured client ( for API project) in identity server as below
Client Properties
Client Secret
(Note whatever the text i put as secret value, the admin UI automatically convert it)
Scope
Then using POSTMAN i am trying get access token, but i always get invalid_client error
I have also tried getting access token using C# code, but get the same error
static TokenResponse GetClientToken()
{
var client = new TokenClient(
"https://xxxxxxxx/connect/token",
"A0AD7FB8-2881-484F-xxxxxxxxxxxxxxxxxx",
"a84iThYxAA5eZpkIzt9xxxxxxxxxxxxxxxxxx");
return client.RequestClientCredentialsAsync("api").Result;
}
Update 1
Here is what i see in identity server's log
2018-12-21 19:29:59.284 +00:00 [Information] Start token request
2018-12-21 19:29:59.301 +00:00 [Debug] Start client validation
2018-12-21 19:29:59.302 +00:00 [Debug] Start parsing Basic Authentication secret
2018-12-21 19:29:59.302 +00:00 [Debug] Start parsing for secret in post body
2018-12-21 19:29:59.304 +00:00 [Debug] Parser found secret: "PostBodySecretParser"
2018-12-21 19:29:59.304 +00:00 [Information] Secret id found: "A0AD7FB8-2881-484F-ABE0-xxxxxxxx"
2018-12-21 19:29:59.943 +00:00 [Debug] Skipping secret: no description, secret is not of type SharedSecret.
2018-12-21 19:29:59.943 +00:00 [Debug] No matching hashed secret found.
2018-12-21 19:29:59.943 +00:00 [Information] Secret validators could not validate secret
2018-12-21 19:29:59.944 +00:00 [Information] Client validation failed.
2018-12-21 19:29:59.945 +00:00 [Information] End token request
2018-12-21 19:29:59.946 +00:00 [Information] Returning error: invalid_client
Update 2
(The the secret value is updated than what i have posted earlier)
Try secret type as SharedSecret instead of clientsecret. Identity Server 3 has the below secret types:
SharedSecret
X509Thumbprint
X509Name
X509CertificateBase64
Taken from Identity Server 3 source
Also, additionally you seem to be using hash value of the secret when sending auth requests a84iThYxAA5eZpkIzt9xxxxxxxxxxxxxxxxxx, however, you need to use the plain text value that you used to create the secret. (58b9....)
You could encounter invalid_client error in the different, quite curious case.
Updating IdentityServer3.EntityFramework (IS3.EF) to 2.5.1 seems to cause a change in both client secret and scope secret's default behaviour. Below this version even if you don't provide value for secret type in a database (leaving it as null) Identity Server will treat it as "SharedSecret". It sets it as such in class's constructor at the application level.
However, the newer IS.EF3 package contains an update of AutoMapper to 5.0 version. This update as a side effect seems to stop executing default constructors (with given configuration). This way setting client secret type in the database becomes de facto mandatory. Otherwise, you get invalid_client error, because secrets don't match their type.
It looks like authors intended to fix this behaviour change, but the branch hasn't been merged into master up till now:
ID3.EF - idea_for_setting_defaults_on_entities
Be advised, there already is Identity Server 4, so the merge may never occur.
I'm currently evaluation AppAuth (https://appauth.io/) for use in a native mobile app together with a STS which currently uses IdentityServer3. I've configured a client like this:
new IdentityServer3.Core.Models.Client
{
Enabled = true,
ClientId = "app",
ClientName = "app",
ClientUri = "app:/",
Flow = Flows.AuthorizationCodeWithProofKey,
RequireConsent = false,
RequireSignOutPrompt = false,
SlidingRefreshTokenLifetime = 28800,
AllowAccessTokensViaBrowser = true,
RedirectUris = new List<string>
{
"app:/signin"
},
PostLogoutRedirectUris = new List<string>
{
"app:/signout"
},
AllowedScopes = new List<string>
{
StandardScopes.OpenId.Name.Name,
StandardScopes.Email.Name.Name,
StandardScopes.Profile.Name.Name,
StandardScopes.Roles.Name.Name,
StandardScopes.OfflineAccess.Name,
}
}
The initial authorize request succeeds and IdentityServer3 returns an authorization code. Now I tried a subsequent token request, and this results in an HTTP 400 with an invalid_client error and the following messages in the IdentityServer3 log:
2018-04-17 10:16:38.324 +02:00 [Information] Start token request
2018-04-17 10:16:38.324 +02:00 [Debug] Start client validation
2018-04-17 10:16:38.324 +02:00 [Debug] Start parsing Basic Authentication secret
2018-04-17 10:16:38.324 +02:00 [Debug] Start parsing for secret in post body
2018-04-17 10:16:38.324 +02:00 [Debug] No secret in post body found
2018-04-17 10:16:38.324 +02:00 [Debug] Start parsing for X.509 certificate
2018-04-17 10:16:38.324 +02:00 [Debug] X.509 certificate not found.
2018-04-17 10:16:38.324 +02:00 [Information] Parser found no secret
2018-04-17 10:16:38.324 +02:00 [Information] No client secret found
2018-04-17 10:16:38.324 +02:00 [Information] End token request
2018-04-17 10:16:38.324 +02:00 [Information] Returning error: invalid_client
Do I understand something wrong or why doesn't IdentityServer3 return an access token?
You need to authenticate Client in token request for Authorization Code flow. So you need to set ClientSecrets for your client.
new IdentityServer3.Core.Models.Client
{
/// your properties
ClientSecrets = new List<Secret>
{
new Secret("secret".Sha256())
}
}
And you need to send client_secret as a query string in your token request.
Or you can use BasicAuthentication. In this case you need to add Base64(ClientId:ClientSecret) in authentication header.
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.
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?
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.