Last week, I wrote about . I used rate limiting as an example, moving it from a library inside the application to the API Gateway. Today, I'll use another example: authentication and authorization. putting the right feature at the right place Securing a Spring Boot application I'll keep using Spring Boot in the following because I'm familiar with it. The Spring Boot application offers a REST endpoint to check employees' salaries. The specific use case is taken from the Open Policy Agent site (more later): Create a policy that allows users to request their own salary as well as the salary of their direct subordinates. We need a way to: Authenticate an HTTP request as coming from a known user Check whether the user has access to the salary data In any other case, return a . 401 I'll pass an authentication token in the request to keep things simple. I won't rely on a dedicated authentication/authorization backend, such as Keycloak, but it should be a similar approach if you do. To enable Spring Security on the app, we need to add the Spring Boot Security Starter. <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency> We also need to enable Spring Security to work its magic: @SpringBootApplication
@EnableWebSecurity
class SecureBootApplication With those two steps in place, we can start securing the application according to the above requirement: internal fun security() = beans {                                       //1
    bean {
        val http = ref<HttpSecurity>()
        http {
            authorizeRequests {
                authorize("/finance/salary/**", authenticated)          //2
            }
            addFilterBefore<UsernamePasswordAuthenticationFilter>(
                TokenAuthenticationFilter(ref())                        //3
            )
            httpBasic { disable() }
            csrf { disable() }
            logout { disable() }
            sessionManagement {
                sessionCreationPolicy = SessionCreationPolicy.STATELESS
            }
        }
        http.build()
    }
    bean { TokenAuthenticationManager(ref(), ref()) }                   //4
} Use the Kotlin Beans DSL - because I can Only allow access to the endpoint to authenticated users Add a filter in the filter chain to replace regular authentication Add a custom authentication manager Requests look like the following: curl -H 'Authorization: xyz'  localhost:9080/finance/salary/bob The filter extracts from the request the necessary data used to decide whether to allow the request or not: internal class TokenAuthenticationFilter(authManager: AuthenticationManager) :
    AbstractAuthenticationProcessingFilter("/finance/salary/**", authManager) {

    override fun attemptAuthentication(req: HttpServletRequest, resp: HttpServletResponse): Authentication {
        val header = req.getHeader("Authorization")                   //1
        val path = req.servletPath.split('/')                         //2
        val token = KeyToken(header, path)                            //3
        return authenticationManager.authenticate(token)              //4
    }

    // override fun successfulAuthentication(
} Get the authentication token Get the path Wrap it under a dedicated structure Try to authenticate the token In turn, the manager tries to authenticate the token: internal class TokenAuthenticationManager(
    private val accountRepo: AccountRepository,
    private val employeeRepo: EmployeeRepository
) : AuthenticationManager {
  override fun authenticate(authentication: Authentication): Authentication {
    val token = authentication.credentials as String? ?:                       //1
        throw BadCredentialsException("No token passed")
    val account = accountRepo.findByPassword(token).orElse(null) ?:            //2
        throw BadCredentialsException("Invalid token")
    val path = authentication.details as List<String>
    val accountId = account.id
    val segment = path.last()
    if (segment == accountId) return authentication.withPrincipal(accountId)   //3
    val employee = employeeRepo.findById(segment).orElse(null)                 //4
    val managerUserName = employee?.manager?.userName
    if (managerUserName != null && managerUserName == accountId)               //5
        return authentication.withPrincipal(accountId)                         //5
    throw InsufficientAuthenticationException("Incorrect token")               //6
  }
} Get the authorization token passed from the filter Try to find the account that has this token. For simplicity's sake, the token is stored in plain text without hashing If the account tries to access its data, allow it If not, we must load the hierarchy from another repo. If the account attempts to access data from an employee they manage, allow it. Else, deny it. The whole flow can be summarized as the following: Now, we can try some requests. curl -H 'Authorization: bob' localhost:9080/finance/salary/bob asks for his own salary, and it works. bob curl -H 'Authorization: bob' localhost:9080/finance/salary/alice asks for the salary of one of his subordinates, and it works as well. bob curl -H 'Authorization: bob' localhost:9080/finance/salary/alice asks for her manager's salary, which is not allowed. alice The code above works perfectly but has one big issue: there's no way to audit the logic. One must know Kotlin and how Spring Security works to ensure the implementation is sound. Introducing Open Policy Agent Open Policy Agent, or OPA for short, describes itself as "Policy-based control for cloud native environments". Stop using a different policy language, policy model, and policy API for every product and service you use. Use OPA for a unified toolset and framework for policy across the cloud native stack. Whether for one service or for all your services, use OPA to decouple policy from the service's code so you can release, analyze, and review policies (which security and compliance teams love) without sacrificing availability or performance. -- OPA Website In short, OPA allows writing policies and offers a CLI and a daemon app to evaluate them. You write policies in a specific interpreted language named , and I must admit it's not fun. Anyway, here's our above policy written in "clear" text: Rego package ch.frankel.blog.secureboot

employees := data.hierarchy                                 //1

default allow := false

# Allow users to get their own salaries.
allow {
	input.path == ["finance", "salary", input.user]         //2
}

