saml サービス プロバイダーを実装しようとしていますが、単一の SP でカバーするシステムのレベルがわかりません。
SP ごとにどのレベルのアーキテクチャが適切と見なされますか? 部門全体、サーバーごと、ドメインごと、アプリケーション プールごと、さらにはサイトごとに 1 つ持つ必要がありますか?
私たちの組織には shibboleth IDP があり、kentor authservices を使用しています。1 つのサイトで機能していますが、sp はそのサイトの一部です。ベスト プラクティスがサイトごとに 1 つではないと仮定すると、それをより一般的にする (つまり、複数のサイトに対して 1 つのエンティティ ID) ようにする最善の方法についてのヒントがあれば、それを歓迎します。
どういうわけか、各サイト/アプリケーションにログイン情報を取得する必要があります。サイトごとに SP を使用するか (Kentor.AuthServices アプローチ)、Web アプリの前に Shibboleth SP プロキシをセットアップします。後者は、Shibboleth が提供する http ヘッダーを解析するために、各サイトにコードを追加する必要があることを意味します。私はそのアプローチが好きではありません - それが私が Kentor.AuthServices プロジェクトを始めた理由です。
したがって、私の好みは、Web アプリケーション フレームワークに対して可能な限りネイティブなモジュールを使用して、各サイトを適切な SP にすることです。関連する可能性のあるモジュールは、Kentor.AuthServices (.NET)、SimpleSamlPhp、Spring (Java)、saml2-js (ノード) です。
組織に複数のサイト/アプリケーションがあり、それらを複数のアップストリーム ID プロバイダーとフェデレートする場合、構成の NxM ペアが得られますが、これはスケーラブルではありません。その場合のオプションは、内部アプリケーションへの Idp として機能し、外部 Idp への SP として機能する SAML2プロキシを挿入することです。新しいサイト/アプリケーションはプロキシでのみ構成する必要があり、新しい外部 Idp はプロキシでのみ構成する必要があります。