他の「リセラー」Web サイトで IFRAME を介してレポート ページを利用できるようにしたいクライアントのために、ASP.NET Web サイトを作成しています。再販業者の Web サイトは、異なるブランドで同じサービスを提供しています。できる限り、これを有効にするためにウェブサーバーにコードを実装するように要求することを避ける必要があります-したがって、iframeを使用します。
ユーザーは再販業者の Web サイトにログインし、iframe を含むページをロードすると、プライマリ サイトでレポートがロードされます。パラメータとして、リセラー ID とそのユーザー名を送信します。
SSL サーバー証明書は使用できますが、フェデレーテッド ログイン (OpenId など) は使用できません。クライアントのビジネス上の選択です。
問題は、リセラーからページを読み込んだユーザーがレポート ページを実際に要求していることをプライマリ サイトがどのように確認するかということです。つまり、再販業者がコードを実装する必要なく、ドメイン間でユーザーを認証する方法..
どんな考えでも大歓迎です！
ログイン フォームは、ログインが必要な各ドメインの非表示の iframe にログイン フォームを投稿するために、JavaScript を使用できます (クロス ドメインのセキュリティ上の理由から、XMLHTTPRequest は使用できません)。
必ず iframe を元のドメインにリダイレクトしてください。そうしないと、クロスドメイン セキュリティのために iframe からログイン ステータスを取得できなくなります。
IE サポートの最後の秘訣は、悪ビットを反転して追加することです。
P3P: CP="CAO PSA OUR"
HTTP 応答ヘッダーに。これはブラウザに「私は何も悪く、正直に言うつもりはありません」と伝えます。
再販業者のサイトにコードを実装せずにこれを行う満足のいく方法はありません。
代わりに、再販業者の Web サーバーからプライマリ Web サーバーに HTTPS 要求を送信し、自分自身を識別するための一意の秘密鍵と、ログオンしているユーザーのユーザー名を渡す必要があります。
プライマリ サイトで検証されると、このキーは再販業者の認証として機能し、ひいてはそのログオン ユーザーの認証としても機能します。
このリクエストの応答には、再販業者が任意のページに挿入できる html フラグメント文字列が含まれます。
このフラグメントには iframe が含まれ、ログオンしているユーザーのレポートをユーザー名を使用してプライマリ サイトから直接読み込みます。このレポート コンテンツには、再販業者固有のスタイルシートへの参照が含まれます。
このアプローチでは、再販業者とそのユーザーの両方が認証されるため、HTTPS はブラウザーに必要ないと言えます。そのプロセスが HTTPS 経由で行われた場合、盗聴者はいないと想定できます。
秘密鍵またはユーザー パスワードが侵害された場合、ブラウザーからの HTTPS はいずれにせよ違いはありません。
何か不足している可能性がありますが、クライアントがサーバーに対して認証されている場合、iframe を介して表示すると、クライアントは引き続き認証されます。
たとえば、iframe から gmail への HTML ページをサーバー上に作成します。ブラウザで Gmail に対して認証されている限り、そのページに受信トレイが表示されます...