Overview of API Access Control and implementing API key access control with BIG-IP APM

Rapid Growth of APIs

APIs are getting more and more important in today’s modern application environment. Microservices communicate with each other through APIs and most S/Ws and H/Ws are also managed by their own API calls. While the adoption of API usage is still growing, there is also raising concern about security from the user side. According to recent research by Gartner, more than 50% of responders answered that ‘API Security’ is their top concern when they adopt API-driven application environments.

There have been many breaches that have happened in the last 3 years because of the vulnerability or the misconfiguration of APIs in applications. For example, there was a breach that happened in a finance company in the US. The threat actors leveraged a stolen credential to access corporate storage thru APIs and stole millions of highly sensitive records. This kind of security breach is not related to ‘zero-day’ vulnerability at all. What we can learn from this breach is that API security is not just tied to ‘preventing vulnerabilities’. A good API security solution should be able to provide more than that. In this case, well-designed ‘API Access Control’ is required.

 

API Access Control

‘API Access Control’ represents a combination of ‘API authentication’ and ‘API authorization’. When an enterprise designs its API services, they normally expect to have only authenticated users access the API endpoints with the right privileges. To achieve this, organizations need to have a system to authenticate the user and authorize the API requests from their users. All these processes can be categorized under ‘API Access Control.' Below, I will explain some of the commonly used ‘API Access Control’ methods and how we can implement them using F5 solutions. In this first article, I will explain the ‘API Key’-based access control method and the configuration steps for this method in the BIG-IP APM and NGINX+ API G/W.

API Key Access Control

An ‘Access Control’ for API endpoints essentially includes two major functions: authentication and authorization. One of the simple ways to implement API access control is an ‘API Key Access Control’ approach. Of course, there is a more widely-used method for this purpose – OAuth. OAuth is an industry-standard protocol to implement API access control, and it includes built-in security enhancements as well. However, OAuth doesn’t fit all API implementations. For example, if organizations run small-sized and simple API services, they probably don’t want to implement complex and dedicated OAuth infrastructure. This could be the same for internal API communications as well. In those cases, organizations may be looking for a more simple approach to implement access control, and the API key approach could be the solution. In this approach, an API key is used for authorization and (normally) HTTP basic authentication is used for authenticating clients.

1) HTTP Basic authentication

There are many ways to authenticate a user before allowing them to access backend APIs. The most simple way to support the authentication is the ‘HTTP Basic authentication' method. This method is especially useful for users who are using a browser or equivalent S/W to access APIs. If an organization decides to implement its own UI to process the authentication, they'll need their own UI and interface to work with IdP(ID Provider). HTTP Basic authentication, on the other hand, is supported by most modern browsers, and it also works well with a command-line tool.

2) API Key authorization

An API key is a shared secret value between the API client and API endpoints. An API key is easy and simple to implement, thus it is recommended to use in small and medium-sized API environments or non-critical API services. An API key doesn’t require any specific format, and it includes a combination of long randomized characters with a long-term lifetime. Using the ‘OpenSSL’ is probably the simplest way to generate it. An example is below.

This is a quick and easy way to generate a randomized API key. Once you generate an API key like above, you need to configure the key manually to your API G/W or API endpoints. Then API G/W or API endpoints will check all API requests to see whether they include a valid API key in their request header.

While the ‘OpenSSL’ method is simple to generate the API keys, it has some limitations as well. First, the key doesn't have an expiration time. That means the stolen key can be used by attackers if the key is compromised. Because it doesn’t have an expiration time, there is no mechanism to prevent theft . This has potential to be a critical security flaw in an organization’s API access. If the issued key is stolen by attackers, they can access the organization’s critical data thru API calls. So, setting an expiration date is essential when you use the API key approach as your API access control. Second, the API owners or SecOps team don’t have visibility on which keys are currently active in their environment. If you want to maintain the active key list in the ‘OpenSSL’ method, you have to create a separate file or database to maintain the key list, but this introduces operational complexity. Moreover, the organization needs to have additional security solutions to protect this file or database. Lastly, API owners or the SecOps team should manage API key configuration manually in API endpoints or API G/W devices. This manual process requires operational overhead and may cause potential misconfiguration as well.

F5 BIG-IP APM can solve these challenges and support API owners to implement API key-based access control more securely. F5 BIG-IP APM generates time-limited randomized API keys and automatically enforces the policy because BIG-IP APM itself can work as another API G/W in front of the organization’s existing API G/W.

 

Implementing API Key access control using BIG-IP APM

1) I configured four virtual servers in the BIG-IP APM and below is the role of each Virtual Server.

a. Auth-VS

This virtual server authenticates a user and forwards an external request to the next virtual server, in this case, ‘API-Key-VS’ virtual server.

b. API-KEY-VS

When the client accesses this virtual server, it generates a randomized ‘API key’ with a limited lifetime setting. In this example, the lifetime of ‘API Key’ is set to 1 week. It returns the generated API key in the simple HTML web page.

c. TEST-VS

This virtual server runs as a reverse proxy for the backend-protected API endpoints. Any external clients have to point to this virtual server address to access the backend APIs.

d. table-exporting-vs

If API owners or the SecOps team need to check the currently active API keys, they simply can access this virtual server. Then the virtual server returns the currently active generated API keys. The operation team can export the table to CSV format as well.

2) Configuring the ‘Auth-VS’

