quarkus security for REST API, RBAC implementation in quarkus

Quarkus - Hello world example using Kotlin!

Quarkus provides a number of security annotations that can be used to secure your application. Here are some commonly used security annotations with examples:

@RolesAllowed

The @RolesAllowed annotation is used to specify which security roles are allowed to access a method.

import javax.annotation.security.RolesAllowed;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;

@Path("/secured")
public class SecuredResource {

    @GET
    @Path("/admin")
    @RolesAllowed("admin")
    public Response adminOnly() {
        // This method can only be accessed by users with the "admin" role
        return Response.ok("Hello Admin!").build();
    }

    @GET
    @Path("/user")
    @RolesAllowed({"admin", "user"})
    public Response userOrAdmin() {
        // This method can be accessed by users with either the "admin" or "user" role
        return Response.ok("Hello User or Admin!").build();
    }
}

In the above example, the adminOnly method can only be accessed by users with the "admin" role, while the userOrAdmin method can be accessed by users with either the "admin" or "user" role.

@Authenticated

The @Authenticated annotation is used to specify that a method can only be accessed by authenticated users.

import javax.annotation.security.RolesAllowed;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;
import org.eclipse.microprofile.auth.inject.SecurityContext;

@Path("/secured")
public class SecuredResource {

    @GET
    @Path("/authenticated")
    @Authenticated
    public Response authenticatedOnly(@Context SecurityContext securityContext) {
        // This method can only be accessed by authenticated users
        String username = securityContext.getUserPrincipal().getName();
        return Response.ok("Hello " + username + "!").build();
    }
}

In the above example, the authenticatedOnly method can only be accessed by authenticated users. The SecurityContext parameter can be used to retrieve information about the authenticated user, such as their username.

@PermitAll

The @PermitAll annotation is used to specify that a method can be accessed by all users, even those who are not authenticated.

import javax.annotation.security.PermitAll;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;

@Path("/public")
public class PublicResource {

    @GET
    @Path("/hello")
    @PermitAll
    public Response publicHello() {
        // This method can be accessed by all users, even those who are not authenticated
        return Response.ok("Hello World!").build();
    }
}

In the above example, the publicHello method can be accessed by all users, even those who are not authenticated.

@DenyAll

The @DenyAll annotation is used to specify that a method cannot be accessed by any user, even those who are authenticated.

import javax.annotation.security.DenyAll;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;

@Path("/restricted")
public class RestrictedResource {

    @GET
    @Path("/secret")
    @DenyAll
    public Response secret() {
        // This method cannot be accessed by any user, even those who are authenticated
        return Response.status(Response.Status.FORBIDDEN).build();
    }
}

In the above example, the secret method cannot be accessed by any user, even those who are authenticated.

I hope this helps, you!!

More such articles:

https://medium.com/techwasti

https://www.youtube.com/channel/UCiTaHm1AYqMS4F4L9zyO7qA

https://www.techwasti.com/

\==========================**=========================

If this article adds any value to you then please clap and comment.

Let’s connect on Stackoverflow, LinkedIn, & Twitter.

Quarkus security annotations with example!!

Comments

More from this blog

Adopting an MCP-First API Design for the Agentic Era | Beyond REST.

Article 6: Mastering Kestra's Plugin Ecosystem.

Article 5: Advanced Workflow Patterns in Kestra.

Article 4: Building Your First ETL Pipeline with Kestra.

Article 3: Understanding Kestra's Architecture: Flows, Tasks, and Namespaces

@RolesAllowed

@Authenticated

@PermitAll

@DenyAll

Command Palette

Comments

More from this blog

@RolesAllowed

@Authenticated

@PermitAll

@DenyAll