第1章 Web エンドポイントの認可

Quarkus には、プラグ可能な Web セキュリティーレイヤーが組み込まれています。セキュリティーを有効にすると、システムはすべての HTTP リクエストに対して権限チェックを実行し、リクエストを続行するかどうかを決定します。

注記

Jakarta RESTful Web サービスを使用する場合は、HTTP パスレベルのマッチングではなく、quarkus.security.jaxrs.deny-unannotated-endpoints または quarkus.security.jaxrs.default-roles-allowed を使用してデフォルトのセキュリティー要件を設定することを検討してください。アノテーションにより、個々のエンドポイントでこれらのプロパティーをオーバーライドできるためです。

認可は、セキュリティープロバイダーが提供するユーザーロールに基づいて行われます。ユーザーロールをカスタマイズするには、SecurityIdentityAugmentor を作成します。Security Identity Customization を参照してください。

1.1. 設定を使用した認可
リンクのコピー

権限は、Quarkus 設定で権限セットによって定義されます。各権限セットで、アクセス制御用のポリシーを指定します。

注記

セキュリティーポリシーの paths プロパティーに、現在のリクエストパスと同じで、詳細なパスが含まれている場合、パスが一致する他のセキュリティーポリシーよりも、そのパスが優先されます。

Expand

表1.1 Quarkus ポリシーの概要
組み込みのポリシー	説明
`deny`	このポリシーはすべてのユーザーを拒否します。
`permit`	このポリシーはすべてのユーザーを許可します。
`authenticated`	このポリシーは認証済みユーザーのみを許可します。

特定のロールを持つユーザーにリソースへのアクセスを許可するロールベースのポリシーを定義できます。

ロールベースのポリシーの例

quarkus.http.auth.policy.role-policy1.roles-allowed=user,admin

quarkus.http.auth.policy.role-policy1.roles-allowed=user,admin

Copy to Clipboard

Toggle word wrap

1: これは、user ロールと admin ロールを持つユーザーを許可するロールベースのポリシーを定義します。

次の設定例に示すように、application.properties ファイルで定義されている組み込みの権限セットを設定することで、カスタムポリシーを参照できます。

ポリシー設定の例

quarkus.http.auth.permission.permit1.paths=/public/*                            
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET

quarkus.http.auth.permission.deny1.paths=/forbidden                             
quarkus.http.auth.permission.deny1.policy=deny

quarkus.http.auth.permission.roles1.paths=/roles-secured/*,/other/*,/api/*      
quarkus.http.auth.permission.roles1.policy=role-policy1

quarkus.http.auth.permission.permit1.paths=/public/*


quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET

quarkus.http.auth.permission.deny1.paths=/forbidden


quarkus.http.auth.permission.deny1.policy=deny

quarkus.http.auth.permission.roles1.paths=/roles-secured/*,/other/*,/api/*


quarkus.http.auth.permission.roles1.policy=role-policy1

Copy to Clipboard

Toggle word wrap

1: この権限は、デフォルトの組み込みの permit ポリシーを参照して、/public への GET メソッドを許可します。この場合、このリクエストはいずれにせよ許可されるため、上記の設定はこの例に影響しません。
2: この権限は、/forbidden パスと /forbidden/ パスの両方の組み込み deny ポリシーを参照します。末尾が * でないため、これはパスの完全一致です。
3: この権限セットは、以前に定義されたポリシーを参照します。roles1 は例の名前です。権限セットには任意の名前を付けることができます。

重要

上記の例の正確なパスパターン /forbidden は、/forbidden/ パスも保護します。この方法では、以下の例の forbidden エンドポイントは deny1 権限により保護されます。

package org.acme.crud;

import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;

@Path("/forbidden")
public class ForbiddenResource {
    @GET
    public String forbidden() { 
        return "No!";
    }
}

package org.acme.crud;

import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;

@Path("/forbidden")
public class ForbiddenResource {
    @GET
    public String forbidden() {


        return "No!";
    }
}

Copy to Clipboard

Toggle word wrap

1: forbidden エンドポイントを保護するには、/forbidden パスと /forbidden/ パスの両方を保護する必要があります。

/forbidden/ パスへのアクセスを許可する必要がある場合は、以下の例のように、より具体的な正確なパスを使用して新しい権限を追加してください。

quarkus.http.auth.permission.permit1.paths=/forbidden/ 
quarkus.http.auth.permission.permit1.policy=permit

quarkus.http.auth.permission.permit1.paths=/forbidden/


quarkus.http.auth.permission.permit1.policy=permit

Copy to Clipboard

Toggle word wrap

1: /forbidden/ パスは保護されていません。

1.1.1. カスタムの HttpSecurityPolicy
リンクのコピー

場合に応じて、独自の名前付きポリシーを登録すると便利です。これを実行するには、io.quarkus.vertx.http.runtime.security.HttpSecurityPolicy インターフェイスを実装するアプリケーションスコープの CDI Bean を作成します。以下にその例を示します。

import jakarta.enterprise.context.ApplicationScoped;

import io.quarkus.security.identity.SecurityIdentity;
import io.quarkus.vertx.http.runtime.security.HttpSecurityPolicy;
import io.smallrye.mutiny.Uni;
import io.vertx.ext.web.RoutingContext;

@ApplicationScoped
public class CustomNamedHttpSecPolicy implements HttpSecurityPolicy {
    @Override
    public Uni<CheckResult> checkPermission(RoutingContext event, Uni<SecurityIdentity> identity,
            AuthorizationRequestContext requestContext) {
        if (customRequestAuthorization(event)) {
            return CheckResult.permit();
        }
        return CheckResult.deny();
    }

    @Override
    public String name() {
        return "custom"; 
    }

    private static boolean customRequestAuthorization(RoutingContext event) {
        // here comes your own security check
        return !event.request().path().endsWith("denied");
    }
}

import jakarta.enterprise.context.ApplicationScoped;

import io.quarkus.security.identity.SecurityIdentity;
import io.quarkus.vertx.http.runtime.security.HttpSecurityPolicy;
import io.smallrye.mutiny.Uni;
import io.vertx.ext.web.RoutingContext;

@ApplicationScoped
public class CustomNamedHttpSecPolicy implements HttpSecurityPolicy {
    @Override
    public Uni<CheckResult> checkPermission(RoutingContext event, Uni<SecurityIdentity> identity,
            AuthorizationRequestContext requestContext) {
        if (customRequestAuthorization(event)) {
            return CheckResult.permit();
        }
        return CheckResult.deny();
    }

    @Override
    public String name() {
        return "custom";


    }

    private static boolean customRequestAuthorization(RoutingContext event) {
        // here comes your own security check
        return !event.request().path().endsWith("denied");
    }
}

Copy to Clipboard

Toggle word wrap

1: 名前付き HTTP セキュリティーポリシーは、application.properties パスマッチングルールにマッチするリクエストにのみ適用されます。

設定ファイルから参照されるカスタム名の HttpSecurityPolicy の例

quarkus.http.auth.permission.custom1.paths=/custom/*
quarkus.http.auth.permission.custom1.policy=custom

quarkus.http.auth.permission.custom1.paths=/custom/*
quarkus.http.auth.permission.custom1.policy=custom

Copy to Clipboard

Toggle word wrap

1: カスタムポリシー名は、io.quarkus.vertx.http.runtime.security.HttpSecurityPolicy.name メソッドにより返される値とマッチする必要があります。

または、@AuthorizationPolicy セキュリティーアノテーションを使用して、カスタム名 HttpSecurityPolicy を Jakarta REST エンドポイントにバインドすることもできます。

Jakarta REST エンドポイントにバインドされたカスタム名の HttpSecurityPolicy の例

import io.quarkus.vertx.http.security.AuthorizationPolicy;
import jakarta.annotation.security.DenyAll;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;

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

    @AuthorizationPolicy(name = "custom") 
    @GET
    public String hello() {
        return "hello";
    }

}

import io.quarkus.vertx.http.security.AuthorizationPolicy;
import jakarta.annotation.security.DenyAll;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;

@DenyAll


@Path("hello")
public class HelloResource {

    @AuthorizationPolicy(name = "custom")


    @GET
    public String hello() {
        return "hello";
    }

}

Copy to Clipboard

Toggle word wrap

1: @AuthorizationPolicy アノテーションは、他の標準セキュリティーアノテーションと一緒に使用できます。通常どおり、メソッドレベルのアノテーションはクラスレベルのアノテーションよりも優先されます。
2: カスタム名の HttpSecurityPolicy を Jakarta REST hello エンドポイントに適用します。

ヒント

すべてのリクエストで呼び出されるグローバルの HttpSecurityPolicy を作成することもできます。io.quarkus.vertx.http.runtime.security.HttpSecurityPolicy.name メソッドを実装せず、ポリシーに名前を付けないままにしてください。

1.1.2. HttpSecurityPolicy への @RequestScoped Bean の注入
リンクのコピー

@RequestScoped Bean は、CDI リクエストコンテキストがアクティブな場合にのみ注入できます。コンテキストは、@ActivateRequestContext などを使用してユーザーがアクティブ化できますが、Quarkus がいくつかの @RequestScoped Bean を準備する前に、認可が行われます。CDI リクエストコンテキストは、Quarkus にアクティブ化および準備させることを推奨します。たとえば、jakarta.ws.rs.core.UriInfo Bean などの Jakarta REST コンテキストから Bean を注入する状況を考えてみましょう。この場合、HttpSecurityPolicy を Jakarta REST エンドポイントに適用する必要があります。これは、次のいずれかの方法で実現できます。

@AuthorizationPolicy セキュリティーアノテーションを使用します。
quarkus.http.auth.permission.custom1.applies-to=jaxrs 設定プロパティーを設定します。

1.1.3. パスとメソッドのマッチング
リンクのコピー

権限セットでは、パスとメソッドをコンマ区切りリスト形式で指定することもできます。パスの末尾がワイルドカード * の場合は、そのパスによって生成されたクエリーがすべてのサブパスにマッチします。それ以外の場合は、クエリーが完全一致を照会し、特定のパスにのみマッチします。

quarkus.http.auth.permission.permit1.paths=/public*,/css/*,/js/*,/robots.txt    
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET,HEAD

quarkus.http.auth.permission.permit1.paths=/public*,/css/*,/js/*,/robots.txt


quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET,HEAD

Copy to Clipboard

Toggle word wrap

1: パスの末尾の * ワイルドカードは、0 個以上のパスセグメントにマッチしますが、/public パスから始まる単語にはマッチしません。そのため、/public-info のようなパスはこのパターンにマッチしません。

1.1.4. パスにはマッチするがメソッドにはマッチしない場合
リンクのコピー

パスに基づいて 1 つ以上の権限セットにマッチしても、必要なメソッドのいずれにもマッチしないと、リクエストは拒否されます。

ヒント

上記の権限セットが指定されていると、GET/public/foo は、パスとメソッドの両方にマッチするため、許可されます。対照的に、POST/public/foo は、パスにはマッチしますが、メソッドにはマッチしないため、拒否されます。

1.1.5. 複数のパスのマッチング: 最長パスが優先される
リンクのコピー

マッチングは、常に "最長パスが優先される" という基準で行われます。より詳細な権限セットがマッチした場合、それよりも詳細でない権限セットは考慮されません。

quarkus.http.auth.permission.permit1.paths=/public/*
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET,HEAD

quarkus.http.auth.permission.deny1.paths=/public/forbidden-folder/*
quarkus.http.auth.permission.deny1.policy=deny

quarkus.http.auth.permission.permit1.paths=/public/*
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET,HEAD

quarkus.http.auth.permission.deny1.paths=/public/forbidden-folder/*
quarkus.http.auth.permission.deny1.policy=deny

Copy to Clipboard

Toggle word wrap

ヒント

上記の権限セットの場合、GET /public/forbidden-folder/foo は、両方の権限セットのパスとマッチします。しかし、より長いパスが deny1 権限セットのパスとマッチするため、deny1 が選択され、リクエストが拒否されます。

注記

前述の deny1 権限と permit1 権限の例で示したように、サブパスの権限がルートパスの権限よりも優先されます。

このルールをさらに例示するために、サブパス権限ではパブリックリソースへのアクセスを許可し、ルートパス権限では認可を要求するシナリオを示します。

quarkus.http.auth.policy.user-policy.roles-allowed=user
quarkus.http.auth.permission.roles.paths=/api/*
quarkus.http.auth.permission.roles.policy=user-policy

quarkus.http.auth.permission.public.paths=/api/noauth/*
quarkus.http.auth.permission.public.policy=permit

quarkus.http.auth.policy.user-policy.roles-allowed=user
quarkus.http.auth.permission.roles.paths=/api/*
quarkus.http.auth.permission.roles.policy=user-policy

quarkus.http.auth.permission.public.paths=/api/noauth/*
quarkus.http.auth.permission.public.policy=permit

Copy to Clipboard

Toggle word wrap

1.1.6. 複数のサブパスのマッチング: * ワイルドカードへの最長パスが優先される
リンクのコピー

前の例では、パスの末尾が * ワイルドカードの場合に、すべてのサブパスがマッチすることを示しました。

このワイルドカードはパスの途中で適用され、単一のパスのセグメントを表すことも可能です。他のパスセグメント文字と混在させることはできません。したがって、/public/*/about-us パスのように、* ワイルドカードは常にパス区切り文字によって囲まれます。