# Allow managers to get their subordinates' salaries.
allow {
	some username
	input.path = ["finance", "salary", username]            //3
	employees[input.user][_] == username                    //3
} Get the employee hierarchy somehow (see below) If the account requests their salary, allow access If the account requests the salary of a subordinate, allow access I used two variables in the above snippet: and . is the payload that the application sends to OPA. It should be in JSON format and has the following form: input data input {
    "path": [
        "finance",
        "salary",
        "alice"
    ],
    "user": "bob"
} More Open Policy Agent goodness However, OPA can't decide on the input alone, as it doesn't know the employee's hierarchy. One approach would be to load the hierarchy data on the app and send it to OPA. A more robust approach is to let OPA access external data to separate responsibilities cleanly. OPA offers to achieve it. Here, I pretend to extract data from the database, bundle it together with the policy file, serve the bundle via HTTP, and configure OPA to load it at regular intervals. many options Employee Note that you shouldn't use Apache APISIX only to serve static files. But since I'll be using it in the next evolution of my architecture, I want to avoid having a separate HTTP server to simplify the system. Now that we moved the decision logic to OPA, we can replace our code with a request to the OPA service. The new version of the authentication manager is: internal class OpaAuthenticationManager(
    private val accountRepo: AccountRepository,
    private val opaWebClient: WebClient
) : AuthenticationManager {

    override fun authenticate(authentication: Authentication): Authentication {
        val token = authentication.credentials as String? ?:                       //1
            throw BadCredentialsException("No token passed")
        val account = accountRepo.findByPassword(token).orElse(null) ?:             //1
            throw BadCredentialsException("Invalid token")
        val path = authentication.details as List<String>
        val decision = opaWebClient.post()                                         //2
            .accept(MediaType.APPLICATION_JSON)
            .contentType(MediaType.APPLICATION_JSON)
            .bodyValue(OpaInput(DataInput(account.id, path)))                      //3
            .exchangeToMono { it.bodyToMono(DecisionOutput::class.java) }          //4
            .block() ?: DecisionOutput(ResultOutput(false))                        //5
        if (decision.result.allow) return authentication.withPrincipal(account.id) //6
        else throw InsufficientAuthenticationException("OPA disallow")             //6
    }
} Keep the initial logic authentication Replace the authorization with a call to the OPA service Serialize the data to conform to the JSON input that the OPA policy expects Deserialize the result If something is wrong, the default should be to disallow Abide by OPA's result The flow is now the following: At this point, we moved the authorization logic from the code to OPA. Moving authentication to the API Gateway The next and final step is to move the logic The obvious candidate is the API Gateway since we set Apache APISIX in the previous step. In general, we should use the capabilities of the API Gateway as much as possible and fall back to libraries for the rest. authentication Apache APISIX has multiple authentication plugins available. Because I used a bearer token, I'll use . Let's create our users, or in Apache APISIX terms, : key-auth consumers consumers:
  - username: alice
    plugins:
      key-auth:
        key:  alice
  - username: betty
    plugins:
      key-auth:
        key:  betty
  - username: bob
    plugins:
      key-auth:
        key:  bob
  - username: charlie
    plugins:
      key-auth:
        key:  charlie Now, we can protect the Spring Boot upstream: routes:
  - uri: /finance/salary*
    upstream:
      type: roundrobin
      nodes:
        "boot:8080": 1
    plugins:
      key-auth:
        header: Authorization                    #1
      proxy-rewrite:
        headers:
          set:
            X-Account: $consumer_name            #2 Authenticate with and the header key-auth Authorization Sets the consumer id in the HTTP header for the upstream X-Account APISIX guarantees that requests that reach the Spring Boot app are authenticated. The code only needs to call the OPA service and follow the decision. We can entirely remove Spring Security and replace it with a filter: simple bean {
    val repo = ref<EmployeeRepository>()
    router {
        val props = ref<AppProperties>()
        val opaWebClient = WebClient.create(props.opaEndpoint)
        filter { req, next -> validateOpa(opaWebClient, req, next) }
        GET("/finance/salary/{user_name}") {
          // ...
        }
    }
}

internal fun validateOpa(
    opaWebClient: WebClient,
    req: ServerRequest,
    next: (ServerRequest) -> ServerResponse
): ServerResponse {
    val httpReq = req.servletRequest()
    val account = httpReq.getHeader("X-Account")                           //1
    val path = httpReq.servletPath.split('/').filter { it.isNotBlank() }
    val decision = opaWebClient.post()                                     //2
        .accept(MediaType.APPLICATION_JSON)
        .contentType(MediaType.APPLICATION_JSON)
        .bodyValue(OpaInput(DataInput(account, path)))
        .exchangeToMono { it.bodyToMono(DecisionOutput::class.java) }
        .block() ?: DecisionOutput(ResultOutput(false))
    return if (decision.result.allow) next(req)
    else ServerResponse.status(HttpStatus.UNAUTHORIZED).build()
} Get the account name from the API Gateway Nothing changes afterward The final flow is the following: Conclusion Everything looks like a nail when all you've got is a hammer. Developers' mighty hammer of choice is code. I've written tons of code to solve problems, and later on, I've used even more libraries to solve even more problems. As you evolve from developer to architect, you increase the number of tools you have. In this regard, code is only one tool among many. Your organization has many infrastructure tools you can leverage to develop solutions at minimal costs. In this post, I've shown how you can leverage OPA and Apache APISIX to move your authentication and authorization logic from the code to the infrastructure. The former allows you to audit your security policies, the latter coherence among all your upstream across all tech stacks. The complete source code for this post can be found on . GitHub To go further: Spring Security Open Policy Agent OPA Bundles Rego playground Spring Security Authorization with OPA Originally published at on February 26th, 2023 A Java Geek

How to Make Your Security Policy Auditable

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

10 Lessons from 10 Years of AWS (part 1)

10 Lessons from 10 Years of AWS (part 2)

111 Stories To Learn About Architecture

13 Expert Tips to Improve Your Web Application Performance Today

4 Skills You Need to Become a Distinguished Developer

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

10 Lessons from 10 Years of AWS (part 1)

10 Lessons from 10 Years of AWS (part 2)

111 Stories To Learn About Architecture

13 Expert Tips to Improve Your Web Application Performance Today

4 Skills You Need to Become a Distinguished Developer

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps