2.5. 認証メカニズムの組み合わせ
異なるソースからユーザー認証情報が提供される場合は、認証メカニズムを組み合わせることができます。たとえば、ビルトイン Basic 認証メカニズムと Quarkus quarkus-oidc
ベアラートークン認証メカニズムを組み合わせることができます。
Quarkus quarkus-oidc
ベアラートークンと smallrye-jwt
認証メカニズムは、両方とも HTTP ベアラートークン認証スキームから抽出されたトークンを検証しようとするため、この 2 つを組み合わせることはできません。
2.5.1. HTTP セキュリティーポリシーを使用してパスベース認証を有効にする
次の設定例は、特定のリクエストパスに対して 1 つの認証メカニズムのみ選択できるようにする方法を示しています。
quarkus.http.auth.permission.basic-or-bearer.paths=/service quarkus.http.auth.permission.basic-or-bearer.policy=authenticated quarkus.http.auth.permission.basic.paths=/basic-only quarkus.http.auth.permission.basic.policy=authenticated quarkus.http.auth.permission.basic.auth-mechanism=basic quarkus.http.auth.permission.bearer.paths=/bearer-only quarkus.http.auth.permission.bearer.policy=authenticated quarkus.http.auth.permission.bearer.auth-mechanism=bearer
auth-mechanism
プロパティーの値が、HttpAuthenticationMechanism
でサポートされている認証スキーム (basic
、bearer
、form
など) と一致していることを確認します。
2.5.2. アノテーションを使用して Jakarta REST エンドポイントのパスベース認証を有効にする
アノテーションを使用して、各 Jakarta REST エンドポイントに固有の認証メカニズムを選択できます。アノテーションを使用して認証メカニズムを選択できるのは、REST エンドポイントが一致した後に限定されるため、この機能は プロアクティブ認証 が無効になっている場合にのみ有効になります。以下の方法で、REST エンドポイントごとに認証メカニズムを選択できます。
quarkus.http.auth.proactive=false
import io.quarkus.oidc.AuthorizationCodeFlow; import io.quarkus.vertx.http.runtime.security.annotation.BasicAuthentication; import jakarta.annotation.security.RolesAllowed; import jakarta.ws.rs.GET; import jakarta.ws.rs.Path; @Path("hello") public class HelloResource { @GET @BasicAuthentication 1 2 @Path("basic") public String basicAuthMechanism() { return "basic"; } @GET @RolesAllowed("admin") 3 @AuthorizationCodeFlow 4 @Path("code-flow") public String codeFlowAuthMechanism() { return "code-flow"; } }
- 1
- REST エンドポイント
/hello/basic
には、Basic 認証 を使用しなければアクセスできません。 - 2
@BasicAuthentication
アノテーションに標準のセキュリティーアノテーションが付属していない場合は、デフォルトで@Authenticated
アノテーションが追加されるため、このエンドポイントには認証が必要です。- 3
@AuthorizationCodeFlow
アノテーションは、@RolesAllowed
や@PermissionsAllowed
などの他の標準セキュリティーアノテーションと組み合わせることができます。- 4
- REST エンドポイント
/hello/code-flow
には、OIDC 認可コードフローメカニズム を使用しなければアクセスできません。
認証メカニズム^ | アノテーション |
---|---|
Basic 認証メカニズム |
|
フォームベース認証メカニズム |
|
相互 TLS 認証メカニズム |
|
ベアラートークン認証メカニズム |
|
OIDC 認可コードフローメカニズム |
|
SmallRye JWT 認証メカニズム |
|
Quarkus は、認証メカニズムアノテーションが付けられたエンドポイントを自動的に保護します。REST エンドポイントとリソースに標準のセキュリティーアノテーションが存在しない場合は、io.quarkus.security.Authenticated
アノテーションが追加されます。
io.quarkus.vertx.http.runtime.security.annotation.HttpAuthenticationMechanism
アノテーションを使用して、スキームに基づき任意の認証メカニズムを選択することもできます。アノテーションベースでは、quarkus.http.auth.permission.basic.auth-mechanism=custom
設定プロパティーは @HttpAuthenticationMechanism("custom")
アノテーションに相当します。
さまざまな Jakarta EE 仕様との整合性を保つために、アノテーションの継承に依存するのではなく、常にアノテーションを繰り返すことが推奨されます。
2.5.2.1. HTTP セキュリティーポリシーとの組み合わせ方法
個々のリソースへのアクセスが許可されるロールを定義する最も簡単な方法は、@RolesAllowed
アノテーションを使用する方法です。ただし、次の例のように HTTP セキュリティーポリシーを使用することもできます。
quarkus.http.auth.policy.roles1.roles-allowed=user quarkus.http.auth.permission.roles1.paths=/hello/code-flow quarkus.http.auth.permission.roles1.applies-to=JAXRS 1 quarkus.http.auth.permission.roles1.policy=roles1 quarkus.http.auth.permission.roles1.methods=GET 2