14

現在、さまざまなソースからの認証を必要とするJBossAS7で実行されているプロジェクトに取り組んでいます。認証を提供するために組み合わされるさまざまなコンポーネントを理解しようとしています。

私はこれがどのように組み合わされるかについていくつかの仮定/推測を持っていますが、私の理解が正しいことを確認する必要があります。以下は、JBossAS7の認証プロセスであると私が理解していることです。

ユーザーの認証方法を定義するセキュリティレルムがあります。次に、このレルムは、その一部またはすべてを保護するためにアプリケーションに公開されます。AS7では、これは<subsystem xmlns = "urn：jboss：domain：security：1.0">要素で設定されます。

レルムは、データベース、LDAP、ローカルファイルなどのログインモジュールを使用して、さまざまなソースに対してユーザーを認証するように構成できます。複数のログインモジュールを定義できます。認証を行うには、ログインモジュールの組み合わせを「成功」させる必要があることを指定できます。

実際のユーザー名とパスワードは、<login-config>要素で定義されたweb.xmlファイル（サーブレット用）で定義されたメカニズムを介して渡されます。

上記のプロセスが正しいと仮定すると（正しくない場合もあります）：

  • この認証プロセス全体はJAASのような仕様に該当しますか、それともJAASはこの手順のほんの一部またはオプションの部分ですか？
  • すべてのタイプの<auth-methods>（つまり、BASIC、DIGEST、およびFORM）は、すべての種類のログインモジュールで機能しますか？このページはそうではないことを示唆しているように見えますが、<login-module>オプション<login-config>オプションに一致する明確なドキュメントは見ていません。
  • login-configからlogin-moduleへのユーザー名とパスワードのフローは十分に単純に見えますが、中間ステップ（外部ログインページへのリダイレクトなど）があるOpenIDやOAuthなどのシステムではどうなりますか？
  • Seam 3 Security、Apache Shiro、Spring Securityなどのプロジェクトはこの図にどのように当てはまりますか？
4

1 に答える 1

13

JavaEEセキュリティ仕様はコンテナ実装者に多くのスペースを残しているので、JBoss実装に焦点を当てて答えます。

JBossセキュリティの実装

JBossはJAAS認証に依存してJavaEEセキュリティを実装します。そうすれば、安定したAPIのメリットを享受し、既存のLoginModule実装を使用できます。ログインモジュールは、サブジェクトを認証するためだけでなく、にロールを追加するためにも使用されますSubject。JAASは承認、パーミッションチェックのメカニズムを提供し、JBossはそれを内部で使用します。

JAAS LoginModuleは、パスワードベースの認証だけでなく、トークンベースの認証もサポートしています。

トークンベースの認証

JAASのおかげでJBossで実行できることの良い例は、Kerberos SPNEGOのHTTPネゴシエーションサポートです。TomcatAuthenticatorのおかげで追加のauth-method名前SPNEGOが実装され、トークンの検証ではJavaSE標準のKerberosLoginModuleが使用されます。

ちなみに、LoginModule APIは必須ではなく、プロトコルによっては複雑すぎる場合もあります。たとえば、PicketLinkでOpenIDをサポートする実装では、サーブレットAPIのみを使用します。

サードパーティのセキュリティライブラリ

これらのライブラリは、認証またはロールベースの承認に関するJavaEE仕様のメリットを享受していなくても、JavaEEまたは純粋なJavaコンテキストを実行しているアプリケーションにセキュリティレイヤーを提供することがよくあります。

ServletFilterSpring Securityは、主にWebアプリケーションが関係する場合に、アプリケーション開発者が認証と承認を実装するためのJavaEEセキュリティ以外の抽象化を提供します。彼のアプリケーションを保護するために、さまざまな選択肢が用意されています。JAASの使用法、JavaEEコンテナのセキュリティの使用法、Spring Security固有の実装（OpenIDとOAuthの場合）など、複数のオプションを組み合わせることができます。JavaEEにも依存関係がないため、JavaSEで実行している場合はほとんどすべての状況で使用できます。ほとんどのアーキテクトは、Spring Securityにアプリケーションセキュリティを構築して、将来特定の実装を自由に切り替えることを選択します。

ApacheShiroはSpringSecurityに非常に似ていますが、より若く、おそらくセットアップが簡単です。

SeamセキュリティはJavaEEセキュリティやJBossに依存せず、サーブレットとJSFAPIにのみ依存します。これは、JSF/SeamベースのWebアプリケーションにとって明らかに最も簡単なオプションです。舞台裏では、PicketLink実装を使用しています。

結論として、 JavaEEセキュリティに加えて、またはJavaEEセキュリティの代わりにサードパーティのライブラリを使用するかどうかは、アーキテクチャの選択（アプリケーションの複雑さ、ベンダーの独立性と移植性、バグ修正または改善のための実装の制御）によって異なります。特定のコンテキストでは、複数の認証ソースを使用するには、認証プロバイダーチェーン（またはShiro）をサポートするSpringSecurityのような柔軟なソリューションが必要です。

于 2012-05-07T07:33:26.353 に答える