A client is trying to SSO into our app using SAML and our app throws followimg exception
org.opensaml.xml.security.SecurityException: SAML message intended destination endpoint did not match recipient endpoint.
The reason for this exception was missing Destination attribute in the Response element in the the assertion client was sending us. The Response needed to be something like:
<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" ID="_a8590dae-831c-4142-9fc9-a15f60e972a0" Version="2.0" IssueInstant="2012-02-22T17:08:57Z" Destination="https://client.ourapp.com/product/AssertionConsumer" xmlns="urn:oasis:names:tc:SAML:2.0:protocol">
The Destination attribute needed to contain our assertion consumer url.
Related
If SAML Response has the status as "status:Responder",
According SAML spec:
urn:oasis:names:tc:SAML:2.0:status:Responder The request could not be performed due to an error on the part of the SAML responder or SAML authority.
We expect the IDP should send the error message along with the response.
In ADFS event viewer, we can find out why SAML request failed, however we don't have access to ADFS sever in production environment.
Is it possible to get the error message inside SAML response in case if the authentication fails?
I am reading documentation about microsoft azure active directory. Here request sample:
<samlp:AuthnRequest
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
ID="id6c1c178c166d486687be4aaf5e482730"
Version="2.0" IssueInstant="2013-03-18T03:28:54.1839884Z"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://www.contoso.com</Issuer>
</samlp:AuthnRequest>
As you can see this does not contains any login or pass. Why? How azure figure out actual credentials?
Authentication request in SAML is a trigger that initiates a sequence that leads to authentication of a principal and subsequent assertion with claims about this principal.
From SAML 2.0 spec:
When a principal (or an agent acting on the principal's behalf) wishes
to obtain assertions containing authentication statements to establish
a security context at one or more relying parties, it can use the
authentication request protocol to send an message
element to a SAML authority and request that it return a
message containing one or more such assertions.
Make a POST HTTP request to Salesforce:
https://login.salesforce.com/services/oauth2/token?
I am receiving org.glassfish.grizzly.utils.BufferInputStream#6ffb2a27
instead of a Json.
I tried to read using Object to String, Object to Json, Byte Array to Object, but all fails.
The same request works using Postman. So I believe I am not handling the return in the right way.
Below the request:
<http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8082" doc:name="HTTP Listener Configuration"/>
<http:request-config name="HTTP_Request_Configuration" host="login.salesforce.com" port="443" doc:name="HTTP Request Configuration"/>
<flow name="sfdc-authenticationFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
<http:request config-ref="HTTP_Request_Configuration" path="/services/oauth2/token?grant_type=password&client_id=3MVG9dZJodJWITSvw.rnZkDdZh_1cGietbXfzgFJEYnJ8Yjy57qnI8Q4lrlDKuW4TkvmhicgzDypbuoU6IlsJ&client_secret=6092113775661001078&username=rofernando.jaramillo#gmail.com&password=live4everzgWJgEvSxKvXeY82DV0oqdqC" method="POST" doc:name="HTTP"/>
</flow>
Anybody faced the same before?
I have tried your request and it fails with error java.io.IOException: Remotely closed. This means Salesforce closed the connection, probably something in the request is wrong. You have to be sure the HTTP request is nearly similar to the one that works in Postman. To troubleshoot that you can enable HTTP wire logging and use the Code feature in Postman to see both HTTP requests.
Note that the HTTP Listener/Requester always returns a type of InputStream that contains the actual value of the payload. You can use DataWeave to parse that.
i'm trying Okta quick start for Java tomcat SAML, I am very new to this topic.
When I start my test application I do see a link to Okta IDP, after clicking "Start single sign-on" button i am being redirected to Okta address with info "Sining in to SAML - Test" (my Okta test name) after that I'm again being redirected to my application with:
Error
Error validating SAML message
after that there is a stack trace with
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:82)
... 27 more
Caused by: org.opensaml.common.SAMLException: Local entity is not the intended audience of the assertion in at least one AudienceRestriction
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAudience(WebSSOProfileConsumerImpl.java:506)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertionConditions(WebSSOProfileConsumerImpl.java:458)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOProfileConsumerImpl.java:303)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:214)
... 28 more
What am I missing? What am I doing wrong?
Thanks for all your help Zack.
The entity ID of your Spring SAML Service Provider doesn't match Destination element in the SAML response from Okta. Compare the two values and fix the value on either Spring SAML or Okta side.
Same issue when deploying Spring Boot app in Azure Container Instance and using Okta SAML. saml.sp=http://fqdn-of-my.domain.com:8082/saml/metadata, FQDN resolved by an AWS hosted DNS zone A record, the URL itself is accessible and downloads the spring_saml_metadata.xml.
Caused by: org.opensaml.common.SAMLException: Local entity is not the intended audience of the assertion in at least one AudienceRestriction
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAudience(WebSSOProfileConsumerImpl.java:542)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertionConditions(WebSSOProfileConsumerImpl.java:494)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOProfileConsumerImpl.java:339)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:250)
... 53 more
Update after 30 minutes: I noticed that the error went away after a rebuild and redeploy of the app!!
With
saml.sp=http://fqdn-of-my.domain.com:8082/saml/metadata in Spring application.properties, the SP Metadata available at the same URL was originally the below, giving error:
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="http___localhost_8082_saml_metadata"
entityID="http://localhost:8082/saml/metadata">
A rebuild and redeployment of the app with Metadata as below resulted in successful handshake:
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="http___fqdn-of-my.domain.com_8082_saml_metadata"
entityID="http://fqdn-of-my.domain.com:8082/saml/metadata">
I am pretty sure I had the property correctly set even when it was giving error. But anyway, a rebuild of the Dockerized Spring app and redeploy of the same in Azure ultimately fixed the problem.
Following is the SAML request send to ADFS
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_84e533b7-4310-41de-8ec7-0af7afeb7979" Version="2.0" IssueInstant="2015-12-02T09:44:30Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Destination="https://XXXX.YYYY.ZZZZ/adfs/ls/" AssertionConsumerServiceURL="http://PPP.QQQ.RRR/SPDemo/Consume.aspx">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://XXXX.YYYY.ZZZZ/adfs/services/trust</saml:Issuer>
</samlp:AuthnRequest>
After compressing and converting to Base64String it is redirected to ADFS.
URL shown below with SAML request
https://XXXX.YYYY.ZZZZ/adfs/ls/?SAMLRequest=hZHNbsIwEIRfJfLdsfODAhZEouVQJKpGJO2hl8okS7Ga2KnXoTx%2bA0kluNCjrflmZ3bnKJu6FcvOHfQWvjtA561XC%2fIxjWESRbuExlHAaRxUQKdQJpTLfSL3sEtmyYx4b2BRGb0goc%2bJt0bsYK3RSe36Lx5MaBBSHhZ8JuJYRPydeJk1zpSmflC6UvpzQTqrhZGoUGjZAApXinz5vBG9o9gNIhRPRZHR7CUviLfqIyot3WXswbkWBWMaj%2fQn%2fAo5n9rQr6zqNX5tSlkzWe2R1ciIt0QEe%2bYejcauAZuDPaoSXrebwak3GtAjba2pgujWKc9W0Bg20r7E9kS8U1NrFJct3u%2fSjsVJOj%2brxWVZ9oq%2fj8u%2f8CQdo%2f7XGYd2yJzt0M3Z1dR0eN3ePf0F
But I am getting following error
Checking for detail error in Event Viewer I got
It seems that the server required the signed SAML request but I haven't mentioned anywhere that signed SAML request is required. Also SignedSamlRequestsRequired property is set to false
So, Why ADFS 2.0 is asking for signed SAML request?
Is there anything that is needed to be done so that signed SAML request is not required or if required what will be the value of signature that will signed the SAML request?
I am able to solved it.
The problem was with wrong setting of issuer in SAML request.
After setting the appropriate issuer,i.e. http://PPP.QQQ.RRR/SPDemo, as shown in following SAML Request I am able to do SP-Initiated login without any ADFS error
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_bd613bda-e506-4747-91c7-96a4d75c67fc" Version="2.0" IssueInstant="2015-12-03T05:51:52Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Destination="https://XXXX.YYYY.ZZZZ/adfs/ls/" AssertionConsumerServiceURL="https://PPP.QQQ.RRR/SPDemo//Consume.aspx">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://PPP.QQQ.RRR/SPDemo</saml:Issuer>
</samlp:AuthnRequest>
Previously used wrong issuer was http://XXXX.YYYY.ZZZZ/adfs/services/trust