Authorize web endpoints
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.
This means you cannot use @PermitAll
to open a path if the path is blocked by the quarkus.http.auth.
configuration.
If you are using JAX-RS, consider using |
Authorization is based on user roles that the security provider provides.
To customize these roles, a SecurityIdentityAugmentor
can be created, see
Security Identity Customization.
Authorization using configuration
Permissions are defined in the Quarkus configuration using permission sets, with each permission set specifying a policy for access control.
Built-in policy |
Description |
|
This policy denies all users. |
|
This policy permits all users. |
|
This policy permits only authenticated users. |
You can define role-based policies that allow users with specified roles to access the resources.
quarkus.http.auth.policy.role-policy1.roles-allowed=user,admin (1)
1 | This defines a role-based policy that allows users with the user and admin roles.
Such a custom policy can be referenced by permission sets just like the built-in ones, as shown in the example below. |
Permission sets are defined in application.properties
as follows:
quarkus.http.auth.permission.permit1.paths=/public/* (1)
quarkus.http.auth.permission.permit1.policy=permit
quarkus.http.auth.permission.permit1.methods=GET
quarkus.http.auth.permission.deny1.paths=/forbidden (2)
quarkus.http.auth.permission.deny1.policy=deny
quarkus.http.auth.permission.roles1.paths=/roles-secured/*,/other/*,/api/* (3)
quarkus.http.auth.permission.roles1.policy=role-policy1
1 | This permission references the default permit built-in policy to allow GET methods to /public .
In this case, the demonstrated setting would not affect this example because this request is allowed anyway. |
2 | This permission references the built-in deny policy for /forbidden .
This is an exact path match as it does not end with * . |
3 | This is a permission set that references the previously defined policy.
roles1 is an example name; you can call the permission sets whatever you want. |
Matching on paths and methods
Permission sets can also specify paths and methods as a comma-separated list.
If a path ends with the *
wildcard, the query it generates matches all sub-paths.
Otherwise, it queries for an exact match and will only match that specific path:
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 a path but not a method
The request is rejected if a request matches one or more permission sets based on the path but does not match any due to method requirements.
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 therefore be rejected.
|
Matching multiple paths: longest path wins
Matching is always done on the "longest path wins" basis. Less specific permission sets are not considered if a more specific one has been matched:
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
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.
|
Subpath permissions always win against the root path permissions, as explained above in the
|
Matching multiple paths: most specific method wins
When a path is registered with multiple permission sets, the permission sets that explicitly specify an HTTP method that matches the request will take precedence. In this instance, the permission sets without methods will only come into effect if the request method does not match permission sets with the method specification.
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
Given the above permission set,
|
Matching multiple paths and methods: both win
Sometimes, the previously described rules allow multiple permission sets to win at the same time. In that case, for the request to proceed, all the permissions must allow access. Note that for this to happen, both have to either have specified the method or have no method. Method-specific matches take precedence.
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
Given the above permission set, GET /api/foo would match both permission sets' paths, requiring both the user and admin roles.
|
Configuration properties to deny access
The following configuration settings alter the role-based access control (RBAC) denying behavior:
quarkus.security.jaxrs.deny-unannotated-endpoints=true|false
-
If set to true, access is denied for all JAX-RS endpoints by default. If a JAX-RS endpoint does not have any security annotations, it defaults to the
@DenyAll
behavior. This is useful to ensure you cannot accidentally expose an endpoint that is supposed to be secured. Defaults tofalse
. quarkus.security.jaxrs.default-roles-allowed=role1,role2
-
Defines the default role requirements for unannotated endpoints. The
**
role is a special role that means any authenticated user. This cannot be combined withdeny-unannotated-endpoints
, asdeny
takes the effect instead. 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 permissions
Permissions can be disabled at build time with an enabled
property for each declared permission, such as:
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
Permissions can be reenabled at runtime with a system property or environment variable, such as:
-Dquarkus.http.auth.permission.permit1.enabled=true
.
Permission paths and HTTP root path
The quarkus.http.root-path
configuration property is used to change the http endpoint context path.
By default, quarkus.http.root-path
is prepended automatically to configured permission paths then do not use a forward slash, for example:
quarkus.http.auth.permission.permit1.paths=public/*,css/*,js/*,robots.txt
This configuration is equivalent to the following:
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
A leading slash will change how the configured permission path is interpreted.
The configured URL will be used as-is, and paths will not be adjusted if the value of quarkus.http.root-path
is changed.
For example:
quarkus.http.auth.permission.permit1.paths=/public/*,css/*,js/*,robots.txt
This configuration will only impact resources served from the fixed/static URL /public
, which may not match your application resources if quarkus.http.root-path
has been set to something other than /
.
See Path Resolution in Quarkus for more information.
Authorization using annotations
Quarkus comes with built-in security to allow for Role-Based Access Control (RBAC)
based on the common security annotations @RolesAllowed
, @DenyAll
, @PermitAll
on REST endpoints and CDI beans.
Annotation type |
Description |
@DenyAll |
Specifies that no security roles are allowed to invoke the specified methods. |
@PermitAll |
Specifies that all security roles are allowed to invoke the specified methods.
|
@RolesAllowed |
Specifies the list of security roles permitted to access methods in an application. As an equivalent to |
SubjectExposingResource Example featured in this chapter demonstrates an endpoint that uses both JAX-RS and Common Security annotations to describe and secure its endpoints.
import java.security.Principal;
import javax.annotation.security.DenyAll;
import javax.annotation.security.PermitAll;
import javax.annotation.security.RolesAllowed;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.SecurityContext;
@Path("subject")
public class SubjectExposingResource {
@GET
@Path("secured")
@RolesAllowed("Tester") (1)
public String getSubjectSecured(@Context SecurityContext sec) {
Principal user = sec.getUserPrincipal(); (2)
String name = user != null ? user.getName() : "anonymous";
return name;
}
@GET
@Path("unsecured")
@PermitAll (3)
public String getSubjectUnsecured(@Context SecurityContext sec) {
Principal user = sec.getUserPrincipal(); (4)
String name = user != null ? user.getName() : "anonymous";
return name;
}
@GET
@Path("denied")
@DenyAll (5)
public String getSubjectDenied(@Context SecurityContext sec) {
Principal user = sec.getUserPrincipal();
String name = user != null ? user.getName() : "anonymous";
return name;
}
}
1 | The /subject/secured endpoint requires an authenticated user with the granted "Tester" role through the use of the @RolesAllowed("Tester") annotation. |
2 | The endpoint obtains the user principal from the JAX-RS SecurityContext . This will be non-null for a secured endpoint. |
3 | The /subject/unsecured endpoint allows for unauthenticated access by specifying the @PermitAll annotation. |
4 | The call to obtain the user principal returns null if the caller is unauthenticated and non-null if the caller is authenticated. |
5 | The /subject/denied endpoint declares the @DenyAll annotation, thus disallowing all direct access to it as a REST method, regardless of the user calling it. The method is still invokable internally by other methods in this class. |
Please refer to the Proactive Authentication section of the Built-In Authentication Support guide if you plan to use standard security annotations on the IO thread. |
The @RolesAllowed
annotation value supports Property Expressions including default values and nested Property Expressions.
Configuration properties used with the annotation are resolved at runtime.
Annotation |
Value explanation |
|
The endpoint will allow users with the role denoted by the value of the |
|
An example showing that the value can contain multiple variables. |
|
A default value demonstration.
The required role will be denoted by the value of the |
@RolesAllowed
annotationadmin=Administrator
tester.group=Software
tester.role=Tester
%prod.secured=User
%dev.secured=**
import java.security.Principal;
import javax.annotation.security.DenyAll;
import javax.annotation.security.PermitAll;
import javax.annotation.security.RolesAllowed;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.SecurityContext;
@Path("subject")
public class SubjectExposingResource {
@GET
@Path("admin")
@RolesAllowed("${admin}") (1)
public String getSubjectSecuredAdmin(@Context SecurityContext sec) {
Principal user = sec.getUserPrincipal();
String name = user != null ? user.getName() : "anonymous";
return name;
}
@GET
@Path("software-tester")
@RolesAllowed("${tester.group}-${tester.role}") (2)
public String getSubjectSoftwareTester(@Context SecurityContext sec) {
Principal user = sec.getUserPrincipal();
String name = user != null ? user.getName() : "anonymous";
return name;
}
@GET
@Path("user")
@RolesAllowed("${customer:User}") (3)
public String getSubjectUser(@Context SecurityContext sec) {
Principal user = sec.getUserPrincipal();
String name = user != null ? user.getName() : "anonymous";
return name;
}
@GET
@Path("secured")
@RolesAllowed("${secured}") (4)
public String getSubjectSecured(@Context SecurityContext sec) {
Principal user = sec.getUserPrincipal();
String name = user != null ? user.getName() : "anonymous";
return name;
}
}
1 | The @RolesAllowed annotation value is set to the value of Administrator . |
2 | This /subject/software-tester endpoint requires an authenticated user that has been granted the role "Software-Tester".
It is possible to use multiple expressions in the role definition. |
3 | This /subject/user endpoint requires an authenticated user that has been granted the role "User" through the use of the @RolesAllowed("${customer:User}") annotation, as we did not set the configuration property customer . |
4 | This /subject/secured endpoint requires an authenticated user that has been granted the role User in production but allows any authenticated user in development mode. |