SSOを実行する3つのサイト、site1.com、site2.com、およびauth.comがあるとします。 SSLは常に必要です。
どのように SiteMinder Cookieはここで説明されています によると、これらのドメインの1つは関連する「マスターCookie」ドメインであり、他のドメインは認証に失敗した場合にそのドメインにリダイレクトします。
現在の仕組み
クリックジャッキングを防ぐために、auth.comのログインページには、古いブラウザ用に実装されたNoFramesスクリプトとフレームバスタースクリプトがあります。
クライアントがsite1.comまたはsite2.comにログインした後、AJAXが起動し、いくつかの操作(ポーリングなど)を実行します。この間、JavaScriptはセッションが無効であることを示すエラーを受け取る場合があります。このエラーは、AJAXの使用中に発生します(参照中に発生した場合、リダイレクトが発生し、この質問全体は当てはまりません)。
この時点で、ページを更新してリダイレクトするか、auth.comに再度ログインするようにユーザーに指示することができますが、その後、メモリ内のアプリケーション状態が失われます。
エンドユーザーのための新しい/シームレスなアプローチ
回避策として、JavaScriptを使用してauth.com/RefreshOnly
へのiFrameを作成することを検討しています(iFrameは大丈夫です)セッションデータをPOSTします。 Auth.com/RefreshOnly
はそのドメインのCookieを確認し、選択した場合は、Origin site1.com
にリダイレクトし、現在のCookieを更新するように指示します。すべて非表示のiFrame内にあります。
質問
IDP /認証プロバイダーでのiFrameのこの制限された使用は許可されますか? (Siteminderに限定されません)
あなたが提案していることが通常のワークフローに違反していないようです。アサーティングパーティ(site1またはsite2、AP)からサービスプロバイダー(auth-SP)に要求を出し、次にサービスプロバイダー(auth-SP)が識別プロバイダー(IdP)に要求を出します。
サイトがクレジットカードを受け入れるが、PCI規制の負担を受け入れたくない場合にも、このアプローチを実装することはかなり一般的です。 Cybersourceのような会社は、SPとして機能し、ユーザー入力を受け付けますAP Webページ内のiframe内。PCI(頭字語があいまいです...)が心配です。問題ありません。
確認番号がAPにどのように返されるかはわかりませんが、それほど問題ではありません。