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.
Related
As an SP, we've opted for the POST binding option - it seemed to be the advised approach. SAML is now set up and working with the IDP. We would now like to change to Redirect as it is better handled in Ajax calls after timeout.
My question is whether we can switch from POST to Redirect without incurring a setup change on the IDP side. Seeing as both bindings are just using the UserAgent (browser) as a transport anyway, I figured it may be possible. But the binding is defined in the AssertionConsumerService in the metadata which indicates that IDP would need to be informed and have its configuration changed.
Sending a SAML Response (which is what is sent to an Assertion Consumer Service endpoint) via Redirect is not supported by the SAML spec since responses easily get too large to send as a query parameter. See line 420 in the SAML Web SSO Profile spec https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
Identity Provider issues to Service Provider In step 5, the identity provider issues a message to be delivered by
the user agent to the service provider. Either the HTTP POST, or HTTP
Artifact binding can be used to transfer the message to the service
provider through the user agent. The message may indicate an error, or
will include (at least) an authentication assertion. The HTTP Redirect
binding MUST NOT be used, as the response will typically exceed the
URL length permitted by most user agents.
You can switch to Artifact, though SP metadata will need to updated on the IDP to relay the changed endpoint.
We are implementing SAML integration and I am the service provider and my identity provider is asking me to send "SAML Consumer URL" and "RelayState"
I would need help to understand what is SAML consumer URL & RelayState and how do I get/generate it for my application.
Thank you for your time and help!
TLDR, AssertionConsumerUrl (ACS) endpoint is SAML protocol endpoint, RelayState is like cross-domain cookie, used to coordinate messages and actions of IdPs and SPs.
In 5.1.Web Browser SSO Profile of SAML 2.0 Technical Review, it will give you a general understanding of how the flow goes.
Down to the SSO implementation, for example Shibboleth, this FlowAndConfig doc details the SSO flow pretty well.
In 2. SP Determines IdP and Issues Authentication Request:
Cookie Set by SP
During this step, the SP will preserve the original
resource requested by the browser using a "relay state" mechanism,
which is configured by a relayState property on the <SessionInitiator>
element. The default mechanism does not rely on a cookie any longer,
but many systems do, and send a state management cookie containing the
resource URL to the client along with the request prepared for the IdP
or DS/WAYF.
In 5. Back to the SP:
The browser delivers the response from the IdP to an Assertion Consumer Service endpoint at the SP.
relay state info returned from IdP to SP
Cookie Read by SP
The "relay state" information returned by the IdP, if any, will have
been created by the SP and if using a cookie, will point to a
specially named cookie that should accompany the authentication
response supplied to the ACS endpoint in this step. This is the cookie
set in Step 2 above. If this cookie is missing (or if no relay state
exists at all), the associated application's homeURL property is
substituted as a fall back.
Also, Shibboleth has some wiki for those two terms as well.
AssertionConsumerService concept
RelayState concept
Hope it helps!
I am using token based security in my web app. The server side is wrote using c# and i am using openiddict for logging in and issuing tokens, found here. I am currencyly using Implict flow.
By default my tokens have a lifespan of 1 hour, after that you have to logging again. I have locked down my API to accept bearer tokens only and not cookies.
I wanted to implement refresh tokens but after reading many websites, it appears that implementing refresh tokens on a web app, is not a good way to go due to a hacker getting the refresh token. I know that to use refresh tokens, you must use code flow, instead of implict, which i can do.
How do people get round this situation in their web apps? I cant be the only one who wants a token to last longer than an hour in a web app?
The approach recommended by OpenID Connect is to send an authorization request in a hidden frame with the same parameters as the ones you use for the initial implicit flow request plus prompt=none and optionally, an id_token_hint corresponding to the id_token you extracted from the authorization response.
When using prompt=none, the identity provider won't display any consent form and will directly redirect the user agent to the redirect_uri you specify, with the new token appended to the URI fragment, just like for a classic implicit flow request. You can retrieve it by extracting it from the popup.location.hash property.
If the request cannot be processed (invalid request, unauthenticated user, invalid id_token_hint, consent required, etc.), an error is returned and the identity provider either redirects the user agent to the redirect_uri with an error parameter or stops processing the request.
Note that due to the same origin policy, you can't access popup.location.hash if the current location belongs to a different domain (e.g if the identity provider refuses to redirect the user agent to your client app): it will throw an access denied exception. In this case, it's always better to add a timeout to your "refresh" operation.
Sadly, there are very few libraries that can help you with this task. oidc-token-manager is one of them, but it has a few limitations that will prevent it from working OTB with OpenIddict: it doesn't support raw RSA keys (you have to explicitly use a X509 certificate in the OpenIddict options) and it doesn't send the id_token_hint parameter required by OpenIddict when sending a prompt=none request.
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.
I am just wondering while implementing SAML SSO with Salesforce I realize that I uploaded the certificate to the SP side (i.e. Salesforce), however I can see when we send a signed SAML response it already includes the certificate.
Why is the certificate shared ahead of time with the SP?
It's all about establishing trust between systems. If you don't give SFDC your cert ahead of time, how can they trust the message you are sending is actually from your IDP? Without your cert ahead of time, they can validate that the message is intact but not who actually generated it. When you include your public key in the SAML Response, they can check that it's the same one you shared with them and it's the same one you used to generate the signature.