Evaluating common integrations between Azure AD and APM - Part 1
Identity as a Service providers (IDaaS) are exploding in adoption rate, Azure AD being one that I encounter most frequently. Given that, I am often asked what options are available for integration between Azure AD and BIG-IP APM, including implementation steps. In this 4-part series, I will first summarize and contrast the integration options, including the pros and cons of each, then in each subsequent article we will dive into the requirements and implementation details for each method of integration. Please note that there may be additional integrations and authentication flows, this article series is however only covering 3 in particular. The 3 authentication flows we will discuss in this article series are: Network Policy Server (NPS) Azure MFA extension** SAML federation ROPC Oauth grant authentication flow **This replaces the legacy integration with Azure MFA Server which is no longer supported: https://devcentral.f5.com/s/articles/heres-how-i-did-it-integrating-azure-mfa-with-the-big-ip-19634 Method 1: Azure NPS Extension The method we will be examining in the first article of this series is integration between BIG-IP APM and Azure AD via a Network Policy Server (NPS) extension. This method is used to achieve Azure AD Multi-factor Authentication (MFA) capabilities for user authentication which is most often the primary business requirement for integration. User authentication requests are sent from BIG-IP APM to the NPS server where the NPS extension for Azure MFA will then inform Azure AD to initiate the MFA challenge. The NPS extension for Azure MFA does NOT support any conditional access policies, as the source of every authentication request from Azure AD's perspective will be that of the NPS server itself.By using this method, we can capture the username and password on the APM logon page for seamless password-based Single Sign-On (SSO), plus we get the MFA capabilities of Azure AD, truly the best of both worlds. Architecture and authentication flow: User requests a resource protected by BIG-IP APM and is presented with an APM logon page where they enter their credentials. BIG-IP captures these credentials as session variables and sends them to the predefined RADIUS AAA server, in this case that would be the NPS server with Azure MFA extension. The RADIUS server first validates user credentials, if successful then the 'AzureMFA' extension will notify Azure AD of the incoming user authentication request and initiate MFA challenge. The user is challenged using the chosen MFA method. Azure AD notifies the NPS extension of the MFA challenge result. The NPS extension responds back to the BIG-IP with a RADIUS response based on the outcome of the MFA challenge. If successful, the user is granted access to the protected application, webtop or resource. Pros: BIG-IP APM can capture both the username and password as session variables as part of the logon process, making password-based Single Sign-on (SSO) viable Requires no federation between BIG-IP and Azure AD Cons: Requires external infrastructure dependencies (Redundant NPS infrastructure) Azure AD Conditional access policy support is limited ***This however can be augmented with conditional policies on BIG-IP APM Method 2: SAML federation with Azure AD SAML is a well understood and adopted standard for federation between identity domains. By federating BIG-IP APM with Azure AD as the Identity Provider (IDP) we direct all user authentication requests to Azure AD. This means that all authentication features supported by Azure AD, such as Conditional Access Policies and MFA will work as intended, as the user is interfacing directly with Azure AD during authentication. By its very design, SAML federation limits the SAML Service Provider (SP), which is the role of BIG-IP APM in this case, from receiving the user's password as part of the authentication flow; this means we must use passwordless Single Sign-On (SSO) methods such as Kerberos or SAML for seamless access to applications and resources. Architecture and authentication flow: **Above depicts SP-initiated SAML authentication flow where BIG-IP APM is the Service Provider (SP) and Azure AD is the (IDP) User requests a resource protected by BIG-IP APM. APM responds to the user with a SAML request and directs them to the IDP (Azure AD). The user browser relays the SAML request to Azure AD. It is at this point that the user authenticates DIRECTLY with Azure AD. Once successfully authenticated (including MFA, if applicable), Azure AD responds to the user with a SAML response containing an Assertion and directs the user back to the BIG-IP APM. The user browser relays the SAML response to the BIG-IP and is provided access to the protected application or resource. Pros: Widely deployed and understood + very easy implementation Full support for conditional access policies and authentication functionality in Azure AD Cons: BIG-IP APM will not receive a password as part of the logon process - this means that password-based Single Sign-On (SSO) will not work out of the box ***We will explore options to get around this further in Article #3 Method 3: ROPC Oauth Grant The Resource Owner Password Credentials (ROPC) grant allows an application or intermediary to sign a user in by directly handling their password. Put simply, BIG-IP APM first captures the user credentials with a standard logon page and then validates them with Azure AD directly. This authentication flow may resemble that of traditional authentication flows such as Active Directory domain controllers or RADIUS servers. In most cases, ROPC grant flows are not highly recommended, as the user credentials are provided to the Oauth 2.0 client (BIG-IP) directly instead of to the Authorization Server (Azure AD) which arguably introduces additional risk.By using this method however, we capture the username and password on the APM logon page for password-based Single Sign-On (SSO) without requiring any on-premises infrastructure such as domain controllers or AAA servers to handle authentication. Architecture and authentication flow: User requests a resource protected by BIG-IP APM and is presented with an APM logon page where credentials are input. BIG-IP captures these credentials as session variables and sends them to the predefined Oauth Authorization Server (AS), Azure AD. If the credentials are correct, Azure AD responds to the BIG-IP with an ID token, Access token and optionally a refresh token. If successful, the user is granted access to the protected application or resource. Pros: BIG-IP APM can capture both the username and password as session variables as part of the logon process, making password-based Single Sign-on (SSO) viable Requires no on-premises infrastructure such as Active Directory or RADIUS/NPS for authentication Cons: Not recommended by Microsoft for Security reasons. No direct support for Azure AD MFA No support for Azure AD conditional access policies ***This however can be augmented with conditional policies on BIG-IP APM Summary In the first article of this series we reviewed 3 unique options for integration between BIG-IP APM and Azure AD. We also described the authentication flow as well as the pros and cons for each method. In each subsequent article, we will dive deeper into these three methods, providing detailed implementation instructions, caveats, and requirements as well as some anecdotal wisdom from the field!Basic OAuth concept and OAuth with F5 solutions
In my previous article [Overview of API Access Control and implementing API key access control with BIG-IP APM] , I explained the ‘API-Key based Access Control’ method and we could see how a user implements it easily and securely using BIG-IP APM. However, although the ‘API-Key’ method has its advantages, it also has some limitations when we use it in the enterprise-grade API access control implementation. Problems of the API-Key Access Control API Key compromise Although some improved API-Key systems can set an expiration time for API keys, the expiration time for keys has to be set for a longer time such as weeks, months, or a year. This is because the issued key should be configured manually to API clients or API G/W or API endpoints. This manual process requires extra operational overhead, thus it is normally recommended to use a long expiration time for keys. However, a longer expiration time may bring security problems as well. Let’s say the issued key is stolen without recognition by the organization, then what happens? Since the key’s expiration time might be set to months or a year, the attacker who stole the key can access the corporate resources until the key reaches its expiration time, a year in the worst case. 3rd party integration Since the API-key method doesn’t have any pre-defined flow or format of the key, it could be challenging to integrate the enterprise’s API system with 3rd party client applications. For example, if Google, AWS, Dropbox, and Open banking services were to provide all different API access control methods, application developers would need to create all different modules for their applications to integrate each service. This is not a scalable solution to integrating the organization’s APIs with other 3rd party applications. OAuth 2.0 An OAuth 2.0 standard protocol was introduced in 2012 to solve these challenges and was defined in RFC6549. It was designed to implement API access control and is one of the most widely adopted methods for API access control purposes. The common misunderstanding of an OAuth is that it is considered an ‘Authentication protocol’. But it’s not an authentication protocol. While OAuth can provide authentication capability with its well-known extension – ‘OIDC(OpenID Connect)’, OAuth itself can work without OIDC and it primarily solves the access delegation problem. If a user wants to delegate third-party application access to their Gmail profile, OAuth can solve this. Many experts explain an OAuth with an example of a hotel key card. Once the key card is issued to the user, the room doesn’t authenticate the user but rather the valid key card. An OAuth works like a hotel key card, thus it is not an authentication protocol. In an OAuth implementation, a token performs the same role as a ‘key’ of the ‘API-Key method’. One of the biggest technical advantages of OAuth is to provide centralized token management, user authentication, and a privilege consent process. This centralized policy management can help an enterprise to expand their API network and organizations more easily integrate their APIs with external applications. An OAuth is a big topic and we can not cover all the details of it in this short article. However, there are some important terminologies and concepts to understand the overall OAuth flow. OAuth roles OAuth standard introduces 4 different roles in a typical OAuth flow. Resource Owner(RO): RO indicates the person who owns the resources. If a fintech app tries to access a user’s banking account, the user is the resource owner(RO). Resource Server(RS): RS is the place to host protected resources. In the above banking example, the server which hosts the banking API is the resource server and the banking API itself is the resource. OAuth Authorization Server: OAuth AS is the centralized system to manage and issue the access token to OAuth clients. OAuth Client Application: The OAuth client indicates the application which wants to access a resource on behalf of the resource owner. In the banking example, the fintech app is the OAuth client. OAuth grant types OAuth grant types define how an OAuth client can obtain a grant from a resource owner to access their resources on their behalf. An OAuth 2.0 defines 4 different grant types. 1) Authorization Code Grant The application(=client) obtains the ‘authorization code’ first from the authorization server and the client exchange the code for an access token. This allows the access token to be never exposed to the resource owner’s user-agent. 2) Implicit Grant Optimized for in-browser JS clients. Instead of an authorization code, an access token is issued immediately without client authentication. 3) Resource Owner Password Credential Grant Username and password are used instead of an authorization code to obtain an access token. Should only be used for highly trusted clients or when other types are not available. Username and password are only used to get an access token and are not stored. 4) Client Credential Grant The client supplies its own credentials to get an access token. Support OAuth in F5 solutions Since OAuth is a key protocol for the enterprise-grade API implementation, F5 solutions support OAuth widely as well. F5 BIG-IP APM and NGINX Plus support various OAuth roles and grant types. Organizations can build their own secure OAuth framework using F5 solutions. Integrating with partner solutions Since OAuth is a standard protocol, one of its strong benefits is to be supported by different vendor solutions. While F5 provides all types of OAuth roles in our product portfolio, we also provide tight integrations with our partner’s platforms, this includes leading vendors of IDaaS solutions – Microsoft Azure AD, Okta, and Ping. F5 BIG-IP APM has built-in OAuth configuration sets for these vendors already, so customers easily can configure their BIG-IP APM device to work with these vendor’s solutions. That means a customer can deploy Microsoft Azure AD or Okta or Ping Identity as their OAuth Authorization Server, and they can configure the BIG-IP APM and NGINX Plus API Gateway as their OAuth Resource Server. Both BIG-IP APM and NGINX Plus can work with those IDaaS vendor’s solutions to build an enterprise-level of OAuth for an organization. Summary An OAuth is an essential component to implement API access control to protect the enterprise’s API endpoints. However, the OAuth standard includes different roles, grant types, and extensions. Because of its complexity, some organizations may have some difficulty adopting the technology. F5 solution can help an organization adopt OAuth more easily. For example, F5 supports different roles of OAuth with multiple solutions – BIG-IP APM and NGINX Plus API Gateway. A customer can build their own OAuth network using F5 solutions only or they also can configure our solutions to work with industry-leading IDaaS vendors such as Microsoft, Okta, and Ping Identity. With all the flexibility and powerful policy management capabilities of the F5 solution, an organization can implement and operate its OAuth systems more effectively.Request and validate OAuth / OIDC tokens with APM
BIG-IP APM is able to request and validate OAuth2.0 and OpenID Connect tokens. It can act as Client, Resource Server and Authorization Server. In this article, I cover the use cases where APM acts as Resource Server (validating the tokens) and Client (requesting the tokens). 1. The tokens : Access Token: this is the Oauth2.0 token (access_token). It is used for Authorization and has to bevalidated by the Resource server. This Resource Server will contact the Authorization server for validation (Out of Path validation - External) Access Token can be either OPAQUE or JWT ID Token: this is the OpenID Token (id_token).It is used by the client onlyin order to know you use the resource owner. For instance, when you see you name and your picture on the top right corner of an app, this comes from the ID_Token. This token is not user/validated by the Resource Server ID Token is JWT only 2. OPAQUE vs JWT tokens : JWT: Decodable Encryptable Can be validated against a preconfigured JWKS in-box or externally OPAQUE: Not decodable (opaque) Proprietary format, might be any length, and must be unique Must be validated in out-of-path HTTP request to the originating provider (the Authorization Server) 3. Token validation : OAuth Scope agentis used to validate anAccess Token either against aninternalJSON web key set (JWKS) if the Access Token isJWTvia an APM provider configuration (Azure AD uses JWT only) orexternallyvia HTTPS if the Access Token isOpaque. JWKS is faster because we don't have an extra HTTP transaction. Oauth Scope agentis used when APM is RS and the request from the client (APM or mobile app) has a authorization bearer header. Either with Opaque (External)or JWT token (Internal). With Opaque token, if the RS needs more information about the user, it needs to request anOpenID Connect UserInfoby presenting theaccess_token to the AS. The opaque scope provides with several information but it depends of the AS. For Google, an OIDC userInfo is needed to get the First and Last names. 4. Token Request : Oauth Client agentis used to request theAccess token and id_tokenwhen APM is deployed asOauth Client. To do so, 2 grant types are available (Code and password) WithAuthorization code grant, the Client agentexchangesan Authorization code for an access_token code + id_token (if OIDC used). When the Oauth Client gets the access_token (and id_token), theOauth scope agent validatesthem.
How to customise Azure AD OIDC user ID token for APM integration
Overview A Service Provider (SP) such as the F5 APM can integrate with Azure AD (AAD) as an Identity Provider (IDP) for federated authentication using OpenID Connect (OIDC). Through this process, a user visiting APM (e.g., https://myapps.acme.corp ) is immediately redirected to AAD for authentication, once authenticated, AAD returns a code to the APM via the user browser. The APM grabs that code, adds additional information, sends them together to AAD, and finally receives an ‘access_token’ and ‘id_token’. This article takes a special focus around what is included in ‘id_token’ that AAD returns, as it is used by APM, and broadly speaking by any relying party SP, for the purpose of session creation. ‘id_token’ (part of OIDC) contains user identity information and is highly customizable. The customization of ‘id_token’ is completely done within AAD. The concept is simple, but not until it is well understood in my experience; especially with the AAD having a bunch of configuration items in the mix, such as ‘Token configuration’, ‘API permissions’ and ‘Expose an API’. This article hopes to cut all the clutter and un-muddy the water so to speak, around this topic. OIDC As a refresher, the difference between oAuth and OIDC lies in that OIDC is an identity piece laying on top of oAuth. Specifically, with oAuth, ‘access_token’ alone is returned, whereas with OIDC, ‘id_token’ is returned in addition to ‘access_token’. Scope To tell AAD we are using OIDC, the APM needs to include a scope named ‘openid’ in its outbound request to the AAD. This is achieved via the following setting. Within AAD, your application must include ‘openid’, as shown below. By default, the ‘openid’ scope comes with a list of claims that will be included in ‘id_token’. However, for certain claims to be available, additional scopes are also required. For example, if you want to have ‘preferred_username’and ‘name’ claims included, ‘profile’ scope needs to be added as well, as is depicted in the following. AAD also lets you add optional claims via ‘Token configuration’ as shown below. If these optional claims need additional scopes, AAD will add those scopes in for you under ‘API permissions’. On the APM ‘OAuth Client’ configuration, make sure to add those scopes in as highlighted below. Once the APM matches scope with AAD, AAD will include all claims in ‘id_token’ it sends back to the APM. The APM is then able to consume those claims based on the use case (e.g., create a session using email) I am hoping that this short article sheds some light around your integration work around this space.
Use of BIG-IP to authenticate API calls based on oAuth2.0 framework
Introduction There is an earlier article in the seriesthat 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. 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. 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. 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. Provider list aggregates multiple identity providers. This is useful if you want to accept JWT tokens from more than one provider. 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. Open the "Access control" tab of the profile to access a per-request policy 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. Click on "OAuth scope" to specify a provider list. Specify provider list and change response to "response2". It returns the appropriate response code and authentication failure reason. 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!Using NGINX Controller API Management Module and NGINX App Protect to secure financial services API transactions
As financial services APIs (such as Open Banking) are concerned primarily with managing access to exposed banking APIs, the security aspect has always been of paramount importance. Securing financial services APIs is a vast topic, as security controls are distributed among different functions, such as user authentication at the Identity Provider level, user authorization and basic API security at the API Gateway level and advanced API security at the WAF level. In this article we will explore how two NGINX products, Controller API Management Module and App Protect, can be deployed to secure the OAuth Authorization Code flow which is a building block of the access controls used to secure many financial services APIs.. Physical setup The setup used to support this article comprises of NGINX Controller API Management Module, providing API Management functions through an instance of NGINX API Gateway and NGINX App Protect deployed on a Kubernetes Ingress Controller providing advanced security for the Kubernetes-deployed demo application, Arcadia Finance. These elements are being deployed and configured in an automated fashion using a Gitlab CI/CD pipeline. The visualization for NGINX App Protect is provided by NAP dashboards deployed in ELK. Note: For the purpose of supporting this lab, APM was configured as an OAuth Authorization Server supporting OpenID Connect. Its configuration, along with the implementation details of the third party banking application (AISP/PISP), acting as an OAuth Client, is beyond the scope of this article. In an OAuth Authorization Code flow, the PSU (End User) is initiating an API request through the Account or Payment Information Services Provider (AISP/PISP Application) which first redirects the end user to the Authorization Server. Strong Customer Authentication is being performed between the end user and Authorization Server which, if successful, will issue an authorization code and redirect the user back to theAISP/PISP Application. The AISP/PISP Application will exchange the authorization code for an ID Token and a JWT Access Token, the latter will be attached as a bearer token to the initial end-user API request which will then be forwarded to the API Gateway. The API Gateway will authenticate the signature of the JWT Access Token by downloading the JSON Web Key (JWK) from the Authorization Server and may apply further security controls by authorising the API call based on JWT claims and/or apply rate limits. Worth noting here is the security function of the API Gateway, which provides positive security by allowing only calls conforming to published APIs, in addition to authentication and authorization functions. The Web Application Firewall function, represented here by the NGINX App Protect deployed on the Kubernetes Ingress Controller (KIC), will add negative security protection, by checking the request against a database of attack signatures, and advanced API security, by validating the API request against the OpenAPI manifest and providing Bot detection capabilities. Configuration To configure the NGINX Controller API Management Module, first create an Application by sending a POST request to 'https://{{ my_controller }}/api/v1/services/environments/env_prod/apps' having the following body: { "metadata": { "name": "app_api", "displayName": "API Application Arcadia", "description": "", "tags": [] }, "desiredState": {} } Then create an Identity Provider, pointed at the Authorization Server's JWK endpoint, by sending a PUT request to 'https://{{ my_controller }}/api/v1/security/identity-providers/bank_idp' having the following body: { "metadata": { "name": "bank_idp", "tags": [] }, "desiredState": { "environmentRefs": [ { "ref": "/services/environments/env_prod" } ], "identityProvider": { "type": "JWT", "jwkFile": { "type": "REMOTE_FILE", "uri": "https://bank.f5lab/f5-oauth2/v1/jwks", "cacheExpire": "12h" } } } } Create an API definition by sending a PUT request to 'https://{{ my_controller }}/api/v1/services/api-definitions/arcadia-api-def/versions/v1' with the following body: { "metadata": { "name": "v1", "displayName": "arcadia-api-def" }, "desiredState": { "specs": { "REST": { "openapi": "3.0.0", "info": { "version": "v1", "title": "arcadia-api-def" }, "paths": {} } } } } Then import the OpenAPI definition by sending a PUT request to 'https://{{ my_controller }}/api/v1/services/api-definitions/arcadia-api-def/versions/v1/import' with the OpenAPI JSON as a request body. Publish the API definition by sending a PUT request to 'https://{{ my_controller }}/api/v1/services/environments/env_prod/apps/app_api/published-apis/prod-api', with the following body: { "metadata": { "name": "prod-api", "displayName": "prod-api", "tags": [] }, "desiredState": { "apiDefinitionVersionRef": { "ref": "/services/api-definitions/arcadia-api-def/versions/v1" }, "gatewayRefs": [ { "ref": "/services/environments/env_prod/gateways/gw_api" } ] } } Declare the necessary back-end components (in this example webapi-kic.nginx-udf.internal Kubernetes workload) by sending a PUT to 'https://{{ my_controller }}/api/v1/services/environments/env_prod/apps/app_api/components/cp_moneytransfer_api' with the following body: { "metadata": { "name": "cp_moneytransfer_api", "displayName": "cp_moneytransfer_api", "tags": [] }, "desiredState": { "ingress": { "uris": { "/api/rest/execute_money_transfer.php": { "php": { "get": { "description": "Send money to a friend", "parameters": [ { "in": "body", "name": "body", "required": true, "schema": { "type": "object" } } ], "responses": { "200": { "description": "200 response" } } }, "matchMethod": "EXACT" } } }, "gatewayRefs": [ { "ref": "/services/environments/env_prod/gateways/gw_api" } ] }, "backend": { "ntlmAuthentication": "DISABLED", "preserveHostHeader": "DISABLED", "workloadGroups": { "wl_mainapp_api": { "loadBalancingMethod": { "type": "ROUND_ROBIN" }, "uris": { "http://webapi-kic.nginx-udf.internal:30276": { "isBackup": false, "isDown": false, "isDrain": false } } } } }, "programmability": { "requestHeaderModifications": [ { "action": "DELETE", "applicableURIs": [], "headerName": "Host" }, { "action": "ADD", "applicableURIs": [], "headerName": "Host", "headerValue": "k8s.arcadia-finance.io" } ] }, "logging": { "errorLog": "DISABLED", "accessLog": { "state": "DISABLED" } }, "security": { "rateLimits": { "policy_1": { "rate": "5000r/m", "burstBeforeReject": 0, "statusCode": 429, "key": "$binary_remote_addr" } }, "conditionalAuthPolicies": { "policy_1": { "action": "ALLOW", "comparisonType": "CONTAINS", "comparisonValues": [ "Payment" ], "sourceType": "JWT_CLAIM", "sourceKey": "scope", "denyStatusCode": 403 } }, "identityProviderRefs": [ { "ref": "/security/identity-providers/bank_idp" } ], "jwtClientAuth": { "keyLocation": "BEARER" } }, "publishedApiRefs": [ { "ref": "/services/environments/env_prod/apps/app_api/published-apis/prod-api" } ] } } Note the 'security' block, specifying the JWT authentication, the Identity Provider from where to download the JWK, the authorization check applied on each request and the rate limit policy. The configuration used to deploy NGINX App Protect on the Kubernetes Ingress Controller can be consulted here. Summary In this article we showed how NGINX Controller API Management Module and NGINX App Protect can be deployed to protect API calls as part of the OAuth Authorization Code flow which is a basic flow used to control the access to many financial services APIs. Links UDF lab environment link.
