web-dev-qa-db-ja.com

SAML拡張機能とShibbolethを使用したSpringでのシングルサインオン

さまざまなセキュリティドメインからの認証と承認をサポートすることを目的として、Springベースのアプリケーションにシングルサインオン（SSO）認証レイヤーを実装したいと思います。 IdPとしてShibbolethを選択しましたが、SPに何を使用するかはまだ特定していません。

選択肢は次のとおりです。

  • Spring Security SAML Extension：コンポーネントを使用すると、新規アプリケーションと既存アプリケーションの両方が、SAML 2.0プロトコルに基づくフェデレーションでサービスプロバイダーとして機能し、Webシングルサインオンを有効にできます。 Spring Security Extensionを使用すると、SAML2.0とその他の認証およびフェデレーションメカニズムを単一のアプリケーションでシームレスに組み合わせることができます。 IDプロバイダーモードでSAML2.0をサポートするすべての製品（ADFS 2.0、Shibboleth、OpenAM/OpenSSO、RM5 IdM、Ping Federateなど）を使用して、Spring Security SAMLExtensionに接続できます。

  • Shibboleth（SPとしても）：Shibbolethは、HTTP/POST、アーティファクト、および属性を実装するWebベースのテクノロジーです。 IDプロバイダー（IdP）コンポーネントとサービスプロバイダー（SP）コンポーネントの両方を含むSAMLのプッシュプロファイル。

だから、私はいくつかの質問があります：

  1. スケーラビリティと保守性の観点から、SpringSAMLをSP）として直接使用することをお勧めしますか？
  2. 外部SPをSpringSecurityと一緒に使用することは可能ですか？アプリケーションやアプリケーションサーバー（JBoss 8.0-WildFly）を構成するにはどうすればよいですか？
  3. （シナリオごとに）役割はどこで定義しますか？
  4. どちらが価値のある選択ですか？

よろしく、V。

spring-securitysingle-sign-onsaml-2.0shibbolethspring-saml
22
vdenotaris

2つの主な違いは、展開シナリオです。

  • Shibboleth SPプラグインはApache/IISWebサーバーに直接デプロイされます。
  • Spring SAMLはアプリケーションに埋め込まれています。

どちらにも長所と短所があります。

  1. スケーラビリティと保守性の観点から、SpringSAMLをSP）として直接使用することをお勧めしますか？

Spring SAML

  • 認証の実行方法と認証プロセスがアプリケーションと対話する方法を細かく制御できます。あなたは例えばすることができます独自の構成UIを作成し、IDPを動的に追加し、アプリケーションの一部としてカスタムログイン画面を作成し、エラー処理を完全かつ簡単に制御し、複数のIDPを簡単にサポートし、SSOの詳細を動的に構成します（要求されたAuthnContext、NameID、バインディング、認証の強制）。
  • 受信したSAML属性をさまざまな形式で簡単に解析し、同じアプリケーションで複数の認証方法をサポートします。
  • SPメタデータを動的に生成し、限定されたマルチテナンシーを提供し、他のすべてのオプション（シングルログアウト、キーのホルダー、IDPディスカバリーなど）では利用できないプロファイルをサポートします。
  • Spring Securityとシームレスに相互作用し、独自の一連の利点をもたらします。 Spring SAMLを使用すると、完全な認証および承認ポリシーをアプリケーションで直接構成することもできます（たとえば、認証が必要かどうか、いつ、コンテンツへのロールベースのアクセス制御、動的条件での認証のステップアップなど）。
  • 機能に影響を与えることなく、アプリケーションを任意のアプリケーションサーバーまたはコンテナーに、任意のリバースプロキシまたはWebサーバーの背後にデプロイできます。

Shibbolethプラグイン

  • これらは静的に構成され、通常はHTTPヘッダーを介してアプリケーションと対話します。これらは認証ロジックをアプリケーション自体から切り離すため、注意する必要があるのは、ヘッダーの受け入れと、正しいセキュリティコンテキストを使用したアプリケーションセッションの初期化だけです。保護されるページの定義は、IIS/Apacheサーバーに存在し、URLパターンに基づいています。つまり、認証と承認のポリシーは、アプリケーションの外部で部分的に定義されています。
  • ヘッダーの偽造が可能になるため、アプリケーションにWebサーバー経由でのみアクセスできること（=すべての直接アクセスを禁止すること）を確認する必要があります。
  • アプリケーション自体に多くの変更を加える必要がないため、通常、レガシーシステムで簡単に使用できます。
  1. 外部SPをSpringSecurityと一緒に使用することは可能ですか？アプリケーションやアプリケーションサーバー（JBoss 8.0-WildFly）を構成するにはどうすればよいですか？

はい、可能ですが、手間がかかります。あなたは例えば暗号化された形式で共有ドメインCookieを設定し、SpringSecurity設定でCookieを確認するようにWildFlyを設定します。

  1. （シナリオごとに）役割はどこで定義しますか？

Spring SAMLを使用すると、SAML応答を処理するときにロールを定義します。 SAML属性の解析。これは、SAMLUserDetailsServiceインターフェースを実装し、samlAuthenticationProviderにプラグインすることによって行われます。

Shibbolethを使用すると、IDPから受け取った属性をヘッダー付きでアプリケーションに転送し、アプリケーションで解析できます。

WildFlyを使用すると、（おそらく）セキュリティコンテキストとロールをSPで直接定義できます。アプリケーションでこれを設定する必要はありません。このような設定は、アプリケーションサーバー間で移植できない場合があります。

  1. どちらが価値のある選択ですか？

すべてのオプションにより、SAML2.0でWebSSOを実行できます。人々は通常、要件（カスタマイズのニーズなど）、環境（使用するWebサーバー、アプリケーションサーバー）、推奨される開発方法（Java、.NET、その他）、使用するフレームワーク、レガシーコードに基づいて選択します。 SpringSAMLプラグインとShibbolethプラグインの両方が多くのお客様に使用されています。

46
Vladimír Schäfer