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.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.
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.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.
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!
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!Authenticating Kubernetes Demo
Following up my article Authenticating KubernetesI want to show you the completed and running environment. Here is ademonstration of the Kubernetes API/Dashboard authentication with BIG-IP BIG-IP using mTLS, Basic Auth (Username/Password), and OAuth Tokens. This illustrates howBIG-IP Access Policy Manager (APM)can securely authenticate to Kubernetes using multiple methods and capture audit logs via BIG-IP Application Security Manager (ASM). As always, please let us know if you have questions. Further Reading Authenticating Kubernetes@DevCentral F5 Container Connector - Kubernetes @ Clouddocs.f5.com F5 Kubernetes Repositories @ github.com/F5Networks Authenticating @ kubernetes.ioProtecting API Access with BIG-IP using OAuth
As more organizations use APIs in their systems, they've become targets for the not-so-good-doers so API Security is something you need to take seriously. Most APIs today use the HTTP protocol so organizations should protect them as they would ordinary web properties. Starting in v13, BIG-IP APM is able to act as an OAuth Client, OAuth Resource Server and OAuth Authorization Server. In this example, we will show how to use BIG-IP APM to act as an OAuth Resource Server protecting the API. In our environment, we’ve published an API (api.f5se.com) and we’re trying to get a list of departments in the HR database. The API is not natively protected and we want APM to enable OAuth protection to this API. First, let’s try an unauthenticated request. You can see we get the 401 Unauthorized response which is coming from the BIG-IP. In this instance we’re only sending 3 headers, Connection (close), Content Length (0) and WWW Authenticate (Bearer), indicating to the client that it wants Bearer Token authentication. So we’ll get that authorization and a new access token. Here the Getpostman.com (Postman toolchain for API developers) is preconfigured to get a new access token from the OAuth authorization server, which is a BIG-IP. We will request the OAuth token and will need to authenticate to the BIG-IP. After that, we get an authorization request. In this case, BIG-IP is acting as an Authorization server and is indicating to the resource owner (us) that there is a HR API application that wants to use certain information (about us) that the authorization server is going to provide. In this case, it is telling us that the resource server wants to get scope api-email. We’ll click Authorize and now we have our auth token and is saved in the Postman client. Within the token properties we see that it expires in 300 seconds, it is a Bearer token and the scope is api-email and we get a refresh token as well. Now we can add this token to the header and try to make a request again. And this time, we get a much better response. We get a 200 OK, along with the headers of the application server. We’ll click on the Body tab within Postman, we’ll see the XML that the API has returned in response to the query for the list of departments that are available. There were no cookies being returned by the server if you were wondering about that tab. In the Headers tab we see the Authorization header that was being sent and the content of the Bearer token. A simple way to easily protect your APIs leveraging OAuth 2.0 Resource Server capabilities in BIG-IP. Special thanks to Michael Koyfman for the basis of the content and check out his full demo here. ps Related: Web API – Security Review – How to Hack an API and Get Away with It API Security Testing – How to Hack an API and Get Away with It API Reference - DevCentral Wiki
Remote Code Execution with Spring OAuth Extension (CVE-2018-1260)
Recently, a new Remote Code Execution vulnerability in Spring OAuth extension was published by Pivotal. The OAuth Protocol OAuth is a protocol that supports authorization processes by enabling users to share their data and resources stored on one site with another site. For example, when you use the sign in with Facebook feature available in many modern websites, you utilize the OAuth protocol to allow the 3rd party application to access resources from your Facebook account. This is achieved by authenticating against Facebook’s authorization server and obtaining a token that will be used by the 3rd party application to access the resource servers of Facebook. The supplied token will be validated and if approved the resource servers will send the requested resource. The Vulnerability There are some conditions that must be met for the application that uses the Spring Framework OAuth extension to be vulnerable: It must act in the role of an authorization server. It must not configure any scopes. OAuth scopes provide a way for the authorization server to limit the amount of access that is granted to an access token. For example, scopes can be defined to limit the 3rd party application to read only for certain resources. Because the malicious payload will be sent to the application in the scope parameter if the application will encounter a scope name that doesn’t match the configured ones it will throw an exception and terminate the authorization process. It must use the Whitelabel OAuth approval page. Whitelabel pages in the Spring framework are pages that are present only for demonstration and should be replaced by the application developers. Another example of a Whitelabel page in the Spring framework is the default 404 page, that should be customized by the developer. Figure 1: Spring OAuth Whitelabel approval page The vulnerable code resides in the WhitelabelApprovalEndpoint class which handles the requests sent to the /oauth/authorize endpoint. It holds the template HTML code that will be rendered by the application and shown to the user when he approves the authorization. The template html is saved as a string in a private variable of the class. Figure 2: Spring’s default OAuth approval HTML template. The HTML template contains a few placeholders that will be replaced with the request values once the page is rendered by the application (e.g. %csrf% and %scopes% placeholders). The function that is responsible for replacing those placeholders is the createTemplate function. Figure 3: createTemplate function used by the WhitelabelApprovalEndpoint class to replace the placeholders with the session values The first if statement in the createTemplate function checks if the model object or the request object containing a key or attribute named “scopes”. if it finds such key in the model object or attribute in the request object it will call the createScopes function, which is responsible for building a <ul> (unordered list) HTML element which will hold the scopes available in the model object or the request object. it is important to note that if the model object contains the key “scopes” the value that will be shown to the user in the Spring’s OAuth Whitelabel page will be taken from it and not from the user’s request thus making the application not vulnerable (Condition number 2 mentioned above for the application to be vulnerable). Figure 4: “createScopes” function used to create a <ul> HTML element containing the provided scopes. After replacing the values in the Whitelabel HTML template, Spring returns a “ModelAndView” class instance and instantiates a SpelView class instance which stands for Spring Expression Language View and passes the parsed HTML template string to the constructor of the SpelView class. Figure 5: ModelAndView class instance returned by Spring framework and SpelView is used as the View instance. The SpelView class implements the View Java interface which declares the render method and requires the class that implements it to give its own implementation to it. Another important point to note about the SpelView class is that it holds an instance of the PlaceHolderResolver interface which requires the class that implements it to implement the resolvePlaceholder method. Figure 6: SpelView class declaration and constructor implementation. During it’s render process the SpelView class attempts to extract values that are located inside “${}” template expressions and evaluate them by parsing them as Spring Expression Language (SpEL) expression instance. Figure 7: SpelView render method implementation. Now let’s recap, if the Spring application is being used as the OAuth Authorization Server, and the application didn’t define any OAuth scopes, the user can supply a Spring Expression Language Expression inside a “${}” expression template, that will be stored in the scope parameter and will be parsed by the SpelView class. As we saw in previous vulnerabilities in the Spring framework, evaluation of a user-controlled Spring Expressions by using the “StandardEvaluationContext” class may lead to arbitrary code execution. Figure 8: Malicious user-controlled input parsed as a Spring Expression by the application. Figure 9:The result of parsing the user provided Spring Expression. Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing Java code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Java Servlets/JSP” System. Also, operating system command execution signatures will detect the attempt to execute operating system commands as the payload for the exploit. Figure 10: Exploit blocked with attack signature 200003437 Figure 11: Exploit blocked with attack signature 200003073Social Login to Enterprise Apps using BIG-IP & OAuth 2.0
Password fatigue is something we’ve all experienced at some point. Whether it’s due to breaches and the ever present, ‘update password’ warnings, the corporate policy of a 90-day rotation or simply registering for a website with yet another unique username and password. Social login or social sign-in allows people to use their existing Google, Twitter, Facebook, LinkedIn or other social credentials to enter a web property, rather than creating a whole new account for the site. These can be used to authenticate, verify identity or to allow posting of content to social networks and the main advantage is convenience and speed. With v13, BIG-IP APM offers a rich set of OAuth capabilities allowing organizations to implement OAuth Client, OAuth Resource Server and OAuth Authorization Server roles to implement social logins. Let's look at BIG-IP’s capabilities (from the user's perspective) as an OAuth Client, OAuth Resource Server. We’ll navigate to our BIG-IP login screen and immediately you’ll notice it looks slightly different than your typical APM login. Here, you now have a choice and can authenticate using any one of the 4 external resources. Azure AD Enterprise and AD B2C along with Google and Facebook. Google and Facebook are very popular social login choices - as shown in the initial image above - where organizations are looking to authenticate the users and allow them to authorize the sharing of information that Google and Facebook already have, with the application. In this case, we have an application behind BIG-IP that is relying on getting such information from an external third party. For this, we’ll select Facebook. When we click logon, BIG-IP will redirect to the Facebook log into screen. Now we’ll need to log into Facebook using our own personal information. And with that, Facebook has authenticated us and has sent BIG-IP critical info like name, email and other parameters. BIG-IP has accepted the OAuth token passed to it from Facebook, extracted the info from the OAuth scope and now the application knows my identity and what resources I’m authorized to access. We can do the same with Google. Select the option, click logon and here we’re redirected to the Google authentication page. Here again, we enter our personal credentials and arrive at the same work top. Like Facebook, Google sent an authorization code to BIG-IP, BIG-IP validated it, extracted the username from the OAuth scope, passed it to the backend application so the application knows who I am and what I can access. Let's look at Microsoft. For Microsoft, we can authenticate using a couple editions of Azure AD – Enterprise and B2C. Let’s see how Enterprise works. Like the others, we get redirected to Microsoftonline.com to enter our MS Enterprise credentials. In this instance, we’re using an account that’s been Federated to Azure AD from another BIG-IP and we’ll authenticate to that BIG-IP. At this point that BIG-IP will issue a SAML assertion to Azure AD to authenticate me to Azure AD. After that, Azure AD will issue an OAuth token to that BIG-IP. BIG-IP will accept it, extract the user information and pass it to the application. Finally, let’s see how Azure AD B2C works. B2C is something that companies can use to store their non-corporate user base. Folks like partners, suppliers, contractors, etc. B2C allows users to maintain their own accounts and personal information. In addition, they can login using a typical Microsoft account or a Google account. In this case, we’ll simply use a Microsoft account and are directed to the Microsoft authentication page. We’ll enter our personal info, the servers communicate and we’re dropped into our WebTop of resources. Social logins can not only help enterprises offer access to certain resources, it also improves the overall customer experience with speed and convenience and allows organizations to capture essential information about their online customers. ps Related: What are social logins? The Most Popular Social Logins Globally [Infographic] Understanding the Benefits of Social Login – How does it add value to your website?
