ADFS 2.0インスタンスがセットアップされました。サードパーティのWebアプリのシングルサインオンに使用します。ユーザーがADFSサーバーにリダイレクトされたときのIWAパススルーを含め、すべてが既存のアプリであるApp1とSAML 2.0で問題なく機能します。
SAML 2.0を使用して、別のアプリケーションApp2の2番目の証明書利用者信頼を構成しました。エンドポイントを含むすべてのデフォルトのADFS設定を使用しています。このアプリケーションのSAML構成ページで、SAMLエンドポイントは " https://adfs.mydomain.com/adfs/ls/ "であると伝えました。ユーザーが資格情報の入力を求められることを除いて、すべてが正常に機能します。 ADFSはこれらのログインにIWAを使用していません。
IE9を使用して、ローカルドメインに参加しているワークステーションからテストしています。内部DNSはローカルドメインに参加しているADFSサーバーを指し、外部DNSはDMZ ADFSプロキシを指します。 "*。mydomain.com"はIE by GPOで適用されます。IEでIWAが有効になっています。IEを閉じるたびにキャッシュ/クッキー/履歴がクリアされます。両方のアプリケーションSP開始されたサインオンを使用しており、両方がアサーションを同じエンドポイントURLに送信します。
クリーンセッションでApp2にログインしようとすると、ADFSログインページが表示されます。資格情報を入力すると、アプリにログインして続行できます。
クリーンセッションでApp1にログインしようとすると、すぐにADFSにリダイレクトされ、IWAがパススルーされ、アプリにログインして続行できます。
App1にログインした後、同じセッションでApp2にログインしようとすると、ADFSにリダイレクトされ、App1によって開始された既存のADFSログインセッションが使用され、すぐにApp2のアサーションコンシューマサービスURLにリダイレクトされますエラーページが表示されます。
私の推測では、RPT構成に何か欠けていると思います。 SPが私に与えたすべては、POSTバインディングを使用した消費者サービスエンドポイントURLです。クレームルールを推測する必要がありました。SPは暗号化を使用しません。
App2カスタマーサービスは困難でした。彼らの技術サポートは海外にあるので、私は現地時間の真夜中頃に1日に1回しか応答を受け取りません。それらの応答のほとんどは、標準の「KBからのコピーアンドペースト」です。彼らはIdPが開始したサインオンを好みますが、SP startedをサポートしていると言っています-ADFSログインページにログインした後、SSOはクリーンセッションで動作するため、これは真実のようです。
誰かが私が欠けているものを知っていますか?
認証方法を構成および要求できます。同じ識別子がSAMLとWS-Fedで使用されます。
WS-Fedで要求されるとwhr =に移動し、SAMLでは認証コンテキストクラスに移動します。 SAMLでは、「比較」(正確、最小などですが、注文に同意する必要があります)を指定できます。 ADFSは(現時点では)比較属性に注意を払いません。
多くの場合、特定のアプリケーション(RP/SP)に特定のレベルを使用するようにポリシーを定義できます。時々それはソースアドレス等に依存して異なって構成されることができます。