Bypass Azure Login Page with OAuth login_hint on F5 BIG-IP APM
Overview This article demonstrates how to enhance the user experience between F5 BIG-IP APM (OAuth Client) and Azure AD (OAuth Authorization Server) by implementing the login_hint parameter. This approach eliminates the need for users to enter their credentials twice, once on the F5 login page and again on the Azure login page. Problem Statement When users access applications protected by F5 APM that authenticate against Azure AD using OAuth/OIDC, they often encounter a suboptimal experience: User enters credentials on the F5 login page (often using their familiar sAMAccountName) F5 redirects to Azure AD for OAuth authentication Azure AD presents another login page asking for the same credentials (expecting UPN/email format) This creates additional friction because users may not know their User Principal Name (UPN) and typically use their sAMAccountName for domain authentication. The login_hint parameter solves this by allowing F5 APM to translate the user's sAMAccountName to their UPN and pre-populate the Azure login page, effectively bypassing the redundant login prompt. Alternative approach The same functionality can be achieved using SAML, as described here. However, I find the OAuth approach cleaner, as it eliminates the need for an iRule and also allows you to include the prompt parameter. This can be useful when you want to force authentication in Azure instead of relying on an existing session. See herefor details. Prerequisites F5 BIG-IP with APM Azure AD tenant with application registration Basic OAuth/OIDC configuration between F5 and Azure AD (as outlined in https://my.f5.com/manage/s/article/K53313351) Implementation Steps Step 1: Complete Basic OAuth Setup Follow the standard F5 APM OAuth configuration with Azure AD: Configure OAuth Server Object Navigate to Access ›› Federation ›› OAuth Client/Resource Server ›› OAuth Server Create a new OAuth server configuration for Azure AD Set the provider type to "Microsoft Identity Platform 2.0" Configure Access Profile Create an access profile with OAuth Client agent Configure authentication redirect and token requests Step 2: Create Custom Authentication Redirect Request The key modification involves creating a custom authentication redirect request that includes the login_hint parameter: Navigate to Request Configuration Access ›› Federation ›› OAuth Client/Resource Server ›› Request Clone the Default Request Find the existing /Common/MSIdentityPlatform2.0AuthRedirectRequest Create a copy Name it something descriptive like MSIdentityPlatform2.0AuthRedirectRequest_LoginHint and the same parameters as /Common/MSIdentityPlatform2.0AuthRedirectRequest Add login_hint Parameter Parameter Name: login_hint Parameter Type: custom Parameter Value: %{session.ad.last.attr.userPrincipalName} or any other variable containing user’s UPN based on your environment and Authentication configuration In the Parameters section, click Add Configure the new parameter: Step 3: Update VPE OAuth Configuration Access the Visual Policy Editor Go to Access ›› Profiles/Policies ›› Access Profiles (Per-Session Policies) Edit your access profile Click Edit to open the VPE Modify OAuth Client Agent Locate the OAuth Client agent in your policy Edit the OAuth Client agent properties In the Authentication Redirect Request dropdown, select your new custom request: MSIdentityPlatform2.0AuthRedirectRequest_LoginHint Apply Access Policy Click Apply Access Policy to save changes Step 4: Session Variable Configuration and UPN Translation The key to successful login_hint implementation is ensuring the proper session variable is populated with a UPN-formatted email address. F5 APM can automatically translate sAMAccountName to UPN during AD authentication. Complete Policy Flow Example Start ↓ Logon Page (user enters: DOMAIN\john.doe or john.doe) ↓ AD Auth (authenticate and populate session variables) ↓ AD Query (to fetch user attributes) ↓ OAuth Client (with custom redirect request including login_hint=john.doe@company.com) ↓ Azure AD (pre-populated with UPN, bypasses login prompt) ↓ Application Access Troubleshooting Common Issues login_hint Parameter Not Working Verify the session variable contains a valid email address Check that the custom request is selected in the OAuth Client agent Ensure the parameter type is set to "custom" Session Variable Empty or Wrong Format Verify AD authentication and query occurs before OAuth redirect Check AD attribute mapping configuration Confirm the userPrincipalName attribute exists in your AD schema Ensure domain suffix matches Azure AD tenant domain Azure AD Still Prompts for Login Verify the email format matches Azure AD expectations Check Azure AD application configuration for login_hint support Ensure the user exists in the Azure AD tenant Debugging Tips Enable APM debug logging: tmsh modify sys db log.apm.level value debug Use browser developer tools to inspect the OAuth redirect URL Verify session variables using Variable Assign agents in VPE Security Considerations The login_hint parameter only pre-populates the username field; users still must provide valid credentials This is a user experience enhancement, not a security bypass Ensure session variables don't contain sensitive information beyond the username/email Conclusion Implementing login_hint with OAuth on F5 BIG-IP APM significantly improves user experience by eliminating redundant login prompts. The key advantage is that F5 APM can seamlessly translate users' familiar sAMAccountName credentials to the UPN format required by Azure AD, allowing users to authenticate once with their domain credentials while Azure AD receives the properly formatted UPN for the login_hint. This approach maintains security while providing a seamless user experience, particularly beneficial in environments where: Users are more familiar with their sAMAccountName than their UPN Organizations want to minimize authentication friction Azure itself is also federated to another IDP and you want transparent rederiction The solution leverages F5 APM's AD integration capabilities to handle the username format translation automatically, making it transparent to end users.F5 BIG-IP APM with Omnissa Workspace ONE Access
This article discusses the collaboration between Omnissa and F5 to integrate Workspace ONE Access Cloud with F5 Access Policy Manager (APM). Workspace ONE Access unifies applications and desktops into a single, aggregated workspace, allowing employees to access resources from anywhere while simplifying IT administration through fewer management points and flexible access. The deployment of Workspace ONE Access in the cloud centralizes assets, devices, and applications, enabling secure management of users and data. Organizations benefit from instant upgrades without maintenance outages. The document provides detailed instructions for configuring Workspace ONE Access Cloud as an Identity Provider (IDP) in front of F5 APM as a Service Provider (SP), utilizing APM as a gateway for Omnissa Horizon. This integration aims to offer a comprehensive view of the workspace, ensuring robust DMZ security and scalability with the F5 PCoIP/Blast Proxy in conjunction with Omnissa Horizon.
SOLVED: sending IsCompliant, IsKnown and IsManaged via SAML (SSO)
Background We have an EntraID (Azure/Microsoft365) SAML based VPN using the APM module and were keen to provide a different device pool to domain devices, rather than personal devices (BYOD). We noted that, in the EntraID logs, it included elements such as whether the device IsCompliant, IsKnown and/or IsManaged: Wrong step first We followed part of the exceptionally good video from Matthieu Dierick (https://www.youtube.com/watch?v=DBA84d4VJU8) in which he explains how to configure InTune to make the IsCompliant assertion and push a certificate onto the device to identify it.. and then the BIG-IP Edge client will send that certificate back to be used via an API call against InTune (even if EntraID isn't used for your APM authentication). To get the API bit to function we needed to follow the guidance in https://my.f5.com/manage/s/article/K00943512 But we aren't that far down the route with InTune and, without pushing that certificate, we got the error "Device ID was not found in session variables" (as explained in https://my.f5.com/manage/s/article/K93969130 ) To get working: Azure steps It seems exporting these variables isn't natively available through the GUI although there were some pointers available from Azure AD - SAML - Intune - ismanaged attribute - Microsoft Q&A In short, Navigate to: https://portal.azure.com/ Microsoft EntraID Under Manage > App registrations (this will default to "owned application") choose "all applications" tab Filter by the name of your SAML configuration Manage > Manifest Take a copy of the manifest incase you want to revert (note that it won't let you save it unless it can parse the input) Find the section "optional claims" and inject the following after any groups you pass back: "optionalClaims": { "accessToken": [], "idToken": [], "saml2Token": [ { "additionalProperties": [ "on_premise_security_identifier" ], "essential": false, "name": "groups", "source": null }, { "additionalProperties": [ ], "essential": true, "name": "is_device_managed", "source": null }, { "additionalProperties": [ ], "essential": true, "name": "is_device_compliant", "source": null }, { "additionalProperties": [ ], "essential": true, "name": "is_device_known", "source": null } ] }, To get working: APM steps In the visual policy editor you can now assign variables to those claims of the form: session.logon.last.isknown = mcget {session.saml.last.attr.name.http://schemas.microsoft.com/201 4/02/devicecontext/claims/isknown} session.logon.last.iscompliant = mcget {session.saml.last.attr.name.http://schemas.microsoft.com/201 4/09/devicecontext/claims/iscompliant} session.logon.last.ismanaged = mcget {session.saml.last.attr.name.http://schemas.microsoft.com/201 2/01/devicecontext/claims/ismanaged} So you can end up with a variable assignment box that looks like: (just be careful with copy/paste that it doesn't introduce spaces in the session variables) Then you can do a new general purpose > empty box with a branch rule evaluating: expr {[mcget {session.logon.last.ismanaged}] == "true"} Optionally you can record the output of these variables by adding a logging box with the entry: username=%{session.logon.last.username}, ismanaged=%{session.logon.last.ismanaged}, iscompliant=%{session.logon.last.iscompliant}, isknown=%{session.logon.last.isknown}Sharing User Credentials Between SAML IDP and SP Policies in F5 APM
In F5 APM environments with one SAML Identity Provider (IDP) and multiple Service Providers (SPs), SP policies may need access to user credentials (like passwords) for SSO mechanisms such as NTLM or RDP. Since SAML doesn't transmit passwords, this solution enables secure credential sharing by storing the password in a custom session variable on the IDP side and passing the IDP session ID to the SP as a SAML attribute. An iRule on the SP side then uses this session ID to retrieve the password from the IDP session, making it available for SSO credential mapping. This approach maintains security by avoiding password exposure in the SAML assertion and leverages internal session sharing between policies.Protecting APIs with Access Policy Manager and custom iRules
The problem: Unprotected API - Vulnerable to Overload Without Rate-Limiting Enforcement Our customer in the B2B sector is encountering a challenge with their public API. Despite having implemented a custom method for generating long-lived API keys, they find themselves unable to enforce rate-limiting effectively. This absence of rate-limiting mechanisms poses significant challenges, potentially resulting in the overloading of their system due to excessive requests or the exploitation of their API by unauthorized users. Without proper rate-limiting controls in place, the customer faces risks to both the performance and security of their API infrastructure, necessitating a solution to mitigate these concerns and ensure the smooth operation of their services for their clients. Our customers wants to offer two tiers of service level agreements (SLAs) - gold and standard. Complicating matters further, the API key, integral to authentication, is transmitted via a custom HTTP header. The solution: BIG-IP APM and Custom iRules for Effective Rate-Limiting My solution involves leveraging the API Protection feature of BIG-IP APM in conjunction with a custom iRule. By utilizing this combination, our customer can effectively extract the API Keys from HTTP requests and enforce rate limiting on specific API endpoints. As for now they only want to enforce rate limiting on the POST endpoints. This approach empowers the customer to secure their API while efficiently managing and controlling access to critical endpoints, ensuring optimal performance and safeguarding against abuse or overload. With this iRule we can to extract the API key from the HTTP Requests and store it in a variable, that can later be used by the API Protection feature of the APM. API Keys and the associated SLA level are stored in a Data Group of the type string. # Enable (1) or disable (0) logging globally when RULE_INIT { set static::debug 1 } # Access and analyze the HTTP header data for SLA value when HTTP_REQUEST { set sla [class lookup [HTTP::header value apikey] dg_apikeys] if { $static::debug } {log local0. "Made it to HTTP_REQUEST event with SLA value $sla."} } # Evaluate SLA value during per-request access policy execution when ACCESS_PER_REQUEST_AGENT_EVENT { set id [ACCESS::perflow get perflow.irule_agent_id] if { $id eq "read-sla" } { if { $static::debug } {log local0. "Made it to iRule agent in perrequest policy with SLA value $sla."} ACCESS::perflow set perflow.custom "$sla" } } And this is how the Per Request Policy in the API Protection profile looks. It uses the value of the API Key (extracted with the help of the the iRule) and the Source IP of the client to enforce Rate Limiting on the POST endpoints, using two different SLAs. In the APM log you should see the following message, once the client exceeds his quota defined in the SLA. Apr 28 20:12:42 ltm-apm-16.mylab.local notice tmm[11094]: 01870075:5: (null):/Common: API request with weight (1) violated the quota in rate limiting config(/Common/demo_api_ratelimiting_auto_rate_limiting_standard). Apr 28 20:12:42 ltm-apm-16.mylab.local notice tmm[11094]: 0187008d:5: /Common/demo_api_ratelimiting_ap:Common:6600283561834577940: Execution of per request access policy (/Common/demo_api_ratelimiting_prp) done with ending type (Reject) Further reading: You can find a more detailed write-up on my GitHub page: https://github.com/webserverdude/f5_APM_API_Protection There you can find the Per Request Policy explained in all details. The Data Group with for the iRule. A demo API for testing my solution. A Postman Collection for working with my demo API.
Improve BIG-IP APM VPN speed with TLS dynamic record size
After successfully setting up BIG-IP APM network access, and running it for sometime, you may be looking for ways to optimize VPN speed for your users. This article discusses one way you can do that. Feature Description Beginning in BIG-IP 12.1.0, the Client SSL profile includes a feature that enables dynamic record size in TLS. When applied to a F5 BIG-IP Access Policy Manager (APM) network access VPN TLS virtual server, this can improve VPN speeds for your users. It has been found that certain protocols, notably HTTP, show better client response times using this method. For more information on the Allow Dynamic Record Sizing setting down to the packet level, refer to the following resources The About dynamic record sizing section of the BIG-IP System: SSL Administration manual. Boosting TLS Performance with Dynamic Record Sizing on BIG-IP on DevCentral. SSL Profiles Part 11: TLS Optimization on DevCentral. Important: Dynamic record size is a TLS enhancement and does not apply to BIG-IP APM network access DTLS virtual servers. Do not enable dynamic record size on DTLS. When you want to optimize network performance, you must allocate time to tune each configuration to match the requirements specific to your environment. Additionally, note that configuration changes that improve performance may increase BIG-IP system resource (CPU, memory) usage. Testing dynamic record size on VPN speeds Having discussed the theory behind the feature, we will now perform tests to see how it affects VPN speeds. Network bandwidth can vary depending on many factors, for instance, peak vs non-peak hours. When more users are connected to a VPN, download speeds can decrease significantly. It is therefore important to establish a baseline network bandwidth and download speed at the beginning: Baseline AWS environment Windows Client (Seattle) -- VPN --> BIG-IP APM (Oregon) --local LAN--> Apache and iperf servers AWS environment: BIG-IP APM 17.1.0 VE on AWS (F5 BIG-IP VE - ALL modules, m5.xlarge, 1 Gbps, AWS) located in us-west-2 Oregon. Note: Ensure you use at least the recommended size (m5.xlarge) and at least 1Gbps on AWS to make sure there are no bandwidth and resource limits. Windows client in located in Seattle Using iperf3 to measure network bandwidth Using curl to download a 377MB apmclient.iso Optional: You can optionally test using the developer tools on your browser. I used firefox; as the results did not differ significantly from curl. They are not included in this article. Baseline test results These are measured with all default settings on BIG-IP APM and dynamic record sizing not enabled: curl download results Average download speed: 4950k C:\Windows\system32>curl -k -o null https://10.0.128.23/apmclient.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 377M 100 377M 0 0 4950k 0 0:01:18 0:01:18 --:--:-- 4988k iperf3 results Network bandwidth: 4873 KB/sec c:\Users\klau\Desktop\iperf-3.1.3-win64>iperf3.exe -c 10.0.128.24 --get-server-output -i 1 -f K -R Connecting to host 10.0.128.24, port 5201 Reverse mode, remote host 10.0.128.24 is sending [ 4] local 10.0.128.31 port 61284 connected to 10.0.128.24 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 4.33 MBytes 4434 KBytes/sec [ 4] 1.00-2.00 sec 4.67 MBytes 4785 KBytes/sec [ 4] 2.00-3.00 sec 4.86 MBytes 4977 KBytes/sec [ 4] 3.00-4.00 sec 4.77 MBytes 4878 KBytes/sec [ 4] 4.00-5.00 sec 4.72 MBytes 4834 KBytes/sec [ 4] 5.00-6.00 sec 4.78 MBytes 4898 KBytes/sec [ 4] 6.00-7.00 sec 4.87 MBytes 4989 KBytes/sec [ 4] 7.00-8.00 sec 4.81 MBytes 4925 KBytes/sec [ 4] 8.00-9.00 sec 4.71 MBytes 4823 KBytes/sec [ 4] 9.00-10.00 sec 4.82 MBytes 4934 KBytes/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 48.0 MBytes 4919 KBytes/sec 9 sender [ 4] 0.00-10.00 sec 47.6 MBytes 4873 KBytes/sec receiver Server output: [...] [ 5] 0.00-10.04 sec 48.0 MBytes 4900 KBytes/sec 9 sender Test 1: Enabling dynamic record size from baseline Comparing with baseline results after enabling dynamic record size Baseline: Dynamic record size disabled dynamic record size enabled Percentage improvement curl average download, k 4950 5272 6.51% iperf3 network bandwidth, KBytes/sec 4873 5138 5.44% While this may not appear to be too high on the AWS cloud, there is also received feedback from customers that they see greater improvements in environments, especially in cases where the end-to-end latencies increase. Implementation strategy and recommendations As you plan to introduce this in your environment, take note of the following recommendations: Every environment is unique Many factors can affect network performance. This can range from VLAN settings (For example. MTU), TCP settings, intermediate network device throttling, and so on. You must perform testing in your own environment before enabling the feature. Implement the feature incrementally for a selected group of users. There are different ways to do this. For example, use an iRule to redirect users based on a URL, to a separate virtual server using a different Client SSL profile that has the feature enabled. Refer to SSL::allow_dynamic_record_sizing on Clouddocs. Monitor BIG-IP system logs and resource usage After you enable dynamic record size, make sure that your BIG-IP system continues to function as expected by monitoring the following monitor /var/log/ltm and /var/log/apm log files monitor BIG-IP CPU and memory usage. For example, you can select Dashboard on the Configuration utility, generating a QKview and analyze it in iHealth and so on. For more information, refer to K71764661: Understanding BIG-IP CPU usage and K16419: Overview of BIG-IP memory usage Verify and analyze SSL statistics Use the tmsh command in K41057430: Enhanced SSL profile statistics and check for failures. The SSL Dynamic Record Sizes section should also indicate use of large record sizes. Boosting TLS Performance with Dynamic Record Sizing on BIG-IP Conclusion There are a variety of different ways to improve VPN speeds, and this article describes just one. For other options and considerations, refer to K31143831: VPN for business continuity | Chapter 5: Optimizing Network Access VPN.APM Webtop SSL-VPN pop up customization
Hello all, I want to customize the pop up window used for webtop SSL-VPN and cannot found how. I am able to customize Webtop, Login & Logout page. Edge client too. But I found nothing about this pop up. I am using modern policy but this seems to use somehow the classic one as it has those diagonal stripes image background in header. Any ideas?
