Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

2.5. 認証メカニズムの組み合わせ

異なるソースからユーザー認証情報が提供される場合は、認証メカニズムを組み合わせることができます。たとえば、組み込みの Basic 認証メカニズムと Quarkus quarkus-oidc ベアラートークン認証メカニズムを組み合わせることができます。

いずれかの認証メカニズムによって最初の SecurityIdentity が生成されると、すぐに認証プロセスが完了します。

2.5.1. 統合認証
リンクのコピー

場合によっては、登録されているすべての認証メカニズムが SecurityIdentity を作成することが必要になることがあります。これが必要になるのは、トークンなどの認証情報を 相互 TLS 認証 経由で渡す必要がある場合です。たとえば、ユーザーが Virtual Private Network 経由で認証している場合や、トークンの検証を成功させるために現在のトークンをクライアント証明書にバインドして、このトークンをクライアント証明書とともに Quarkus に渡している同じクライアントにトークンが正確に発行されたことを保証する場合などです。

Quarkus ではこのような認証は inclusive (統合認証) と呼ばれ、次のようにして有効にできます。 

quarkus.http.auth.inclusive=true
Copy to Clipboard Toggle word wrap

認証が統合認証である場合、最初の認証メカニズムによって作成された SecurityIdentity をアプリケーションコードに注入できます。たとえば、相互 TLS 認証 と Basic 認証メカニズムの両方の認証が必要な場合、相互 TLS 認証 メカニズムが最初に SecurityIdentity を作成します。

注記

統合認証が有効な場合、相互 TLS 認証 メカニズムの優先度が最も高くなります。これにより、注入された SecurityIdentity が、常に 相互 TLS 認証 を表すようになり、他の認証メカニズムが提供する SecurityIdentity アイデンティティーにアクセスするために使用できるようになります。

追加の SecurityIdentity インスタンスには、最初の SecurityIdentity の quarkus.security.identities 属性としてアクセスできます。しかし、これらの追加のアイデンティティーに直接アクセスする必要がない場合があります。たとえば、相互 TLS 認証 メカニズムと OIDC ベアラー認証 メカニズムの両方が組み合わされて認証が行われている場合、認証されたベアラートークンは、相互 TLS 認証 によって作成された SecurityIdentity とともにトークン認証情報として注入できます。以下に例を示します。 

package org.acme.security;

import io.quarkus.oidc.AccessTokenCredential;
import io.quarkus.oidc.common.runtime.OidcConstants;
import io.quarkus.security.identity.SecurityIdentity;
import io.quarkus.vertx.http.runtime.security.HttpSecurityUtils;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.inject.Inject;

@ApplicationScoped
public class InclusiveAuthExampleBean {

    @Inject
    SecurityIdentity mtlsIdentity;
1 


    @Inject
    AccessTokenCredential accessTokenCredential;

    private AccessTokenCredential getAccessTokenCredential() {
        if (doItHardWay()) {
            var securityIdentities = HttpSecurityUtils.getSecurityIdentities(mtlsIdentity);
2 

            if (securityIdentities != null) {
                SecurityIdentity bearerIdentity = securityIdentities.get(OidcConstants.BEARER_SCHEME);
                if (bearerIdentity != null) {
                    return bearerIdentity.getCredential(AccessTokenCredential.class);
                }
            }
        }
        return accessTokenCredential;
    }

}
Copy to Clipboard Toggle word wrap
1
これは、優先度が最も高い該当する認証メカニズムによって作成された SecurityIdentity です。
2
その他の該当する認証メカニズムは認証を実行し、SecurityIdentity で利用できます。
重要

Quarkus quarkus-oidc ベアラートークンと smallrye-jwt 認証メカニズムは、両方とも HTTP ベアラートークン認証スキームから抽出されたトークンを検証しようとするため、この 2 つを組み合わせることはできません。

2.5.2. パスベース認証
リンクのコピー

2.5.2.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
Copy to Clipboard Toggle word wrap

auth-mechanism プロパティーの値が、HttpAuthenticationMechanism でサポートされている認証スキーム (basic、bearer、form など) と一致していることを確認します。

2.5.2.2. アノテーションを使用して Jakarta REST エンドポイントのパスベース認証を有効にする
リンクのコピー

アノテーションを使用して、各 Jakarta REST エンドポイントに固有の認証メカニズムを選択できます。アノテーションを使用して認証メカニズムを選択できるのは、REST エンドポイントが一致した後に限定されるため、この機能は プロアクティブ認証 が無効になっている場合にのみ有効になります。以下の方法で、REST エンドポイントごとに認証メカニズムを選択できます。 

