I am attempting to create a custom identity provider (based on https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/tree/master/test/TestIdPCore) but using HTTT-POST binding. The issue I am having is that when the service provider tries to validate the authn response they are getting errors ("actual digest value does not match expected"). I have also attempted to use a third party tool validating the xml response and was getting an error like "The XML has been altered after signing."
I am signing the assertion on the response using a certificate in the key store on the server where the service is running.
The XML need to keep the same plain format for the signatur validation to succeed.
You probably need to debug to find the problem.
Do you IdP work with a sample RP, e.g. https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/tree/master/test/TestWebAppCore
Do you have different RP's and do someone work?
Related
I am getting the below error when trying to make a connection to the snowflake.
{
"code": "390100",
"message": "Incorrect username or password was specified."
}
The same works well when I generate the token via cli and use the same to connect to snowflake. This issue is happening when I use Oauth.
Does any one has info on this?
Check the official documentation below.
https://docs.snowflake.com/en/developer-guide/sql-api/submitting-requests.html#label-sql-api-submit-query-regionless-account
Snowflake-Account header must be passed and this must be the account locator (which you can find under your username when you connect to snowflake UI).
For example:
when you connect to snowflake, there are two URL's that can be utilized.
Regionless :--> https://organizationname-accountname.snowflakecomputing.com
With Region :-> https://Account_locator.us-east-2.snowflakecomputing.com
When you are using a Regionless URL and the authentication type as OAUTH, then you need to pass an additional header.
"Snowflake-Account: "
In postman you can pass the parameter under headers with key and value way, where key being Snowflake-Account and value being Account Locator.
If you don't use regionless URL, the above header is not needed.
Let me know if the above helps. Also attaching KB article for your reference to setup with postman.
https://community.snowflake.com/s/article/Connect-to-SQL-API-using-Postman
Kentor - Using the SampleMvcApplication with success through their StubIdp but when I try with Clareity I receive the above error.
Without knowing anything about the implementations ( Kentor, SampleMvcApplication, StubIdP, Clareity )it looks as if:
Your Identity Provider implementation does not return a 'RelayState' parameter in the body of the HTTP POST along with the SAMLResponse.
Your Identity Provider implementation has added an InResponseTo attribute in the SAMLResponse element
Your Service Provider implementation interprets this as an IdP initiated SSO since it does not see a 'RelayState' parameter
Your Service Provider throws an error since it doesn't make sense for an SAMLResponse in an IdP initiated SSO flow to have an InResponseTo. InResponseTo refers to an AuthenticationRequest which is only there in a normal SP initiated SSO.
To get more help, you should tell us a little about the implementation you are using and your configuration.
I'm facing a problem with validating SAML response where in, its giving digest mismatch. Tried checking it with the certificate's digest value and its showed a different value. I think there is a problem with the certificate or the SAML response but, I'm also wondering whether not having an authentication at the SP level is also a cause for concern since, the client does not want a response back on the IDP, contrary to what the standard setup for SAML dictates. I realize there shouldn't be a setup of this sort due to obvious security concerns but, this was the setup they have requested...
If the SAML assertion is not signed properly, this is a security concern and you should not trust it. By trusting it without validating the digest, you would open your self up to anyone submitting SAML to your ACS URL and being authenticated.
SAML assertion is generated at the IDP(PF). It is consumed at the SP(PF). Is saml assertion tampering possible? If so, how to test it? I am trying to track get & post requests.
When I post the generated SAML Response to https://machine_name:port_no/sp/ACS.saml2, I get 404 error. I understand that we cannot hit the url.when I give the destination resource url, the resource page is opened.But I don't find the response in my server log.
I want to post the generated response with slight modifications and test if it throws any error. The intruder shouldn't be allowed to get the resource. Though I modify the response, I am able to hit the url & access the page.I am using POSTMAN chrome extension for this purpose.
Note : I am extracting saml response from the Agentless Integration Kit sample application.so the destination url is https://machine_name:port_no/AgentlessIntegrationKitSampleSP
Thanks,
Aswini J
If you want to tamper with the SAML data in the browser, you should use the Tamper Data extension for Firefox. It will allow you to step through each transaction and selectively modify the data.
However, you cannot successfully tamper with the SAML Response because it is a digitally signed (and optionally encrypted) message. Any tampering of the signed data will invalidate the message and PingFederate will not allow the message to go through. This is mandated per the SAML XMLDig specification which PF strictly enforces.
The info exchanged between the PingFederate (SP) and QuickStartApp (SP) is not SAML -- it is a "one time use" reference token that refers to information that is stored in PingFederate runtime memory. If you modify this value, PF will throw an error because it will not reference any known data.
When calling a web service from Force.com, I am getting:
System.CalloutException: Web service callout failed: Unexpected
element. Parser was expecting element
'http://schemas.xmlsoap.org/soap/envelope/:Envelope' but found ':HTML'
The network guys at the other end has asked to see the full response that Salesforce is getting from their server.
Is there a way to achieve that? I have tried running with debug level 'Finest' from execute anonymous, but that yields the same little message with no further detail.
The message you are getting is because an error is generated as Saleforce is trying to parse the response is and it isn't logged unfortunately.
The parsing error is happening because instead of a SOAP message response you are getting an HTML page. This usually happens when you are accessing a service that is protected behind a firewall. Which means you may be able to see the service when browsing on your computer but remember that Salesforce is outside of your firewall and thus any communication by Salesforce to your service will be blocked.
Couple of ways to address this but this wiki topic from Salesforce best covers the options:
http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_om_outboundmessaging_security.htm
The above is specific to outbound messaging but essentially the technology issues are the same.
Don't forget that Apex includes an HttpRequest Class that works as a lower layer than the SOAP APIs. You should be able to write up a test method that sends a hard-coded XML request to the server and dumps the HttpResponse so you can see it.
Adding my own best answer, based on some internet research:
You can use an external tool like Runscope as a webservice proxy to automatically forward requests and pass through responses and view the XML SOAP messages. This is not a native solution on SFDC but it does do the job.
https://www.runscope.com/
The issue is that Force.com is trying to parse a SOAP response that's actually just HTML. This happens sometimes when an error occurred server-side and the response is meant for a browser to display, rather than sending back an exception report via a properly formatted SOAP response.
If they can't figure out why they are not sending back a consumable SOAP response, then you can try using other tools (outside of Force.com) to make the same webservice call from your browser and then see what the HTML actually says on return.