Capturing SAML Response sent by IDP
Cantor, Scott
cantor.2 at osu.edu
Tue May 17 18:44:55 EDT 2016
On 5/17/16, 5:31 PM, "users on behalf of Ram, Budh" <users-bounces at shibboleth.net on behalf of budh.ram at sap.com> wrote:
>I am using Shibboleth SP for SSO implementation in my application (application is running on IIS7.5). My IDP was able to authenticate the user and sends back the SAML response to me as the response of this request “/Shibboleth.sso/SAML2/POST”. After this request there are two more GET request fired to reach back to my application.
No, there's one (a redirect to the RelayState-derived resource).
> As the above POST request which is having “SAMLResponse” header is the 3rd last request, I am not able to capture this header in my application as it is flushed out by the later GET requests fired.
It is not a header, it's a form field, and the SP is there to do that work. If you want access to the assertion, you can get it via the assertion export mechanism, but that's generally also a dubious thing to do. If you want to process the SAML *response* yourself, then you wouldn't be using the SP software also since that's its function.
>Can you please help me out how can I capture this intermediate request header to fetch the information sent by my IDP?
The information sent by the IdP is consumed and decoded into HTTP headers by the SP software using all of its various features, you don't get it from the SAML response.
>
>But in actual implantation how can I change the URL not having “Shibboleth.sso” portion in it while deploying to production.
You don't.
>How can I keep the URL same for my end user and authenticate the users via SSO?
By protecting resources with the RequestMap and setting the requireSession setting to true, which is active protection. Using the /Login endpoint to initiate a session is something you do when you're passively protecting resources and manually causing the login to happen under specific circumstances.
-- Scott
More information about the users
mailing list