cancel
Showing results for 
Search instead for 
Did you mean: 
Mikhail_Fedoro1
F5 Employee
F5 Employee

Introduction

There is an earlier article in the series that shows how to use the NGINX Controller for Authentication of API calls (See Use of NGINX Controller to Authenticate API Calls). It is also possible to use the BIG-IP to perform authentication of API calls. This is usually the preferred method if a translation needs to occur between the authentication method being used by clients and one that is being used by the API.

Topology

Picture 1 below, represents the overall solution topology. In previous articles, I've explained how to use API security features available on BIG-IP. In this article, we'll take a look at how to use BIG-IP to authenticate calls using the oAuth2.0 framework before they get forwarded to a WAF. Order is important here. A flood of unauthorized calls may put a significant load on WAF. Therefore, it is vital to authorize calls before passing them to WAF.

0151T000003lWwuQAE.png

Picture 1.

Configuration

A protection profile associated with a virtual server configures authentication of API calls, as well as sets up policies to secure the API. Per-request policy gets automatically created along with the profile. The policy gets most of its configuration from the profile but requires explicit specification of the provider list. The following diagram shows how all configuration pieces interact together.

0151T000003lWwpQAE.png


Let us go through all the steps to configure BIG-IP to authenticate API calls using the oAuth2.0 framework.


Firstly, resolver. It allows BIG-IP to resolve domain names e.g. API server hostname to forward API calls to.

0151T000003lWwzQAE.png


Next is identity provider for oAuth. In this example, Okta is used. Therefore Okta is responsible for:

  • Issuing JWT tokens to API clients
  • Issuing JWK keys to BIG-IP

As soon as OpenID URI for Okta is specified in the BIG-IP configuration, other related information is automatically retrieved, including JWK keys.

0151T000003lWwVQAU.png


Provider list aggregates multiple identity providers. This is useful if you want to accept JWT tokens from more than one provider.

0151T000003lWwMQAU.png


API protection profile contains primary configuration with following parameters:

  • OpenAPI file
  • Resolver
  • Per-request policy

Note, per-request policy gets created and configured with most properties implicitly based on options selected in the protection profile. However, identity provider needs to be configured explicitly.

0151T000003lWwWQAU.png


Open the "Access control" tab of the profile to access a per-request policy

0151T000003lWwaQAE.png


Per-request policy diagram shows how every incoming API call gets processed. At first BIG-IP checks identity. If a JWT token is valid, then BIGIP checks to see if the endpoint is in the allowed URL list. If both tests pass then BIG-IP forwards call towards its destination.

0151T000003lXEUQA2.png


Click on "OAuth scope" to specify a provider list.

0151T000003lWwQQAU.png


Specify provider list and change response to "response2". It returns the appropriate response code and authentication failure reason.

0151T000003lWwLQAU.png


The last step is to assign the API protection profile to a virtual server. From this point, BIG-IP will verify the identity of every incoming call before forwarding it to its destination.


Following is an example of a call with a valid JWT token that gets forwarded to the destination and the response that is received:

$ curl -sv https://7a583404-3e51-4cf4-935d-f9f84f108b17.com/uuid -H "Authorization: Bearer eyJra...omitted...f8b_Q"
> GET /uuid HTTP/1.1
> Host: 7a583404-3e51-4cf4-935d-f9f84f108b17.com
> User-Agent: curl/7.54.0
> Accept: */*
> Authorization: Bearer eyJra...omitted...f8b_Q
>
< HTTP/1.1 200 OK
< date: Thu, 23 Jan 2020 19:42:33 GMT
< content-type: application/json
< content-length: 53
< connection: keep-alive
< access-control-allow-origin: *
< access-control-allow-credentials: true
<
{
 "uuid": "c9f949a6-7fca-477a-9345-8cfc61a73d7b"
}
* Connection #0 to host 7a583404-3e51-4cf4-935d-f9f84f108b17.com left intact

Following is an example of a situation where the token is invalid or the API endpoint is not in the allowed URL list. In this case, the call is blocked with an appropriate error message.

$ curl -sv https://7a583404-3e51-4cf4-935d-f9f84f108b17.com/uuid -H "Authorization: Bearer eyJra...omitted...BAD...TOKEN...rGF-w"
> GET /uuid HTTP/1.1
> Host: 7a583404-3e51-4cf4-935d-f9f84f108b17.com
> User-Agent: curl/7.54.0
> Accept: */*
> Authorization: Bearer eyJra...omitted...BAD...TOKEN...rGF-w
>
< HTTP/1.1 401 Unauthorized
< www-authenticate: Bearer error="invalid_token",error_description="Internal error during signature verification"
< content-length: 0
< connection: Close
< Date: Thu, 23 Jan 2020 19:06:35 GMT
<
* Closing connection 0

$ curl -sv https://7a583404-3e51-4cf4-935d-f9f84f108b17.com/NO_SUCH_ENDPOINT -H "Authorization: Bearer eyJra...omitted...f8b_Q"
> GET /NO_SUCH_ENDPOINT HTTP/1.1
> Host: 7a583404-3e51-4cf4-935d-f9f84f108b17.com
> User-Agent: curl/7.54.0
> Accept: */*
> Authorization: Bearer eyJra...omitted...f8b_Q
>
< HTTP/1.1 403 Forbidden
< content-length: 0
< connection: Close
< Date: Thu, 23 Jan 2020 19:44:52 GMT
<
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):


Hopefully this was useful. See you in comments!


Good luck!

Version history
Last update:
‎03-Mar-2020 13:42
Updated by:
Contributors