a. First we need to create a new irule to forward authenticated API requests to the next VS – ‘API-KEY-VS’. (irule name is ‘irule_auth_vs’.)

when HTTP_REQUEST {
    virtual API-KEY-VS
}

b. We need to connect IdP(Id Provider) system to the BIG-IP APM and we will use ‘Local DB’ in this example. However, you can connect Active Directory or other external IdP in the production environment.

BIG-IP APM UI >> Access >> Authentication >> Local User DB >> Instances >> Create New Instance

BIG-IP APM UI >> Access >> Authentication >> Local User DB >> Users >> Create New User

 

c. Since the main purpose of this virtual server is to authenticate a user, it requires having an access profile.

BIG-IP APM UI >> Access >> Profiles / Policies >> Access Profiles (Per-Session Policies) >> Create

d. Once you create the access profile, click the ‘Edit’ under the ‘Per-Session Policy’ column.

e.  Create a virtual server to assign the access profile and irule.

 

 

2) Configuring the ‘API-KEY-VS’

a. We need two irules to generate randomized API keys and show them on a simple HTML page. The first irule name is a ‘library’. (The name should not be changed.)

# The original irule was created by 'Jason Rahm'. 
# https://community.f5.com/t5/crowdsrc/random-string-generators/ta-p/286104
# iRule proc Source - Define the proc named html_encode in a separate iRule named library:

proc randomNumberLetterGenerator {length {chars "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"}} {
  set range [expr {[string length $chars]-1}]
  set txt ""
  for {set i 0} {$i < $length} {incr i} {
    set pos [expr {int(rand()*$range)}]
    append txt [string range $chars $pos $pos]
}
return $txt
}

b. Second irule name is ‘api_key_vs’.

# The original irule was created by 'Jason Rahm'. 
# https://community.f5.com/t5/crowdsrc/random-string-generators/ta-p/286104

when CLIENT_ACCEPTED {
  set key [call library::randomNumberLetterGenerator 20]
  set value "[IP::client_addr]:[TCP::client_port]"
  set tbl "api_key_table"
  set now [clock seconds]
  set nowformatted [clock format $now]
  set expire [expr {$now+300}]
  set expireformatted [clock format $expire]
  
  table set -subtable $tbl $key $value indefinite 300
  
  #log local0. "Random Strings: $key / $value / $tbl / $nowformatted / $expireformatted"
}

when HTTP_REQUEST {
  set response "<html>
         <head>
            <title> Time-limited API Key Generating </title>
         </head>
         <body>
            This is your one-time API access Key: $key <br>
            The current time is $nowformatted <br>
            The key will be expired at $expireformatted
         </body>
      </html>"
      
  HTTP::respond 200 content $response
#  log local0. "$response"
}

c.  Create a virtual server to assign irules.

3) Configuring the ‘table-exporting-vs’

a. The purpose of this virtual server is to show the currently active ‘API keys’ in the BIG-IP table. We created the table name – ‘api_key_table’ in the previous irule. This table manages active API keys and the below irule simply shows the current table status on a simple HTML page. You have to access this table using '/subtables' URI. The irule was originally developed by 'Joe Pruitt(https://community.f5.com/t5/crowdsrc/session-table-control/ta-p/282248)'. You can copy the irule from this link. 

b.  Create a virtual server to assign irules.

 

4) Configuring the ‘TEST-VS’

This virtual server is a normal virtual server to provide access to the backend API endpoints. You need to create your own server pool first before proceeding with the below step.

Verifying the result

We use the most commonly used API client S/W – Postman – to check that API-key access control of BIG-IP APM works correctly. 

a. Our first request doesn’t include a valid API key in the header, thus BIG-IP APM blocks the request and returns ‘401 Unauthorized error’.

b.  We add the incorrect API key in the header of the second request. The request failed to pass the BIG-IP APM access control policy and BIG-IP APM returns ‘401 Unauthorized error’ again.

 

c.  The client has access to the Auth-VS to obtain a valid API access key. BIG-IP APM authenticates the user first and passes the request to the next virtual server only if the user is authenticated successfully.

d.  If the user is authenticated successfully, BIG-IP APM generates a one-time API access key with 20digit randomized strings. The key has 5minitues of its lifetime but it is recommended to set up a longer key lifetime in a production network, for example, weeks or months.

e.  In the Postman configuration UI, you need to set up an ‘Authorization Type’ as an ‘API Key’ and paste the API key which you obtained in the previous step.  Then the API request would be successful.

f. To check the currently active API keys, the user needs to access the ‘table-exporting-vs’ virtual server with '/subtables' URI. (Although it doesn’t have any authentication process, you can optionally enable the login process in this virtual server.) Type our API key table name (api_key_table) and click the ‘submit’ button.

g.  Then you can see the active API access key list here.

h. After 5minutes, you could see the key is expired automatically.

i.  If you try to access the API endpoint again with the previously obtained key, you can see the connection is blocked by BIG-IP APM because the key is expired already.

 

Summary

API Key-based access control provides a simple and easy API access control method for organizations. However, manual key configuration and key management bring extra operation overhead to SecOps or API owners. F5 BIG-IP APM can automate this process and help an organization deploy API-key access control more easily.

Although those benefits of BIG-IP APM, API Key method may not fit large-scale API deployment as an access control method. Because of its security issues, it is recommended to use OAuth for API deployment which requires a high-security level. In our next article, I will explain an overview of the OAuth protocol and how it works in F5 solutions.