<commit_before>////
This guide is maintained in the main Quarkus repository
and pull requests should be submitted there:
https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
////
= Quarkus - Authorization of Web Endpoints

include::./attributes.adoc[]

Quarkus has an integrated pluggable web security layer. If security is enabled all HTTP requests will have a permission
check performed to make sure they are allowed to continue.

NOTE: Configuration authorization checks are executed before any annotation-based authorization check is done, so both
checks have to pass for a request to be allowed.

== Authorization using Configuration

The default implementation allows you to define permissions using config in `application.properties`. An example
config is shown below:

[source,properties]
----
quarkus.http.auth.policy.role-policy1.roles-allowed=user,admin                      <1>

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

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

quarkus.http.auth.permission.deny1.paths=/forbidden                                 <4>
quarkus.http.auth.permission.deny1.policy=deny
----
<1> This defines a role based policy that allows users with the `user` and `admin` roles. This is referenced by later rules.
<2> This is a permission set that references the previously defined policy. `roles1` is an arbitrary name, you can call the permission sets whatever you want.
<3> This permission references the default `permit` built-in policy to allow `GET` methods to `/public`. This is actually a no-op in this example, as this request would have been allowed anyway.
<4> This permission references the built-in `deny` policy for `/forbidden`. This is an exact path match as it does not end with `*`.

Permissions are defined in config using permission sets. These are arbitrarily named permission grouping. Each permission
set must specify a policy that is used to control access. There are three built-in policies: `deny`, `permit` and `authenticated`,
which respectively permits all, denies all and only allows authenticated users.

It is also possible to define role based policies, as shown in the example. These policies will only allow users with the
specified roles to access the resources.

=== Matching on paths, methods

Permission sets can also specify paths and methods as a comma separated list. If a path ends with `*` then it is considered
to be a wildcard match and will match all sub paths, otherwise it is an exact match and will only match that specific path:

[source,properties]
----
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
----

=== Matching path but not method

If a request would match one or more permission sets based on the path, but does not match any due to method requirements
then the request is rejected.

TIP: Given the above permission set, `GET /public/foo` would match both the path and method and thus be allowed,
whereas `POST /public/foo` would match the path but not the method and would thus be rejected.

=== Matching multiple paths: longest path wins

Matching is always done on a longest path wins basis, less specific permission sets are not considered if a more specific one
has been matched:

[source,properties]
----
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
----

TIP: Given the above permission set, `GET /public/forbidden-folder/foo` would match both permission sets' paths,
but because it matches the `deny1` permission set's path on a longer match, `deny1` will be chosen and the request will
be rejected.

[NOTE] 
====
Subpath permissions always win against the root path permissions as explained above in the `deny1` versus `permit1` permission example.
Here is another example showing a subpath permission allowing a public resource access with the root path permission requiring the authorization:

[source,properties]
----
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
----
====

=== Matching multiple paths: most specific method wins

If a path is registered with multiple permission sets then any permission sets that specify a HTTP method will take
precedence and permissions sets without a method will not be considered (assuming of course the method matches). In this
instance, the permission sets without methods will only come into effect if the request method does not match any of the
sets with method permissions.

[source,properties]
----
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
----

TIP: Given the above permission set, `GET /public/foo` would match both permission sets' paths,
but because it matches the `permit1` permission set's explicit method, `permit1` will be chosen and the request will
be accepted. `PUT /public/foo` on the other hand, will not match the method permissions of `permit1` and so
`deny1` will be activated and reject the request.

=== Matching multiple paths and methods: both win

If multiple permission sets specify the same path and method (or multiple have no method) then both permissions have to
allow access for the request to proceed. Note that for this to happen both have to either have specified the method, or
have no method, method specific matches take precedence as stated above:

[source,properties]
----
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
----

TIP: Given the above permission set, `GET /api/foo` would match both permission sets' paths,
so would require both the `user` and `admin` roles.

=== Configuration Properties to Deny access

There are two configuration settings that alter the RBAC Deny behavior:

- `quarkus.security.jaxrs.deny-unannotated-endpoints=true|false` - if set to true, the access will be denied for all JAX-RS endpoints by default.
That is if the security annotations do not define the access control. Defaults to `false`.
- `quarkus.security.deny-unannotated-members=true|false` - if set to true, the access will be denied to all CDI methods
and JAX-RS endpoints that do not have security annotations but are defined in classes that contain methods with
security annotations. Defaults to `false`.

