Last week, I wrote about putting the right feature at the right place. 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.

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:

1. Authenticate an HTTP request as coming from a known user
2. 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@EnableWebSecurityclass 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}

1. Use the Kotlin Beans DSL - because I can
2. Only allow access to the endpoint to authenticated users
3. Add a filter in the filter chain to replace regular authentication
4. 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(}

1. Get the authentication token
2. Get the path
3. Wrap it under a dedicated structure
4. 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  }}

1. Get the authorization token passed from the filter
2. Try to find the account that has this token. For simplicity's sake, the token is stored in plain text without hashing
3. If the account tries to access its data, allow it
4. If not, we must load the hierarchy from another repo.
5. If the account attempts to access data from an employee they manage, allow it.
6. 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

bob asks for his own salary, and it works.

curl -H 'Authorization: bob' localhost:9080/finance/salary/alice

bob asks for the salary of one of his subordinates, and it works as well.

curl -H 'Authorization: bob' localhost:9080/finance/salary/alice

alice asks for her manager's salary, which is not allowed.

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 Rego, and I must admit it's not fun. Anyway, here's our above policy written in "clear" text:

package ch.frankel.blog.securebootemployees := data.hierarchy                                 #1default 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}

1. Get the employee hierarchy somehow (see below)
2. If the account requests their salary, allow access
3. If the account requests the salary of a subordinate, allow access

I used two variables in the above snippet: input and data. input is the payload that the application sends to OPA. It should be in JSON format and has the following form:

{    "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 many options to achieve it. Here, I pretend to extract data from the Employee database, bundle it together with the policy file, serve the bundle via HTTP, and configure OPA to load it at regular intervals.

Note that you shouldn't use Apache 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    }}

1. Keep the initial authentication logic
2. Replace the authorization with a call to the OPA service
3. Serialize the data to conform to the JSON input that the OPA policy expects
4. Deserialize the result
5. If something is wrong, the default should be to disallow
6. 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 authentication logic The obvious candidate is the API Gateway since we set Apache 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.

Apache has multiple authentication plugins available. Because I used a bearer token, I'll use key-auth. Let's create our users, or in Apache terms, consumers:

consumers:  - username: alice    plugins:      key-auth:        key:  alice<span class="token-line" style="color: rgb