F5 BIG-IP Access Policy Manager (APM) v17 new features and capabilities

• Introduction
• CRLDP Maximum Size Cache Support
• JWE Consumption Support
• Device Passcode Complexity Support (Android F5 Access Application)
• NLA on Machine Tunnel Support
• PKCE Support on OAuth Authorization Server
• Support for Microsoft Intune's new Compliance Retrieval service
• TLS 1.2 AES GCM ciphers support for OAuth Provider Discovery

 

 

 

 

 

 

 

 

 

V17 and later

 

JWE Consumption Support

BIG-IP APM already supports most of the functionalities for the JSON Web Token (JWT) use case to provide mobile or system access (through either native apps or browser based) to enterprise applications. However, secure authentication requires JSON Web Encryption (JWE) to encrypt the JWT.

Now, F5 Oauth Client and Resource Server support consumption of JWE which is issued by the Identity providers.

This feature aims to extend the existing JWT functionality for BIG-IP APM as Client and Resource Server with the following algorithm sets mentioned below to decrypt the JWE token.

RSA OAEP with AES_GCM_128

RSA OAEP with AES_GCM_256

A lab for the JWT configuration can be found here,

https://f5-agility-labs-iam.readthedocs.io/en/latest/class2/module2/module2.html

A secure JWT setup, How not to guide can be found here,

https://www.f5.com/labs/articles/threat-intelligence/jwt--a-how-not-to-guide

Device Passcode Complexity Support (Android F5 Access Application)

Effective August 2021, due to new restrictions from Google, F5 Access application can be uploaded to play store only If the app is built against API level 29.

Google has added restrictions on device administration policies that can be enforced by application vendors. Because of this change, F5 has to move to new API's to enforce password policies on devices running Android 10 and higher.

A new setting Device Lock Complexity option in Connectivity Profile settings for Android F5 Access Client allows the administrator to configure the password policies for devices. You can continue to use the older method of enforced device lock on devices running on Android 9 and lower. The client-side support for the device lock complexity is added from F5 Access for Android 3.0.8 versions.

NLA on Machine Tunnel Support

The Network Location Awareness (NLA) on machine tunnel for Windows determines when a client should start a Network Access connection. During a network switch, such as changing WiFi connections, NLA detects whether a connection is corporate or remote and enables BIG-IP Edge Client to automatically terminate a VPN session on a corporate network and establish a VPN connection on a remote network.

When an administrator adds corporate DNS suffixes in the DNS name setting of the BIG-IP APM connectivity profile, the NLA feature compares the DNS suffixes present on the system against the administrator configured DNS list on a network switch. If the DNS Suffix matches, the connection is identified as a corporate network, and the client does not attempt to establish a Network Access connection. The machine tunnel service that supports the maintenance and remote troubleshooting is disabled on a corporate network. When the suffixes don’t match, the connection is identified as a non-corporate network, and the client attempts to establish a Network Access VPN connection. The machine tunnel service is enabled on a non-corporate network.

Before v17

v17 and later

PKCE Support on OAuth Authorization Server

This release includes an implementation of Proof Key for Code Exchange (PKCE) that extends the authorization code flow. PKCE mitigates authorization code interception attacks when the public clients request access using authorization code.

Clients generate a random code verifier string and employ a code challenge method (plain or SHA256) to validate themselves with the authorization server.

You can enable the PKCE feature for both the Client Application and the OAuth profile. The settings in the Client Application override the settings in OAuth Profile. This option is useful for the use cases that support both public and private clients in the same authorization server. PKCE is used primarily for public clients with a more restricted “s256” challenge method and is optional for private clients.

Before v17

v17 and later

During PKCE configuration on the client-side, you can choose the code challenge method. By default, clients are expected to authorize with APM using the SHA256 code challenge method. Clients who cannot perform the SHA256 code challenge (s256) can use the plain code challenge (plain) method. Refer to the RFC7636 document for more details.

Support for Microsoft Intune's new Compliance Retrieval service

In June 2021, Microsoft released the Compliance Retrieval service to replace the Intune NAC service, offering improved security and reliability. This means Microsoft is moving away from the device ID based compliance check towards Intune ID in the certificate-based compliance check.

The BIG-IP APM now supports the new Compliance Retrieval service and uses certificate-based authentication to check for device enrollment and compliance state with Intune.

You can configure an access policy to allow access to devices that have Intune ID in the authentication certificate.

Refer to the latest Edge Client and Application Configuration guide for the settings required on the BIG-IP system and the Microsoft Endpoint Manager admin center to maintain NAC availability.

https://techdocs.f5.com/en-us/edge-client-7-2-2/big-ip-access-policy-manager-edge-client-and-application-configuration-7-2-2/configuring-access-policy-manager-for-mdm-applications.html#supporting-intune-deviceid

Refer to the New Microsoft Intune service for network access control for additional details regarding new Microsoft Intune service.

TLS 1.2 AES GCM ciphers support for OAuth Provider Discovery

Starting January 31, 2022, Microsoft has discontinued support for Transport Layer Security (TLS) 1.0/1.1/3DES cipher suites due to potential protocol downgrade attacks and other TLS vulnerabilities. Microsoft Azure AD plans to phase out support for the TLS 1.0/1.1/3DES cipher suites and implement a secure TLS 1.2 cipher suite that supports the secure transmission of data between clients and servers. Therefore, Microsoft Azure AD chooses the following TLS 1.2 AES GCM cipher suites during the TLS handshake:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

In addition, the latest version of the OpenShift Container Platform recommends the use of the most secure TLS 1.2 AES GCM cipher suite over previous weak cipher suites.

Due to the use of weak TLS 1.0, 1.1, 3DES cipher suites, the Oauth provider discovery module option does not function. TLS 1.2 AES GCM cipher suites support is added to resolve the Oauth provider discovery failures.