Azure ACS - Relaying Party Application - ReturnURL with parameters?

Question

We're building an application which uses ACS. Our usage scenario looks like this:

1. The user gets a URL like this one https://our.application.com/?requestId=123456 via email and clicks on it
2. The user gets redirected to the LiveID login screen
3. After logging in, ACS forwards the user to us, but to https://our.application.com/

Unfortunately, it seems that the "Return URL" setting in the "Relaying Party" on the "Access Control Service Portal" is just a fixed string. Is there a way to propagate the original request to it? If not, what would you suggest as a workaround?

Trilley

Answer 1

I believe the answer's no, and I would suggest using a cookie to store the parameter.

Wycoff

Actually you can do it without the cookie stuff - see the other answers. – Minnick

Answer 2

The answer is actually yes, but not without a little work. In step 3, your return URL is being overridden by the one you have configured in your ACS RP by the default ACS login page. This is the page, which ACS hosts for you by default, where you choose your identity provider. (You may not always see it in the browser; it will redirect automatically if you only have one IDP configured.)

You can tell ACS to use a custom login page that you host yourself so that this original URL gets saved. You can download the default ACS login page from ACS portal as something to work off of.

The tricky part comes from the fact that different identity providers using different protocols use different mechanisms to save this original URL.

Some further discussion and code samples about this can be found here, and you might find further solutions to this problem elsewhere on the web:

How do I get the return URL working properly again after downloading a login page from Azure ACS?

Gottlieb

OK, I tried this, but it seems that LiveID doesn't like the &cx param. I kept getting the "The request is not properly formatted." error. Ended up with the Cookie solution after all. However, if you do know what could be the cause of this - I'd like to know it :-) Your suggestion did help me in some other way - I wanted in some cases to present just one IdentitiyProvider as an option instead of listing all of them. – Trilley

My first guess is an URL encoding problem. If you were to send me an example I might be able to tell you for sure :) – Gottlieb

Answer 3

If you want to provide a "returnUrl" via ACS + Microsoft Account you can query the ACS login pages via the IdentitiyProviders.js and pass a "context", e.g.: https://MyACS.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?protocol=wsfederation&realm=MyRealm&reply_to=&context=foooobar&request_id=&version=1.0&callback=&wfresh=0

As a result you will get the Login-URL for Microsoft Account with the wctx parameter: https://login.live.com/login.srf?wa=wsignin1.0&wtrealm=...&wp=MBI_FED_SSL&wctx=cHI9d3NmZWRlcmF0aW9uJnJtPXVybiUzYW9uZW9mZml4eCUzYWRldiUzYWRlZmF1bHQmY3g9Zm9vb29iYXI1 <-- foobar.

After the login process your configured returnUrl is invoked with the wctx parameter (in my example you will get "foobar").

Minnick