[#standard-security-annotations]
== Authorization using Annotations

Quarkus comes with built-in security to allow for Role-Based Access Control (link:https://en.wikipedia.org/wiki/Role-based_access_control[RBAC])
based on the common security annotations `@RolesAllowed`, `@DenyAll`, `@PermitAll` on REST endpoints and CDI beans.
An example of an endpoint that makes use of both JAX-RS and Common Security annotations to describe and secure its endpoints is given in <<subject-example>>. Quarkus also provides
the `io.quarkus.security.Authenticated` annotation that will permit any authenticated user to access the resource<commit_msg>Add a note to Security Authorization doc how to disable the permissions<commit_after>////
This guide is maintained in the main Quarkus repository
and pull requests should be submitted there:
https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
////
= Quarkus - Authorization of Web Endpoints

include::./attributes.adoc[]

Quarkus has an integrated pluggable web security layer. If security is enabled all HTTP requests will have a permission
check performed to make sure they are allowed to continue.

NOTE: Configuration authorization checks are executed before any annotation-based authorization check is done, so both
checks have to pass for a request to be allowed.

== Authorization using Configuration

The default implementation allows you to define permissions using config in `application.properties`. An example
config is shown below:

[source,properties]
----
quarkus.http.auth.policy.role-policy1.roles-allowed=user,admin                      <1>

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

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

quarkus.http.auth.permission.deny1.paths=/forbidden                                 <4>
quarkus.http.auth.permission.deny1.policy=deny
----
<1> This defines a role based policy that allows users with the `user` and `admin` roles. This is referenced by later rules.
<2> This is a permission set that references the previously defined policy. `roles1` is an arbitrary name, you can call the permission sets whatever you want.
<3> This permission references the default `permit` built-in policy to allow `GET` methods to `/public`. This is actually a no-op in this example, as this request would have been allowed anyway.
<4> This permission references the built-in `deny` policy for `/forbidden`. This is an exact path match as it does not end with `*`.

Permissions are defined in config using permission sets. These are arbitrarily named permission grouping. Each permission
set must specify a policy that is used to control access. There are three built-in policies: `deny`, `permit` and `authenticated`,
which respectively permits all, denies all and only allows authenticated users.

It is also possible to define role based policies, as shown in the example. These policies will only allow users with the
specified roles to access the resources.

=== Matching on paths, methods

Permission sets can also specify paths and methods as a comma separated list. If a path ends with `*` then it is considered
to be a wildcard match and will match all sub paths, otherwise it is an exact match and will only match that specific path:

[source,properties]
----
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
----

=== Matching path but not method

If a request would match one or more permission sets based on the path, but does not match any due to method requirements
then the request is rejected.

TIP: Given the above permission set, `GET /public/foo` would match both the path and method and thus be allowed,
whereas `POST /public/foo` would match the path but not the method and would thus be rejected.

=== Matching multiple paths: longest path wins

Matching is always done on a longest path wins basis, less specific permission sets are not considered if a more specific one
has been matched:

[source,properties]
----
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
----

TIP: Given the above permission set, `GET /public/forbidden-folder/foo` would match both permission sets' paths,
but because it matches the `deny1` permission set's path on a longer match, `deny1` will be chosen and the request will
be rejected.

[NOTE] 
====
Subpath permissions always win against the root path permissions as explained above in the `deny1` versus `permit1` permission example.
Here is another example showing a subpath permission allowing a public resource access with the root path permission requiring the authorization:

[source,properties]
----
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
----
====

=== Matching multiple paths: most specific method wins

If a path is registered with multiple permission sets then any permission sets that specify a HTTP method will take
precedence and permissions sets without a method will not be considered (assuming of course the method matches). In this
instance, the permission sets without methods will only come into effect if the request method does not match any of the
sets with method permissions.

[source,properties]
----
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
----

TIP: Given the above permission set, `GET /public/foo` would match both permission sets' paths,
but because it matches the `permit1` permission set's explicit method, `permit1` will be chosen and the request will
be accepted. `PUT /public/foo` on the other hand, will not match the method permissions of `permit1` and so
`deny1` will be activated and reject the request.

=== Matching multiple paths and methods: both win

If multiple permission sets specify the same path and method (or multiple have no method) then both permissions have to
allow access for the request to proceed. Note that for this to happen both have to either have specified the method, or
have no method, method specific matches take precedence as stated above:

[source,properties]
----
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
----

TIP: Given the above permission set, `GET /api/foo` would match both permission sets' paths,
so would require both the `user` and `admin` roles.

=== Configuration Properties to Deny access

There are two configuration settings that alter the RBAC Deny behavior:

- `quarkus.security.jaxrs.deny-unannotated-endpoints=true|false` - if set to true, the access will be denied for all JAX-RS endpoints by default.
That is if the security annotations do not define the access control. Defaults to `false`.
- `quarkus.security.deny-unannotated-members=true|false` - if set to true, the access will be denied to all CDI methods
and JAX-RS endpoints that do not have security annotations but are defined in classes that contain methods with
security annotations. Defaults to `false`.

=== Disabling the permissions 

The permissions can be disabled at build time with a permissions policy specific `enabled` property, for example: 

[source,properties]
----
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
----

and enabled at runtime with a system property or environment variable, for example: `-Dquarkus.http.auth.permission.permit1.enabled=true`.

[#standard-security-annotations]
== Authorization using Annotations

Quarkus comes with built-in security to allow for Role-Based Access Control (link:https://en.wikipedia.org/wiki/Role-based_access_control[RBAC])
based on the common security annotations `@RolesAllowed`, `@DenyAll`, `@PermitAll` on REST endpoints and CDI beans.
An example of an endpoint that makes use of both JAX-RS and Common Security annotations to describe and secure its endpoints is given in <<subject-example>>. Quarkus also provides
the `io.quarkus.security.Authenticated` annotation that will permit any authenticated user to access the resource
{'fraction_non_alphanumeric': 0.08368982346207146, 'fraction_numerical': 0.005964933421702717, 'mean_word_length': 4.527139527139527, 'pattern_counts': {'":': 0, '<': 23, '<?xml version=': 0, '>': 23, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7583506', 'n_tokens_mistral': 4599, 'n_tokens_neox': 4426, 'n_words': 1873}