Is there a way to know what the target url is at the Identity provider?
code at sp: SAMLServiceProvider.InitiateSSO(HttpContext.Current.Response, null, targeturl, partnerIdP);
code at the idp: SAMLIdentityProvider.ReceiveSSO(Request, out partnerSP); → I want to know what the target url is here as I need to show a different skin on the idp login page based on a query string parameter on teh target url. All i see is the encrypted Return url and SAML requestlooking something like this
http://localhost/idp/Account/Login?ReturnUrl=%2fidp%2fSAML%2fSSOService%3fSAMLRequest%3dfZLR…
If that is not the right approach to handle this scenario, please advise what is correct.
The third parameter to SAMLServiceProvider.InitiateSSO is actually the optional SAML relay state.
For SP-initiated SSO the relay state is a value that the SP may send along with the authn request to the IdP and the IdP will return it to the SP along with the SAML response. The relay state is not a target URL and its value is opaque to the IdP.
For IdP-initiated SSO the relay state is a target URL and specifies to the SP which page to redirect to once SSO completes.
We don’t expose the relay state sent by the SP to the IdP application as this is handled internally by us and the value of this relay state is not a target URL or anything else that can be interpreted by the IdP application.
Just to confirm, do you want to customize the login page at the IdP based on information sent from the SP as part of the SSO?
*Just to confirm, do you want to customize the login page at the IdP based on information sent from the SP as part of the SSO?
-Yes. That is exactly what I wanted.
This isn’t something we currently support in our SAML high level API.
Would you want to send the additional information as query string parameters?
If so, if we provided an overload to our SAMLServiceProvider.InitiateSSO to allow you to specify these query string parameters and we appended these to the configured SSO service URL for the IdP, would that meet your requirements?
Yes. I think that should do it. Thanks v much
Ok. Please email support@componentspace.com mentioning this topic so we can get an update to you when it’s available. Thanks.
Okay. Just did. Any idea, how long it might take. I need to update the Boss.
We should have an update available next week.
Hi, On the same lines, Can an overload also be added to the
SAMLServiceProvider.InitiateSLO method to accept a targeturl/query string params and then sent back from the IDP.When I logout, I need to redirect the user to a target url that I pass to the idp. This is just for the logout portion of my situation that was describer earlier.
To summarize,
I have 2 pages in the same applicaiton
Page A → IDP Login Screen with Skin A → Page A ->Logout → Page A’s Redirect page that should show up after logout
Page B → IDP Login Screen with Skin B → Page B → Logout → Page B’'s Redirect page that should show up after logout
Thanks
We’ll take a look at this as well.
For login, we will provider an overload to SAMLServiceProvider.InitiateSSO which takes a singleSignOnServiceUrl parameter. If specified this will override the SingleSignOnServiceUrl specified in the configuration. The singleSignOnServiceUrl parameter can include whatever additional query string parameters you require. The identity provider should then check for these query string parameters as required either before or after calling SAMLIdentityProvider.ReceiveSSO.
For logout, I think this can be handled directly by your application. When you call SAMLServiceProvider.InitiateSLO, this sends a logout request to the identity provider. The identity provider will logout the user locally and send a logout response to the service provider. The service provider calls SAMLServiceProvider.ReceiveSLO to receive and process the logout response. Once this method returns, SAML logout has completed. You don’t need to pass a target URL to the identity provider because control returns to the service provider which can then perform a redirect to the target URL.
That is fine. Please let me know when you have the patch available to download
Please check your email. I’ve sent you a download link.
Iam sorry. I havent received it till now. Can you resend it to my email again. Mbonthu@acep.org
thanks
I’ve sent it twice now. Please let me know if you don’t receive the email.
Thank You. I got it.
Is this available yet? I don't see SAMLServiceProvider.InitiateSSO that can pass targetURL.
There’s a SAMLServiceProvider.InitiateSSO overload that takes a singleSignOnServiceUrl.
If specified, this URL is used instead of the configured URL, as the destination for the SAML authn request sent to the IdP.
[quote]
[/quote]
Thanks for the reply.
Maybe I got the was not clear on the question. Let's say that user going to www.sp.com/contact.aspx and it got redirected to login.aspx page.
On login page, it will call SAMLServiceProvider.InitiateSSO to IDP, then back again to AssertCustomerService.aspx so SAMLServiceProvider.ReceiveSSO will parse the response.
Now, on SAMLServiceProvider.ReceiveSSO, I keep getting targetUrl as null. Is there a way to preserve the "ReturnUrl" parameter so it will redirect to the contact.aspx page instead of default.aspx page?
Sorry, I misunderstood your question.
You can send the return URL as relay state when you call SAMLServiceProvider.InitiateSSO.
For example, in your login page:
var returnUrl = Request.QueryString[“ReturnUrl”];
SAMLServiceProvider.InitiateSSO(Response, returnUrl, partnerIdP);
When you call SAMLServiceProvider.ReceiveSSO, the targetUrl output parameter should be set to the returnUrl parameter passed in as the relay state to SAMLServiceProvider.InitiateSSO.
You should check that the targetUrl is within your web application to avoid potential open redirect attacks.
Alternatively, you could store the returnUrl in your ASP.NET session or elsewhere rather than using relay state/target URL.