quarkus.http.auth.proactive=false
Copy to Clipboard Toggle word wrap 
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";
    }
}
Copy to Clipboard Toggle word wrap
1
REST エンドポイント /hello/basic には、Basic 認証 を使用しなければアクセスできません。
2
@BasicAuthentication アノテーションに標準のセキュリティーアノテーションが付属していない場合は、デフォルトで @Authenticated アノテーションが追加されるため、このエンドポイントには認証が必要です。
3
@AuthorizationCodeFlow アノテーションは、@RolesAllowed や @PermissionsAllowed などの他の標準セキュリティーアノテーションと組み合わせることができます。
4
REST エンドポイント /hello/code-flow には、OIDC 認可コードフローメカニズム を使用しなければアクセスできません。
Expand
表2.3 サポートされている認証メカニズムのアノテーション
認証メカニズムアノテーション

Basic 認証メカニズム

io.quarkus.vertx.http.runtime.security.annotation.BasicAuthentication

フォームベース認証メカニズム

io.quarkus.vertx.http.runtime.security.annotation.FormAuthentication

相互 TLS 認証メカニズム

io.quarkus.vertx.http.runtime.security.annotation.MTLSAuthentication

ベアラートークン認証メカニズム

io.quarkus.oidc.BearerTokenAuthentication

OIDC 認可コードフローメカニズム

io.quarkus.oidc.AuthorizationCodeFlow

SmallRye JWT 認証メカニズム

io.quarkus.smallrye.jwt.runtime.auth.BearerTokenAuthentication

ヒント

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.3. 統合認証を使用したパスベース認証の有効化
リンクのコピー

デフォルトでは、Quarkus は パスベース認証 において、1 つのパスにつき 1 つの認証メカニズムしかサポートしていません。パスベース認証に複数の認証メカニズムを使用する必要がある場合は、「Security Tips and Tricks」ガイドの Dealing with more than one HttpAuthenticationMechanism セクションに記載されているように、カスタムの HttpAuthenticationMechanism を作成できます。もう 1 つの方法は、統合認証 を lax モードで有効にして、登録されているすべての HTTP 認証メカニズムがメカニズム固有の SecurityIdentity を作成したことを確認するカスタムの HttpSecurityPolicy または PermissionChecker を記述することです。

lax モードでの統合認証の有効化

quarkus.http.auth.inclusive-mode=lax
1 

quarkus.http.auth.inclusive=true
Copy to Clipboard Toggle word wrap

1
統合認証では、デフォルトで、登録されているすべての HTTP 認証メカニズムが SecurityIdentity を作成する必要があります。一方、lax モードでは、少なくとも 1 つ以上の登録済みの HttpAuthenticationMechanism が SecurityIdentity を作成すると、認証が成功します。

たとえば、mTLS、Basic、OIDC の 3 つの登録済みメカニズムがあり、hello メソッドへのアクセスを許可するのに必要なものが、Basic 認証と mTLS 認証の成功だけであるとします。この場合、lax モードで統合認証を有効にすると、次の例に示すように、アイデンティティーを生成したメカニズムを確認できます。

HTTP 認証メカニズムのチェックの例

import io.quarkus.security.PermissionChecker;
import io.quarkus.security.PermissionsAllowed;
import io.quarkus.security.identity.SecurityIdentity;
import io.quarkus.vertx.http.runtime.security.HttpSecurityUtils;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;

import java.util.Map;

@Path("/hello")
public class HelloResource {

    @PermissionsAllowed("mtls-basic")
    @GET
    public String hello() {
        return "Hello world";
    }

    @PermissionChecker("mtls-basic")
    boolean isMtlsAndBasicAuthentication(SecurityIdentity identity) {
        Map<String, SecurityIdentity> identities = HttpSecurityUtils.getSecurityIdentities(identity);
        if (identities != null) {
            return identities.containsKey("basic") && identities.containsKey("x509");
1 

        }
        return false;
    }
}
Copy to Clipboard Toggle word wrap

1
mTLS と Basic の両方の認証メカニズムが現在のリクエストを認証したことが確認された場合にのみ、エンドポイントへのアクセスを許可します。

2.5.2.4. 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
Copy to Clipboard Toggle word wrap
1
エンドポイント固有の認証メカニズムを選択してから、このポリシーの権限チェックを遅らせます。
2
roles1 権限が、@AuthorizationCodeFlow アノテーションが付けられたエンドポイントのみと一致するようにします。アノテーションが付いていないエンドポイントは、applies-to=JAXRS オプションによって生じる遅延を回避する必要があります。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat