次のシナリオがあります。
3 つの異なる SharePoint サーバー: sp1.company.com。sp2.company.com... Windows 認証を使用する内部ユーザーと、フォーム ベース認証 (FBA) を使用する外部ユーザー。
外部ユーザーがあるサーバーから別のサーバーに変更すると、再度ログインする必要があります。私の目標は、すべての SharePoint サーバーにシングル サインオン (SSO) を導入することです。
内部ユーザーには ADFS を使用し、外部ユーザーには customSts (ThinkTecture IdentityServer) を使用することで、これを実現できるのではないかと考えました。
これは可能でしょうか？Sts サーバーの ADFS と IdentityServer をセットアップするにはどうすればよいですか? WS-Federation 経由で ADFS を IdentityServer に接続する必要がありますか?
はい、提案しているアーキテクチャは問題ありません。SharePointでのフォーム認証とWindows認証の使用を停止し、シングルログインメカニズムとしてクレームベース（SAMLおよびWS-Fed）の使用を開始する必要があります。アーキテクチャパターンは次のとおりです。アプリケーションは「フェデレーションハブ」（ADFSまたはWindows Azure Active Directoryのいずれか）を信頼します。そのサーバーは、IDプロバイダーおよびアプリケーションとのすべての信頼関係を持ちます。あなたの場合、今日持っているのは、2つのSharePointアプリケーションと2つのIDプロバイダー（1つはADFSを介したAD、もう1つはIdentity Serverなどを介したカスタムデータベース）です。
すべてが標準プロトコルとトークン形式で接続されています。SharePointから「フェデレーションハブ」まで、WS-FederationおよびSAML1.1トークンを使用します。「フェデレーションハブ」からADFSまで、WS-FederationおよびSAML1.1または2.0トークンを使用します。「フェデレーションハブ」からIdentityServerまでは、ADFSと同じです。将来、Facebookのようなものをプラグインする場合、「フェデレーションハブ」はOAuthを話す必要がありますが、SharePointは引き続きWS-Federationを使用するため、その部分に触れる必要はありません。
フェデレーションハブとしてのADFSは、WS-FederationおよびSAMLプロトコル（OAuthではない）のサポートを提供します。今日はそれで十分かもしれません。Microsoftからサービスとして提供される「フェデレーションハブ」であるWindowsAzureActive Directory （以前はWindows Azureアクセス制御サービスと呼ばれていました）を検討することをお勧めします（10万ログインあたり2米ドルの値札）。Microsoftは現在、ADFS以外のWAADに重点を置いています。WAADは、OAuth、モバイルシナリオ、Office 365などのサポートを提供します。ADFSが廃止されるなどと言っているのではなく、投資が行われている場所についての私の見解です。
物事をまとめるにはある程度の学習と時間が必要です。そのため、証明書の問題、構成の誤り、ホームレルムの検出、クレームの変換、SharePointピープルピッカー、Cookie、ログアウトなどの壁にぶつかる準備をしてください。
ここにいくつかのポインタがあります：
マティアス
お返事ありがとうございます、それは私を大いに助けました。
ADFSとCustomSTSを使用して認証する単純なASPアプリを構築することができました。ADFSでホームレルムを選択し、IdentityServerにログインできましたが、アプリにリダイレクトされませんでした。さらに、SharePointでそれを行うためにそれを管理しませんでした。PowerShellスクリプトを使用すれば簡単なはずですが、まだ機能していません。
People Pickerについて：SharePointのClaimsProviderを上書きする必要があることはわかっています。ADとカスタムメンバーシッププロバイダーに対してクエリを実行する必要がありますか？
私はあなたの製品を調べました。多分これは私たちにも役立つかもしれません。さらにテストします。
よろしく、パトリック