16.3. Elytron を使用した Jakarta Authentication セキュリティーの設定
JBoss EAP 7.3 より、elytron サブシステムは、Jakarta Authentication からの Servlet プロファイル実装を行うことができます。これにより、Elytron のセキュリティー機能とのより密接な統合が可能になります。
Web アプリケーションの Jakarta Authentication の有効化
Jakarta Authentication インテグレーションが web アプリケーションに対して有効化されるようにするには、Web アプリケーションを Elytron http-authentication-factory または security-domain に割り当てる必要があります。これにより、Elytron セキュリティーハンドラーがデプロイメントにインストールされ、Elytron セキュリティーフレームワークがデプロイメントに対してアクティベートされます。
Elytron セキュリティーフレームワークがデプロイメントに対してアクティブ化されると、リクエストの処理時に、グローバルに登録された AuthConfigFactory がクエリーされます。これは、デプロイメントに使用される AuthConfigProvider が登録されているかどうかを特定します。AuthConfigProvider が見つかった場合、JASPI 認証がデプロイメントの認証設定の代わりに使用されます。AuthConfigProvider が見つからない場合、デプロイメントの認証設定が代わりに使用されます。これにより、以下の 3 つのいずれかの状況になります。
-
http-authentication-factoryの認証メカニズムの使用。 -
web.xmlに指定されたメカニズムの使用。 - アプリケーションにメカニズムが定義されていない場合は、認証は実行されません。
AuthConfigFactory に行われた更新は即座に利用できます。これは、AuthConfigProvider が登録され、既存のアプリケーションと一致する場合、アプリケーションの再デプロイメントなしですぐに使用できることを意味します。
JBoss EAP にデプロイされたすべての web アプリケーションにはセキュリティードメインがあります。これは、以下の順番で解決されます。
- デプロイメント記述子またはデプロイメントのアノテーションから。
-
undertowサブシステムのdefault-security-domain属性で定義される値。 -
デフォルトは
otherです。
このセキュリティードメインは PicketBox セキュリティードメインへの参照であることが仮定されます。そのため、アクティベーションの最終ステップでは undertow サブシステムの application-security-domain リソースを使用して Elytron にマップされるようにします。
このマッピングは以下のいずれかを行います。
elytronセキュリティードメインを直接参照します。例を以下に示します。/subsystem=undertow/application-security-domain=MyAppSecurity:add(security-domain=ApplicationDomain)
http-authentication-factoryリソースを参照して認証メカニズムのインスタンスを取得しま。例を以下に示します。/subsystem=undertow/application-security-domain=MyAppSecurity:add(http-authentication-factory=application-http-authentication)
Jakarta Authentication インテグレーションを有効にする最小ステップは次のとおりです。
-
undertowサブシステムのdefault-security-domain属性を未定義のままにして、デフォルトがotherになるようにします。 -
application-security-domainマッピングをotherから Elytron セキュリティードメインに追加します。
これらの手順のディプロイメントに関連したセキュリティードメインは、CallbackHandler でラッピングされるセキュリティードメインです。これは、認証に使用される ServerAuthModule インスタンスに渡すようにするためです。
追加オプション
さらに 2 つの属性が application-security-domain リソースに追加され、Jakarta Authentication の動作をさらに制御できるようになりました。
表16.1 application-security-domain リソースに追加された属性
| 属性 | 説明 |
|---|---|
|
|
このマッピングを使用してすべてのデプロイメントの Jakarta Authentication サポートを無効にするには、 |
|
|
デフォルトでは、すべてのアイデンティティーがセキュリティードメインからロードされます。 |
サブシステムの設定
ディプロイメントに AuthConfigProvider が返される設定を登録する方法の 1 つは、elytron サブシステムに jaspi-configuration を登録することです。
以下のコマンドは、2 つの ServerAuthModule 定義が含まれる設定を追加する方法を表しています。
/subsystem=elytron/jaspi-configuration=simple-configuration:add(layer=HttpServlet, application-context="default-host /webctx", description="Elytron Test Configuration", server-auth-modules=[{class-name=org.wildfly.security.examples.jaspi.SimpleServerAuthModule, module=org.wildfly.security.examples.jaspi, flag=OPTIONAL, options={a=b, c=d}}, {class-name=org.wildfly.security.examples.jaspi.SecondServerAuthModule, module=org.wildfly.security.examples.jaspi}])これにより、以下の設定が永続化されます。
<jaspi>
<jaspi-configuration name="simple-configuration" layer="HttpServlet" application-context="default-host /webctx" description="Elytron Test Configuration">
<server-auth-modules>
<server-auth-module class-name="org.wildfly.security.examples.jaspi.SimpleServerAuthModule" module="org.wildfly.security.examples.jaspi" flag="OPTIONAL">
<options>
<property name="a" value="b"/>
<property name="c" value="d"/>
</options>
</server-auth-module>
<server-auth-module class-name="org.wildfly.security.examples.jaspi.SecondServerAuthModule" module="org.wildfly.security.examples.jaspi"/>
</server-auth-modules>
</jaspi-configuration>
</jaspi>
name 属性は、リソースが管理モデルで参照できる名前のみです。
layer と application-context 属性は、この設定を AuthConfigFactory に登録するときに使用されます。これらの属性は両者とも省略でき、ワイルドカードの一致を許可します。description も任意の属性で、AuthConfigFactory に説明を追加するために使用します。
設定内で、複数の server-auth-module インスタンスを以下の属性で定義することができます。
-
class-name:
ServerAuthModuleの完全修飾クラス名。 -
module -
ServerAuthModuleをロードするモジュール。 - flag - このモジュールが他のモジュールに関連してどのように動作するかを示す制御フラグ。
-
options: 初期化の際に
ServerAuthModuleに渡される設定オプション。
この方法で定義した設定は AuthConfigFactory で即座に登録されます。layer と application-context に一致する Elytron セキュリティーフレームワークを使用する既存のデプロイメントは、この設定をすぐに使用し始めます。
プログラムによる設定
Jakarta Authentication 仕様内で定義した API により、アプリケーションはカスタム AuthConfigProvider インスタンスを動的に登録できます。ただし、この仕様は実際に使用する実装や、実装のインスタンスを作成するための標準的な方法は指定しません。このため、Elytron プロジェクトには、ディプロイメントが使用できるシンプルなユーティリティーが含まれています。
以下のコード例は、この API を使用して上記の サブシステム設定 で説明したものと似た設定を登録する方法を示しています。
String registrationId = org.wildfly.security.auth.jaspi.JaspiConfigurationBuilder.builder("HttpServlet", servletContext.getVirtualServerName() + " " + servletContext.getContextPath())
.addAuthModuleFactory(SimpleServerAuthModule::new, Flag.OPTIONAL, Collections.singletonMap("a", "b"))
.addAuthModuleFactory(SecondServerAuthModule::new)
.register();
たとえば、このコードはサーブレットの init() メソッド内で実行して、そのデプロイメントに固有の AuthConfigProvider を登録することができます。このコード例では、ServletContext を参照して、アプリケーションコンテンツが設定されています。
register() メソッドは、生成された登録 ID を返します。この登録 ID は、この登録を AuthConfigFactory から直接削除するためにも使用できます。
Subsystem Configuration と同様に、この呼び出しも即効性があり、Elytron セキュリティーフレームワークを使用するすべての Web アプリケーションで有効になります。
認証プロセス
undertow サブシステムの application-security-domain リソースの設定を基にして、ServerAuthModule に渡される CallbackHandler は以下のいずれかのモードで動作できます。
統合モード
統合モードで動作すると、ServerAuthModule インスタンスが実際の認証を処理します。しかし、生成されるアイデンティティは、その の SecurityDomain によって参照される SecurityRealms を使用して、参照された の SecurityDomain からロードされます。このモードでは依然として、サーブレットコンテナー内で割り当てられるロールを上書きできます。
このモードのメリットは、ServerAuthModules が、アイデンティティのロードに Elytron 設定を活用できることです。このため、データベースや LDAP などの通常の場所に保存されているアイデンティティは、ServerAuthModule がこれらの場所を認識せずに読み込みできます。さらに、ロールやパーミッションマッピングなどの他の Elytron 設定を適用することもできます。参照される SecurityDomain は、SASL 認証またはその他の JASPI 以外のアプリケーションなど、他の場所で参照することも可能です。
表16.2 統合モードでの CallbackHandlers メソッドの操作。
| 操作 | 説明 |
|---|---|
|
|
認証には、 |
|
|
この 注記
認証されたアイデンティティが既に
匿名のアイデンティティーの承認が行われると、 |
|
|
このモードでは、セキュリティードメインに設定された属性のロード、ロールのデコード、およびロールのマッピングでアイデンティティーが確立されます。この |
非統合モード
非統合モードで動作している場合、ServerAuthModules は、すべての認証およびアイデンティティー管理を完全に行います。指定した Callbacks を使用してアイデンティティーを確立できます。生成されるアイデンティティーは SecurityDomain に作成されますが、参照される SecurityRealms に格納されるアイデンティティーに依存しません。
このモードの利点は、簡単な SecurityDomain 定義以外を必要とせずに、アイデンティティーを完全に処理可能な JASPI 設定をアプリケーションサーバーにデプロイすることができることです。この SecurityDomain には、起動時に使用されるアイデンティティーを実際に含める必要はありません。このモードの欠点は、ServerAuthModule がすべてのアイデンティティー処理を行うようになるため、実装がはるかに複雑になる可能性があることです。
表16.3 非統合モードでの CallbackHandlers メソッドの操作。
| 操作 | 説明 |
|---|---|
|
|
|
|
|
この
|
|
|
このアイデンティティーは |
validateRequest
ServerAuthContext で validateRequest を呼び出すと、個々の ServerAuthModule インスタンスが、定義された順に呼び出されます。各モジュールには、制御フラグを指定することもできます。このフラグは、応答がどのように解釈され、処理が次のサーバー認証モジュールに続行するべきかや、すぐに返されるべきかを定義します。
制御フラグ
設定が elytron サブシステム内で指定されていても、JaspiConfigurationBuilder API を使用していても、制御フラグは各 ServerAuthModule に関連付けることができます。指定がない場合は、デフォルトが REQUIRED に設定されます。このフラグは、結果に応じて、以下の意味を持ちます。
| フラグ | AuthStatus.SEND_CLAIM | AuthStatus.SEND_FAILURE、AuthStatus.SEND_continue |
|---|---|---|
| Required | 検証は、残りのモジュールに対して継続されます。残りのモジュールの要件が満たされると、リクエストによる承認の続行が許可されます。 | 検証は残りのモジュールに対して継続されますが、その結果に関係なく検証は失敗し、制御はクライアントに返されます。 |
| Requisite | 検証は、残りのモジュールに対して継続されます。残りのモジュールの要件が満たされると、リクエストによる承認の続行が許可されます。 | このリクエストは即座にクライアントに返されます。 |
| Sufficient |
検証は成功して完了したと判断され、以前の |
検証は、残りのモジュールのリストへと続きます。このステータスは、 |
| Optional |
|
検証は、残りのモジュールのリストへと続きます。このステータスは、 |
すべての ServerAuthModule インスタンスについては、AuthException を出力すると、エラーがすぐにクライアントに報告され、それ以上のモジュール呼び出しは行われません。
secureResponse
secureResponse の呼び出し中には、各 ServerAuthModule が呼び出されます。ただし、この場合は逆順で、モジュールは secureResponse で措置をとるだけです。モジュールが validateResponse でアクションを実行した場合、この追跡は、このモジュールが行います。
制御フラグは、secureResponse 処理には影響しません。次のいずれかに該当する場合、処理は終了します。
-
すべての
ServerAuthModuleインスタンスが呼び出されている。 -
モジュールは
AuthStatus.SEND_FAILUREを返している。 -
モジュールは
AuthExceptionを出力している。
SecurityIdentity の作成
認証プロセスが完了すると、CallbackHandler への Callbacks の結果として、ディプロイメントの SecurityDomain の org.wildfly.security.auth.server.SecurityIdentity が作成されます。Callbacks に応じて、これは SecurityDomain から直接ロードされたアイデンティティーになるか、そのコールバックによって記述されるアドホックアイデンティティーになります。この SecurityIdentity は、他の認証メカニズムの場合と同じように、リクエストに関連付けられます。