複数のパスパターンが同じリクエストパスに対応する場合、システムは * ワイルドカードに至る最長のサブパスを選択します。この場合は、すべてのパスセグメント文字が * ワイルドカードよりも詳細なものとして扱われます。

以下は簡単な例です。

quarkus.http.auth.permission.secured.paths=/api/*/detail                    
quarkus.http.auth.permission.secured.policy=authenticated
quarkus.http.auth.permission.public.paths=/api/public-product/detail        
quarkus.http.auth.permission.public.policy=permit

quarkus.http.auth.permission.secured.paths=/api/*/detail


quarkus.http.auth.permission.secured.policy=authenticated
quarkus.http.auth.permission.public.paths=/api/public-product/detail


quarkus.http.auth.permission.public.policy=permit

Copy to Clipboard

Toggle word wrap

1: /api/product/detail などのリクエストパスには、認証済みユーザーのみがアクセスできます。
2: パス /api/public-product/detail はより詳細であるため、どのユーザーもアクセスできます。

重要

認可を使用した設定で保護するパスは、すべてテストする必要があります。複数のワイルドカードを使用してパスパターンを記述するのは、手間がかかる場合があります。パスが意図したとおりに認可されていることを確認してください。

次の例では、パスは最も詳細なものから最も詳細でないものの順に並べられています。

