私たちはACSを使用するアプリケーションを構築しています。当社の使用シナリオは次のようになります。Azure ACS - リレーパーティーアプリケーション - パラメータ付きのReturnURL？
にユーザーが残念ながら、「アクセス制御サービスポータル」上の「戻るURL」「中継党」に設定するだけで固定文字列であるようです。元のリクエストを伝播する方法はありますか？そうでない場合は、回避策として何を提案しますか？
私は答えがノーだと私は信じて、私はパラメータを格納するためにクッキーを使用することをお勧めします。
答えは実際にはいですが、少しの作業ではありません。ステップ3では、デフォルトのACSログインページによってACS RPで設定したURLによって戻りURLが上書きされます。これは、IDプロバイダを選択したACSがデフォルトでホストするページです。
この元のURLが保存されるように自分自身をホストするカスタムログインページを使用するようにACSに指示することができます（ブラウザでは常に表示されるわけではありません）。デフォルトのACSログインページは、ACSポータルからダウンロードして作業することができます。
難しい部分は、異なるプロトコルを使用する異なるアイデンティティプロバイダが、この元のURLを保存するために異なるメカニズムを使用するという事実から来ています。これについて
いくつかのさらなる議論やコードサンプルは、ここで見つけることができます、そしてあなたは、ウェブ上の他の場所で、この問題に対する更なる解決策を見つけるかもしれない：
How do I get the return URL working properly again after downloading a login page from Azure ACS?
OK、これを試しましたが、LiveIDは＆cxパラメータが気に入らないようです。私は "リクエストが適切にフォーマットされていません。"エラー。結局のところCookieソリューションで終わった。しかし、あなたが何の原因か分かりましたら、私はそれを知りたいです:-) あなたの提案は、他の方法で私を助けてくれました - 私は場合によってはオプションとしてただ1つのIdentitiyProviderを提示することを望んでいましたそれらのすべてをリストする。 –
私の最初の推測はURLエンコーディングの問題です。あなたが私に事例を送ってもらえれば、確かにあなたに伝えることができるかもしれません:) –
あなたは「にreturnurl」経由を提供する場合+マイクロソフトアカウントACSあなたが例えば、IdentitiyProviders.jsを経由してACSのログインページを照会し、「コンテキスト」を渡すことができます：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
その結果、あなたはwctxパラメータでのMicrosoftアカウントのログイン-URLを取得します。 https://login.live.com/login.srf?wa=wsignin1.0&wtrealm=...&wp=MBI_FED_SSL&wctx=cHI9d3NmZWRlcmF0aW9uJnJtPXVybiUzYW9uZW9mZml4eCUzYWRldiUzYWRlZmF1bHQmY3g9Zm9vb29iYXI1 < - foobar。
ログイン処理後、設定されたreturnUrlがwctxパラメータで呼び出されます（私の例では "foobar"になります）。
ありがとうございました:-) –
実際には、クッキーがなくても実行できます。他の回答を参照してください。 –