最も詳細なパスから最も詳細でないパスの順に並べたリクエストパス /one/two/three/four/five のマッチ

/one/two/three/four/five
/one/two/three/four/*
/one/two/three/*/five
/one/two/three/*/*
/one/two/*/four/five
/one/*/three/four/five
/*/two/three/four/five
/*/two/three/*/five
/*

/one/two/three/four/five
/one/two/three/four/*
/one/two/three/*/five
/one/two/three/*/*
/one/two/*/four/five
/one/*/three/four/five
/*/two/three/four/five
/*/two/three/*/five
/*

Copy to Clipboard

Toggle word wrap

重要

パスの末尾の * ワイルドカードは、0 個以上のパスセグメントとマッチします。その他の場所に指定された * ワイルドカードは、1 つのパスセグメントに完全一致します。

1.1.7. 複数のパスのマッチング: 最も詳細なメソッドが優先される
リンクのコピー

パスが複数の権限セットに登録されている場合は、リクエストにマッチする HTTP メソッドを明示的に指定している権限セットが優先されます。この場合、メソッドのない権限セットが適用されるのは、リクエストメソッドがメソッドの指定を持つ権限セットとマッチしない場合に限られます。

quarkus.http.auth.permission.permit1.paths=/public/*
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET,HEAD

quarkus.http.auth.permission.deny1.paths=/public/*
quarkus.http.auth.permission.deny1.policy=deny

quarkus.http.auth.permission.permit1.paths=/public/*
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET,HEAD

quarkus.http.auth.permission.deny1.paths=/public/*
quarkus.http.auth.permission.deny1.policy=deny

Copy to Clipboard

Toggle word wrap

注記

上記の権限セットは、GET/public/foo が両方の権限セットのパスにマッチすることを示しています。ただし、これは permit1 権限セットの明示的なメソッドと明確に一致しています。したがって、permit1 が選択され、リクエストが受け入れられます。

対照的に、PUT/public/foo は、permit1 のメソッド権限とマッチしません。その結果、deny1 がアクティブになり、リクエストが拒否されます。

1.1.8. 複数のパスとメソッドのマッチング: どちらも優先される
リンクのコピー

場合に応じて、前述のルールにより、複数の権限セットが同時に適用されることがあります。その場合、リクエストを続行するには、すべての権限でアクセスが許可されている必要があります。これを実現するには、両方にメソッドを追加するか、両方からメソッドを除外する必要があります。メソッド固有のマッチが優先されます。

quarkus.http.auth.policy.user-policy1.roles-allowed=user
quarkus.http.auth.policy.admin-policy1.roles-allowed=admin

quarkus.http.auth.permission.roles1.paths=/api/*,/restricted/*
quarkus.http.auth.permission.roles1.policy=user-policy1

quarkus.http.auth.permission.roles2.paths=/api/*,/admin/*
quarkus.http.auth.permission.roles2.policy=admin-policy1

quarkus.http.auth.policy.user-policy1.roles-allowed=user
quarkus.http.auth.policy.admin-policy1.roles-allowed=admin

quarkus.http.auth.permission.roles1.paths=/api/*,/restricted/*
quarkus.http.auth.permission.roles1.policy=user-policy1

quarkus.http.auth.permission.roles2.paths=/api/*,/admin/*
quarkus.http.auth.permission.roles2.policy=admin-policy1

Copy to Clipboard

Toggle word wrap

ヒント

上記の権限セットの場合、GET /api/foo は両方の権限セットのパスにマッチするため、user と admin の両方のロールが必要です。

1.1.9. アクセスを拒否するための設定プロパティー
リンクのコピー

次の設定は、ロールベースのアクセス制御 (RBAC) の拒否動作を変更するものです。

quarkus.security.jaxrs.deny-unannotated-endpoints=true|false: true に設定すると、すべての Jakarta REST エンドポイントへのアクセスがデフォルトで拒否されます。Jakarta REST エンドポイントにセキュリティーアノテーションがない場合は、エンドポイントのデフォルトが @DenyAll 動作になります。これにより、保護されているはずのエンドポイントが誤って公開されることを回避できます。デフォルトは false です。
quarkus.security.jaxrs.default-roles-allowed=role1,role2: アノテーションのないエンドポイントのデフォルトのロール要件を定義します。** ロールは、すべての認証済みユーザーを意味する特別なロールです。これを deny-unannotated-endpoints と組み合わせることはできません。代わりに deny が有効になるためです。
quarkus.security.deny-unannotated-members=true|false: true に設定すると、セキュリティーアノテーションを持たないが、セキュリティーアノテーションを持つメソッドを含むクラスで定義されているすべての CDI メソッドと Jakarta REST エンドポイントへのアクセスが拒否されます。デフォルトは false です。

1.1.10. 権限の無効化
リンクのコピー

次のように、宣言された各権限に対して enabled プロパティーを設定することで、ビルド時に権限を無効にできます。

quarkus.http.auth.permission.permit1.enabled=false
quarkus.http.auth.permission.permit1.paths=/public/*,/css/*,/js/*,/robots.txt
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET,HEAD

quarkus.http.auth.permission.permit1.enabled=false
quarkus.http.auth.permission.permit1.paths=/public/*,/css/*,/js/*,/robots.txt
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET,HEAD

Copy to Clipboard

Toggle word wrap

権限は、システムプロパティーまたは環境変数 (例: -Dquarkus.http.auth.permission.permit1.enabled=true) を使用して実行時に再度有効にできます。

1.1.11. 権限パスと HTTP ルートパス
リンクのコピー

quarkus.http.root-path 設定プロパティーは、http エンドポイントのコンテキストパスを変更します。

デフォルトでは、quarkus.http.root-path は設定した権限パスの先頭に自動的に追加されるため、スラッシュを使用しないでください。次に例を示します。

quarkus.http.auth.permission.permit1.paths=public/*,css/*,js/*,robots.txt

quarkus.http.auth.permission.permit1.paths=public/*,css/*,js/*,robots.txt

Copy to Clipboard

Toggle word wrap

この設定は次のものと同等です。

quarkus.http.auth.permission.permit1.paths=${quarkus.http.root-path}/public/*,${quarkus.http.root-path}/css/*,${quarkus.http.root-path}/js/*,${quarkus.http.root-path}/robots.txt

quarkus.http.auth.permission.permit1.paths=${quarkus.http.root-path}/public/*,${quarkus.http.root-path}/css/*,${quarkus.http.root-path}/js/*,${quarkus.http.root-path}/robots.txt

Copy to Clipboard

Toggle word wrap

先頭にスラッシュを付けると、設定された権限パスの解釈方法が変わります。設定された URL がそのまま使用され、quarkus.http.root-path の値が変更されても、パスが調整されません。

例:

quarkus.http.auth.permission.permit1.paths=/public/*,css/*,js/*,robots.txt

quarkus.http.auth.permission.permit1.paths=/public/*,css/*,js/*,robots.txt

Copy to Clipboard

Toggle word wrap

この設定は、固定または静的 URL /public から提供されるリソースにのみ影響します。この URL は、quarkus.http.root-path が / 以外に設定されていると、アプリケーションリソースとマッチしない可能性があります。

詳細は、Path Resolution in Quarkus を参照してください。

1.1.12. SecurityIdentity ロールのマッピング
リンクのコピー

現在の要求を承認するために選択された、優先されるロールベースのポリシーは、SecurityIdentity ロールをデプロイメント固有のロールにマッピングできます。その後、デプロイメント固有のロールを、@RolesAllowed アノテーションを使用してエンドポイント認可に適用できます。

quarkus.http.auth.policy.admin-policy1.roles.admin=Admin1 
quarkus.http.auth.permission.roles1.paths=/* 
quarkus.http.auth.permission.roles1.policy=admin-policy1

quarkus.http.auth.policy.admin-policy1.roles.admin=Admin1


quarkus.http.auth.permission.roles1.paths=/*


quarkus.http.auth.permission.roles1.policy=admin-policy1

Copy to Clipboard

Toggle word wrap

1: admin ロールを Admin1 ロールにマッピングします。SecurityIdentity に admin と Admin1 の両方のロールが付与されます。
2: /* パスは保護されており、認証された HTTP リクエストのみにアクセスが許可されます。

パスに関係なく、SecurityIdentity ロールをデプロイメント固有のロールにマップするだけの場合は、次のようにすることもできます。

quarkus.http.auth.roles-mapping.admin=Admin1

quarkus.http.auth.roles-mapping.admin=Admin1

Copy to Clipboard

Toggle word wrap

1: admin ロールを Admin1 ロールにマッピングします。SecurityIdentity に admin と Admin1 の両方のロールが付与されます。
2: /* パスは保護されていません。標準のセキュリティーアノテーションを使用してエンドポイントを保護するか、この設定プロパティーに加えて HTTP 権限を定義する必要があります。

プログラムによる設定を希望する場合は、io.quarkus.vertx.http.security.HttpSecurity CDI イベントを使用して同じマッピングを追加できます。

package org.acme.http.security;

import io.quarkus.vertx.http.security.HttpSecurity;
import jakarta.enterprise.event.Observes;

public class HttpSecurityConfiguration {

    void configure(@Observes HttpSecurity httpSecurity) {
        httpSecurity.rolesMapping("admin", "Admin1");
    }
}

package org.acme.http.security;

import io.quarkus.vertx.http.security.HttpSecurity;
import jakarta.enterprise.event.Observes;

public class HttpSecurityConfiguration {

    void configure(@Observes HttpSecurity httpSecurity) {
        httpSecurity.rolesMapping("admin", "Admin1");
    }
}

Copy to Clipboard

Toggle word wrap

1.1.13. 共有権限チェック
リンクのコピー

非共有権限チェックの重要なルールの 1 つは、最も詳細なパスのマッチが 1 つだけ適用されることです。パスが詳細に一致する場合、そのパスに対して複数の権限を指定でき、すべて適用されます。しかし、何度も繰り返さずに、権限チェックを多くのパスに適用したいという場合もあるでしょう。そのような場合は、共有権限チェックが有用です。共有権限チェックは、権限パスがマッチしたときに常に適用されます。

すべての HTTP リクエストに適用されるカスタム名の HttpSecurityPolicy の例

quarkus.http.auth.permission.custom1.paths=/*
quarkus.http.auth.permission.custom1.shared=true    
quarkus.http.auth.permission.custom1.policy=custom

quarkus.http.auth.policy.admin-policy1.roles-allowed=admin
quarkus.http.auth.permission.roles1.paths=/admin/*
quarkus.http.auth.permission.roles1.policy=admin-policy1

quarkus.http.auth.permission.custom1.paths=/*
quarkus.http.auth.permission.custom1.shared=true


quarkus.http.auth.permission.custom1.policy=custom

quarkus.http.auth.policy.admin-policy1.roles-allowed=admin
quarkus.http.auth.permission.roles1.paths=/admin/*
quarkus.http.auth.permission.roles1.policy=admin-policy1

Copy to Clipboard

Toggle word wrap

1: カスタムの HttpSecurityPolicy も、admin-policy1 ポリシーとともに /admin/1 パスに適用されます。

ヒント

共有権限チェックを多数設定することは、非共有権限チェックを設定する場合よりも効果が低くなります。以下の例のように、共有権限を使用して非共有権限チェックを補完してください。

共有権限を持つ SecurityIdentity ロールのマッピング

quarkus.http.auth.policy.role-policy1.roles.root=admin,user 
quarkus.http.auth.permission.roles1.paths=/secured/*        
quarkus.http.auth.permission.roles1.policy=role-policy1
quarkus.http.auth.permission.roles1.shared=true

quarkus.http.auth.policy.role-policy2.roles-allowed=user    
quarkus.http.auth.permission.roles2.paths=/secured/user/*
quarkus.http.auth.permission.roles2.policy=role-policy2

quarkus.http.auth.policy.role-policy3.roles-allowed=admin
quarkus.http.auth.permission.roles3.paths=/secured/admin/*
quarkus.http.auth.permission.roles3.policy=role-policy3

quarkus.http.auth.policy.role-policy1.roles.root=admin,user


quarkus.http.auth.permission.roles1.paths=/secured/*


quarkus.http.auth.permission.roles1.policy=role-policy1
quarkus.http.auth.permission.roles1.shared=true

quarkus.http.auth.policy.role-policy2.roles-allowed=user


quarkus.http.auth.permission.roles2.paths=/secured/user/*
quarkus.http.auth.permission.roles2.policy=role-policy2

quarkus.http.auth.policy.role-policy3.roles-allowed=admin
quarkus.http.auth.permission.roles3.paths=/secured/admin/*
quarkus.http.auth.permission.roles3.policy=role-policy3

Copy to Clipboard

Toggle word wrap

1: ロール root は、/secured/user/* および /secured/admin/* パスにアクセスできるようになります。
2: /secured/* パスには認証済みユーザーのみがアクセスできます。これにより、/secured/all パスなどが保護されます。
3: 共有権限は常に非共有権限の前に適用されるため、root ロールを持つ SecurityIdentity には user ロールも付与されます。

1.1.14. パス固有の認可をプログラムでセットアップする
リンクのコピー

このガイドでこれまでに説明した認可ポリシーをプログラムで設定することもできます。前述の例を考えてみましょう。

quarkus.http.auth.permission.permit1.paths=/public/*
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET

quarkus.http.auth.permission.deny1.paths=/forbidden
quarkus.http.auth.permission.deny1.policy=deny

quarkus.http.auth.permission.roles1.paths=/roles-secured/*,/other/*,/api/*
quarkus.http.auth.permission.roles1.policy=role-policy1
quarkus.http.auth.policy.role-policy1.roles-allowed=user,admin

quarkus.http.auth.permission.permit1.paths=/public/*
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET

quarkus.http.auth.permission.deny1.paths=/forbidden
quarkus.http.auth.permission.deny1.policy=deny

quarkus.http.auth.permission.roles1.paths=/roles-secured/*,/other/*,/api/*
quarkus.http.auth.permission.roles1.policy=role-policy1
quarkus.http.auth.policy.role-policy1.roles-allowed=user,admin

Copy to Clipboard

Toggle word wrap

同じ認可ポリシーをプログラムで設定することもできます。

package org.acme.http.security;

import jakarta.enterprise.event.Observes;

import io.quarkus.vertx.http.security.HttpSecurity;

public class HttpSecurityConfiguration {

    void configure(@Observes HttpSecurity httpSecurity) {
        httpSecurity
                .get("/public/*").permit()
                .path("/roles-secured/*", "/other/*", "/api/*").roles("admin", "user")
                .path("/forbidden").authorization().deny();
    }

}

package org.acme.http.security;

import jakarta.enterprise.event.Observes;

import io.quarkus.vertx.http.security.HttpSecurity;

public class HttpSecurityConfiguration {

    void configure(@Observes HttpSecurity httpSecurity) {
        httpSecurity
                .get("/public/*").permit()
                .path("/roles-secured/*", "/other/*", "/api/*").roles("admin", "user")
                .path("/forbidden").authorization().deny();
    }

}

Copy to Clipboard

Toggle word wrap

さらに、io.quarkus.vertx.http.security.HttpSecurity CDI イベントを使用して、特定の認証メカニズムとポリシーを設定することもできます。

package org.acme.http.security;

import io.quarkus.vertx.http.security.HttpSecurity;
import jakarta.enterprise.event.Observes;
import org.eclipse.microprofile.config.inject.ConfigProperty;

public class HttpSecurityConfiguration {

    void configure(@Observes HttpSecurity httpSecurity, CustomHttpSecurityPolicy customHttpSecurityPolicy,
                        @ConfigProperty(name = "secured-path") String securedPath) {

        httpSecurity.path("/other/*").basic().policy(customHttpSecurityPolicy); 

        httpSecurity.path("/roles-secured/*").bearer().authorization()
                .policy(identity -> identity.hasRole("user") || "root".equals(identity.getPrincipal().getName()));  

        httpSecurity.path("/other/administration").authorizationCodeFlow()
                .authorization().policy((identity, routingContext) -> {
                    if (!identity.isAnonymous()) {
                        String customAuthorization = routingContext.request().getHeader("Custom Authorization");
                        return yourCustomAuthorizationCheck(customAuthorization);
                    }
                    return false;
                });     

        httpSecurity.path(securedPath).form();  

        httpSecurity.path("/user-info").bearer().authorization().permissions("openid", "email", "profile"); 
    }
}

package org.acme.http.security;

import io.quarkus.vertx.http.security.HttpSecurity;
import jakarta.enterprise.event.Observes;
import org.eclipse.microprofile.config.inject.ConfigProperty;

public class HttpSecurityConfiguration {

    void configure(@Observes HttpSecurity httpSecurity, CustomHttpSecurityPolicy customHttpSecurityPolicy,
                        @ConfigProperty(name = "secured-path") String securedPath) {

        httpSecurity.path("/other/*").basic().policy(customHttpSecurityPolicy);



        httpSecurity.path("/roles-secured/*").bearer().authorization()
                .policy(identity -> identity.hasRole("user") || "root".equals(identity.getPrincipal().getName()));



        httpSecurity.path("/other/administration").authorizationCodeFlow()
                .authorization().policy((identity, routingContext) -> {
                    if (!identity.isAnonymous()) {
                        String customAuthorization = routingContext.request().getHeader("Custom Authorization");
                        return yourCustomAuthorizationCheck(customAuthorization);
                    }
                    return false;
                });



        httpSecurity.path(securedPath).form();



        httpSecurity.path("/user-info").bearer().authorization().permissions("openid", "email", "profile");

}
}

Copy to Clipboard

Toggle word wrap

1: Basic 認証を使用し、カスタム io.quarkus.vertx.http.runtime.security.HttpSecurityPolicy を使用してリクエストを承認します。
2: Bearer トークン認証を使用し、独自のポリシーで SecurityIdentity を承認します。
3: 認可コードフローメカニズムを使用し、受信リクエストヘッダーに基づいて独自のポリシーを記述します。
4: Quarkus が HttpSecurity CDI イベントを発生させると、ランタイム設定が準備されます。
5: /user-info パスへのすべてのリクエストに、文字列の権限 openid、email、profile が必要です。エンドポイントに配置された @PermissionsAllowed(value = { "openid", "email", "profile" }, inclusive = true) アノテーションインスタンスでも、同じ認可が必要になる場合があります。

第1章 Web エンドポイントの認可

1.1. 設定を使用した認可
リンクのコピー

1.1.1. カスタムの HttpSecurityPolicy
リンクのコピー

1.1.2. HttpSecurityPolicy への @RequestScoped Bean の注入
リンクのコピー

1.1.3. パスとメソッドのマッチング
リンクのコピー

1.1.4. パスにはマッチするがメソッドにはマッチしない場合
リンクのコピー

1.1.5. 複数のパスのマッチング: 最長パスが優先される
リンクのコピー

1.1.6. 複数のサブパスのマッチング: * ワイルドカードへの最長パスが優先される
リンクのコピー

1.1.7. 複数のパスのマッチング: 最も詳細なメソッドが優先される
リンクのコピー

1.1.8. 複数のパスとメソッドのマッチング: どちらも優先される
リンクのコピー

1.1.9. アクセスを拒否するための設定プロパティー
リンクのコピー

1.1.10. 権限の無効化
リンクのコピー

1.1.11. 権限パスと HTTP ルートパス
リンクのコピー

1.1.12. SecurityIdentity ロールのマッピング
リンクのコピー

1.1.13. 共有権限チェック
リンクのコピー

1.1.14. パス固有の認可をプログラムでセットアップする
リンクのコピー

1.1.14.1. プログラムによるセットアップの参照
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第1章 Web エンドポイントの認可

1.1. 設定を使用した認可リンクのコピーリンクがクリップボードにコピーされました!

1.1.1. カスタムの HttpSecurityPolicyリンクのコピーリンクがクリップボードにコピーされました!

1.1.2. HttpSecurityPolicy への @RequestScoped Bean の注入リンクのコピーリンクがクリップボードにコピーされました!

1.1.3. パスとメソッドのマッチングリンクのコピーリンクがクリップボードにコピーされました!

1.1.4. パスにはマッチするがメソッドにはマッチしない場合リンクのコピーリンクがクリップボードにコピーされました!

1.1.5. 複数のパスのマッチング: 最長パスが優先されるリンクのコピーリンクがクリップボードにコピーされました!

1.1.6. 複数のサブパスのマッチング: * ワイルドカードへの最長パスが優先されるリンクのコピーリンクがクリップボードにコピーされました!

1.1.7. 複数のパスのマッチング: 最も詳細なメソッドが優先されるリンクのコピーリンクがクリップボードにコピーされました!

1.1.8. 複数のパスとメソッドのマッチング: どちらも優先されるリンクのコピーリンクがクリップボードにコピーされました!

1.1.9. アクセスを拒否するための設定プロパティーリンクのコピーリンクがクリップボードにコピーされました!

1.1.10. 権限の無効化リンクのコピーリンクがクリップボードにコピーされました!

1.1.11. 権限パスと HTTP ルートパスリンクのコピーリンクがクリップボードにコピーされました!

1.1.12. SecurityIdentity ロールのマッピングリンクのコピーリンクがクリップボードにコピーされました!

1.1.13. 共有権限チェックリンクのコピーリンクがクリップボードにコピーされました!

1.1.14. パス固有の認可をプログラムでセットアップするリンクのコピーリンクがクリップボードにコピーされました!

1.1.14.1. プログラムによるセットアップの参照リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

1.1. 設定を使用した認可
リンクのコピー

1.1.1. カスタムの HttpSecurityPolicy
リンクのコピー

1.1.2. HttpSecurityPolicy への @RequestScoped Bean の注入
リンクのコピー

1.1.3. パスとメソッドのマッチング
リンクのコピー

1.1.4. パスにはマッチするがメソッドにはマッチしない場合
リンクのコピー

1.1.5. 複数のパスのマッチング: 最長パスが優先される
リンクのコピー

1.1.6. 複数のサブパスのマッチング: * ワイルドカードへの最長パスが優先される
リンクのコピー

1.1.7. 複数のパスのマッチング: 最も詳細なメソッドが優先される
リンクのコピー

1.1.8. 複数のパスとメソッドのマッチング: どちらも優先される
リンクのコピー

1.1.9. アクセスを拒否するための設定プロパティー
リンクのコピー

1.1.10. 権限の無効化
リンクのコピー

1.1.11. 権限パスと HTTP ルートパス
リンクのコピー

1.1.12. SecurityIdentity ロールのマッピング
リンクのコピー

1.1.13. 共有権限チェック
リンクのコピー

1.1.14. パス固有の認可をプログラムでセットアップする
リンクのコピー

1.1.14.1. プログラムによるセットアップの参照
リンクのコピー