Mitigating OWASP API Security Top 10 risks using F5 NGINX App Protect
This 2019 API Security article covers the summary of OWASP API Security Top 10 – 2019 categories and newly published 2023 API security article covered introductory part of newest edition of OWASP API Security Top 10 risks – 2023. We will deep-dive into some of those common risks and how we can protect our applications against these vulnerabilities using F5 NGINX App Protect. Excessive Data Exposure Problem Statement: As shown below in one of the demo application API’s, Personal Identifiable Information (PII) data, like Credit Card Numbers (CCN) and U.S. Social Security Numbers (SSN), are visible in responses that are highly sensitive. So, we must hide these details to prevent personal data exploits. Solution: To prevent this vulnerability, we will use the DataGuard feature in NGINX App Protect, which validates all response data for sensitive details and will either mask the data or block those requests, as per the configured settings. First, we will configure DataGuard to mask the PII data as shown below and will apply this configuration. Next, if we resend the same request, we can see that the CCN/SSN numbers are masked, thereby preventing data breaches. If needed, we can update configurations to block this vulnerability after which all incoming requests for this endpoint will be blocked. If you open the security log and filter with this support ID, we can see that the request is either blocked or PII data is masked, as per the DataGuard configuration applied in the above section. Injection Problem Statement: Customer login pages without secure coding practices may have flaws. Intruders could use those flaws to exploit credential validation using different types of injections, like SQLi, command injections, etc. In our demo application, we have found an exploit which allows us to bypass credential validation using SQL injection (by using username as “' OR true --” and any password), thereby getting administrative access, as below: Solution: NGINX App Protect has a database of signatures that match this type of SQLi attacks. By configuring the WAF policy in blocking mode, NGINX App Protect can identify and block this attack, as shown below. If you check in the security log with this support ID, we can see that request is blocked because of SQL injection risk, as below. Insufficient Logging & Monitoring Problem Statement: Appropriate logging and monitoring solutions play a pivotal role in identifying attacks and also in finding the root cause for any security issues. Without these solutions, applications are fully exposed to attackers and SecOps is completely blind to identifying details of users and resources being accessed. Solution: NGINX provides different options to track logging details of applications for end-to-end visibility of every request both from a security and performance perspective. Users can change configurations as per their requirements and can also configure different logging mechanisms with different levels. Check the links below for more details on logging: https://www.nginx.com/blog/logging-upstream-nginx-traffic-cdn77/ https://www.nginx.com/blog/modsecurity-logging-and-debugging/ https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/ https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ https://docs.nginx.com/nginx-app-protect-waf/logging-overview/logs-overview/ Unrestricted Access to Sensitive Business Flows Problem Statement: By using the power of automation tools, attackers can now break through tough levels of protection. The inefficiency of APIs to detect automated bot tools not only causes business loss, but it can also adversely impact the services for genuine users of an application. Solution: NGINX App Protect has the best-in-class bot detection technology and can detect and label automation tools in different categories, like trusted, untrusted, and unknown. Depending on the appropriate configurations applied in the policy, requests generated from these tools are either blocked or alerted. Below is an example that shows how requests generated from the Postman automation tool are getting blocked. By filtering the security log with this support-id, we can see that the request is blocked because of an untrusted bot. Lack of Resources & Rate Limiting Problem Statement: APIs do not have any restrictions on the size or number of resources that can be requested by the end user. Above mentioned scenarios sometimes lead to poor API server performance, Denial of Service (DoS), and brute force attacks. Solution: NGINX App Protect provides different ways to rate limit the requests as per user requirements. A simple rate limiting use case configuration is able to block requests after reaching the limit, which is demonstrated below. Conclusion: In short, this article covered some common API vulnerabilities and shows how NGINX App Protect can be used as a mitigation solution to prevent these OWASP API security risks. Related resources for more information or to get started: F5 NGINX App Protect OWASP API Security Top 10 2019 OWASP API Security Top 10 2023
API Security: How to implement API Access Control with F5
Per Gartner, API Security comprises two aspects: API Threat Protection and API Access Control. API Threat Protection is addressed with measures such as API L7 firewall, bot protection, DDoS mitigation, etc. API Access Control is most comprehensively addressed via OAuth 2.0. This article will see our attention focused on API Access Control, and how F5 APM can be leverage for this universal challenge when protecting API.Mitigating OWASP Web Application Security Top 10 – 2021 risks using F5 Distributed Cloud Platform
Overview: In the early 90’s, applications were in dormant phase and JavaScript & XML were dominating this technology. But in 1999, the first web application was introduced after the release of the Java language in 1995. Later with the adoption of new languages like Ajax, HTML, Node, Angular, SQL, Go, Python, etc. and availability of web application frameworks have boosted application development, deployment, and release to production. With the evolving software technologies, modern web applications are becoming more and more innovative, providing users with a grand new experience and ridiculously ease of interface. With these leading-edge technologies, novel exploit surfaces are also exposed which made them a primary target for intruders/hackers. Application safeguarding against all these common exploits is a necessary step in protecting backend application data. Open Worldwide Application Security Project (OWASP) is one of those security practices which protects application with above issues. This article is the first part of the series and covers OWASP evolution, its importance and overview of top 10 categories. Before diving into OWASP Web Application Security Top 10, let’s time travel to era of 1990’s and try to identify challenges the application customers, developers and users were facing. Below are some of them: Rapid and diversified cyber-attacks has become a major concern and monitoring/categorizing them was difficult Product owners are concerned about application security & availability and are in desperate need of a checklist/report to understand their application security posture Developers are looking for recommendations to securely develop code before running into security flaws in production No consolidated repo to manage, document and provide research insights for every security vulnerability After running into the above concerns, people across the globe have come together in 2001 and formed an international open-source community OWASP. It’s a non-profit foundation which has people from different backgrounds like developers, evangelist, security experts, etc. The main agenda for this community is to solve application related issues by providing: Regularly updating “OWASP TOP 10” report which provides insights of latest top 10 security issues in web applications Report also provides security recommendations to protect them from these issues Consolidated monitoring and tracking of application vulnerabilities Conducting events, trainings and conferences around the world to discuss, solve and provide preventive recommendations for latest security issues OWASP also provides security tools, research papers, libraries, cheat sheets, books, presentations and videos covering application security testing, secure development, and secure code review OWASP WEB SECURITY TOP 10 2021: With the rapid increase of cyber-attacks and because of dynamic report updates, OWASP gained immense popularity and is considered as one of the top security aspects which application companies are following to protect their modern applications against known security issues. Periodically they release their Top 10 vulnerabilities report and below are the latest Top 10 - 2021 categories with their summary: A01:2021-Broken Access Control Access controls enforce policy such that users cannot act outside of their intended permissions. Also called authorization, it allows or denies access to your application's features and resources. Misuse of access control enables unauthorized access to sensitive information, privilege escalation and illegal file executions. Check this article on protection against broken access vulnerabilities A02:2021-Cryptographic Failures In 2017 OWASP top 10 report, this attack was known as Sensitive Data Exposure, which focuses on failures related to cryptography leading to exposure of sensitive data. Check this article on cryptographic failures A03:2021-Injection An application is vulnerable to injection if user data and schema is not validated by the application. Some of the common injections are XSS, SQL, NoSQL, OS command, Object Relational Mapping (ORM), etc., causing data breaches and loss of revenue. Check this article on safeguarding against injection exploits A04:2021-Insecure Design During the development cycle, some phases might be reduced in scope which leads to some of the vulnerabilities. Insecure Design represents the weaknesses i.e., lack of security controls which are not tracked in other categories throughout the development cycle. Check this article on design flaws and mitigation A05:2021-Security Misconfiguration This occurs when security best practices are overlooked allowing attackers to get into the system utilizing the loopholes. XML External Entities (XXE), which was previously a Top 10 category, is now a part of security misconfiguration. Check this article on protection against misconfiguration vulnerabilities A06:2021-Vulnerable and Outdated Components Applications used in enterprises are prone to threats such as code injection, buffer overflow, command injection and cross-site scripting from unsupported, out of date open-source components and known exploited vulnerabilities. Utilizing components with security issues makes the application itself vulnerable. Intruders will take use of this defects and exploit the deprecated packages thereby gaining access to backend applications. Check this article on finding outdated components A07:2021-Identification and Authentication Failures Confirmation of the user's identity, authentication, authorization and session management is critical to protect applications against authentication-related attacks. Apps without valid authorization, use of default credentials and unable to detect bot traffic are some of the scenarios in this category. Check this article on identifying and protection against bots A08:2021-Software and Data Integrity Failures Software and data integrity failures occurs when updates are pushed to the deployment pipeline without verifying its integrity. Insecure Deserialization, which was a separate category in OWASP 2017, has now become a part of this larger category set. Check this article on software failures protection A09:2021-Security Logging and Monitoring Failures As a best recommendation, we shall always log all incoming request details and monitor application for fraudulent transactions, invalid logins, etc. to identify if there are any attacks or breaches. Applications without logging capabilities provide opportunities to the attackers to exploit the application and may lead to many security concerns. Without logging and monitoring we won’t be able to validate the application traffic and can’t identify the source of the breach. Check this article for identifying logging issues A10:2021-Server-Side Request Forgery Server-Side Request Forgery (SSRF) attack is a technique which allows intruders to manipulate the server-side application vulnerability and make a malicious request to the internal-only resources. Attacker exploits this flaw by modifying/crafting a URL which forces the server to retrieve and disclose sensitive information. Check this article which focusses on SSRF mitigation NOTE: This is an overview article of this OWASP series, check the below links to prevent these vulnerabilities using F5 Distributed Cloud Platform. OWASP Web Application Security Series: Broken access mitigation Cryptographic failures Injection mitigation Insecure design mitigation Security misconfiguration prevention Vulnerable and outdated components Identification failures prevention Software failures mitigation Security logging issues prevention SSRF MitigationHow I did it - “Delivering Kasm Workspaces three ways”
Securing modern, containerized platforms like Kasm Workspaces requires a robust and multi-faceted approach to ensure performance, reliability, and data protection. In this edition of "How I did it" we'll see how F5 technologies can enhance the security and scalability of Kasm Workspaces deployments.F5 Distributed Cloud JA4 detection for enhanced performance and detection
JA4+ is a suite of network fingerprinting methods. These methods are both human and machine readable to facilitate more effective threat-hunting and analysis. The use cases for these fingerprints include scanning for threat actors, malware detection, session hijacking prevention, compliance automation, location tracking, DDoS detection, grouping of threat actors, reverse shell detection, and many more. Introduction In a previous article, Identity-Aware decisions with JA4+ we discussed using JA4 fingerprints with BIG-IP. In this article, we are exploring the use of JA4 in F5 Distributed Cloud. A very useful use case for using JA4 in F5 Distributed Cloud is explained at F5 App Connect and NetApp S3 Storage – Secured Scalable AI RAG. Let's go through the steps of getting the JA4 fingerprints applied to a traffic sample. Implementation In this example we are using NGINX instance deployed via F5 Distributed Cloud Distributed Apps. Deploy Virtual K8s through Distributed Apps. Create service policy with the matching JA4 fingerprints to block. JA4 Database can be found over here JA4 Database Service policy creation From Distributed Cloud UI > Distributed Apps > Manage > Service Policies > Service Policies Add Service Policy Add name: ja4-service-policy Under rules, select Custom rules and then click configure Click Add item Update the below, Add name, Actions. Show advanced fields in the client section. TLS Fingerprint Matcher: JA4 TLS Fingerprint Click Configure JA4 TLS Fingerprint Click Add item and match the needed JA4 fingerprint. In our case, we are blocking curl, wget fingerprints. Click Apply, to save, then Save, and Exit. Now, we attach the service policy to our HTTP Load balancer. Manage > HTTP Loadbalancer > Click Manage configurations Click Edit Configurations At Common Security Controls section, Select Apply Service Policies and click Edit Configurations. Select the configured policy, then Apply. Testing From Firefox browser From Ubuntu using curl Observing logs from F5 Distributed Cloud From HTTP Loadbalancers > select the created loadbalancer and click Security Monitoring Click Security Events to check the requests You can see the events with the requests and client information From Action column, you can select Explain with AI to gain further information and recommendations. We have the service policy configured and attached. It can be attached as well to different component for client identification as well. Related Content F5 App Connect and NetApp S3 Storage – Secured Scalable AI RAG | DevCentral Fingerprint TLS Clients with JA4 on F5 BIG-IP using iRules JA4 Part 2: Detecting and Mitigating Based on Dynamic JA4 Reputation | DevCentral Identity-Aware decisions with JA4+ | DevCentral Setting Up A Basic Customer Edge To Run vk8s in F5 Distributed Cloud App Stack | DevCentralMitigating OWASP Web Application Risk: Broken Access attacks using F5 Distributed Cloud Platform
This article is in continuation of the owasp series and will cover broken access control.Check here for overview article. Introduction to Broken Access Control attack: Access controls enforces policy such that users cannot act outside of their intended permissions. Also called authorization, allows or denies access to your application's features and resources. Misuse of access control enables: Unauthorized access to sensitive information. Privilege escalation. Illegal file executions. There are many ways to infiltrate application servers using broken access controls and we are going to focus on the 2 scenarios below and how to mitigate them. Scenario 1: Broken access + SQL injection attack Instead of logging with valid credentials,attacker uses SQL injection attacks to login as another standard or higher privileged user, like admin.We can also say this is broken authentication, because an attacker authenticated to a system using injection attack without providing valid credentials. For this demo I am using OWASP Juice shop (reference links at bottom for more info). Step1: Please follow steps suggested in Article1 to configure HTTP load balancer and WAF in cloud console. Make sure WAF is configured in Monitoring mode to generate the attack. Step2: Open a browser and navigate to the login page of the application load balancer. In the Email field provide “' OR true --” and any password as below: Step3: Validate you can login to application as administrator as below: Scenario2: File upload vulnerability Any file which has the capability to harm the server is a malicious file.For example, a php file which has some dangerous php functions like exec () can be considered as a malicious file as these functions can execute OS command and can remotely provide us the control of the application server. Suppose there is a file upload functionality in the web application and only jpeg extension file is allowed to be uploaded. Failing to properly enforce access restrictions on file properties can lead to broken access control attacks providing attackers a way to upload potentially dangerous files with different extensions.For this demo I am using DVWA as the vulnerable testing application (reference links at bottom for more info). Step by step process: Step1: Open a notepad editor and paste below contents and save to desktop as malicious.php Step2: Open a browser and navigate to the application load balancer URL. Login to DVWA application using admin/password as the credentials. Click on “File Upload” option in left side of the menu section. Step3: This page is used to upload images with extensions .jpeg, .png, .gif etc. But this demo application doesn’t have file restrictions enabled making attackers to upload any file extensions. Click on “Choose File” button and upload above created .php file. Step4: Note the location displayed in the message, open the URL in the browser and validate we can see all the users available as below. NOTE: Since this is just a demo environment, I'm using same F5 Distributed Cloud load balancer for both the demo applications by changing the IP and ports in F5 Distributed Cloud Origin pool as per my needs. That's why you can see both apps are accessible using juiceshop domain. Solution: To mitigatethese attacks, navigate to Firewall section and in “App Firewall” configuration make sure “Enforcement Mode” is set to “Blocking” as below: Next in browser try to generate above scenarios and validate your request is blocked as below. Login Mitigation: Illegal File Upload mitigation: Illegal File Execution mitigations: In Distributed Cloud Console expand the security event and check the WAF section to understand the reason why request was blocked. Conclusion: As shown above, OWASP Top 10: Broken access control attacks can be mitigated by configuring WAF firewall in “Blocking” mode. For further information click the links below: OWASP - Broken access control File Upload Vulnerability OWASP Juice Shop DVWASecuring Model Serving in Red Hat OpenShift AI (on ROSA) with F5 Distributed Cloud API Security
Learn how Red Hat OpenShift AI on ROSA and F5 Distributed Cloud API Security work together to protect generative AI model inference endpoints. This integration ensures robust API discovery, schema enforcement, LLM-aware threat detection, bot mitigation, sensitive data redaction, and continuous observability—enabling secure, compliant, and high-performance AI-driven experiences at scale.AI Security - LLM-DOS, and predictions of 2025 and beyond
Introduction Hello again, this article is part of AI security series. I have been discussing AI security along with theOWASP LLM top10. LLM01 and LLM02 were discussed in the "AI Security : Prompt Injection and Insecure Output Handling", and LLM03 and its basic concepts were discussed in the "Using ChatGPT for security and introduction of AI security". In this article, I am going to discuss LLM04. And, since we are almost at the end of the year 2024, I would like to present some discussions and predictions for AI security in 2025 and beyond. LLM04: Model Denial of Service LLM04 is relatively easy to understand for security engineers who is familiar with conventional cyber attack methods. Denial of Service (DoS) is a common method of cyber attack, in which a large amount of data is given to the server to make it unable to provide services and/or crash. DoS attacks usually aim to exhaust computational resources and block services rather than stealing data, but the disruption they cause can be used as a smokescreen for more malicious activities, such as data breaches or malware installation. DOS attack against LLM (LLM-DOS) is same. It aims to exhaust computational resources of DOS (like CPU/GPU usage) and block services (like responding to chat). LLM-DOS can be done in two ways. One is a simple LLM-DOS attack which is to mass input against the LLM's input, similar to a DOS attack against a server. This method, as described in this article, can deplete the LLM's resources, like CPU/GPU usages. If you call this as a simple DoS attack, in such a scenario would be to instruct the model to keep repeating Hello, but we see that relying only on natural instructions limits the output length, which is limited by the maximum length of the LLM's Supervised Fine-Tuning (SFT) data The another method of LLM-DOS is to include code in the input that over-consumes resources.Denial-of-Service Poisoning Attacks on Large Language Models is discussing this. In the paper, this is called as a poisoning-based DoS (P-DoS) attack and it demonstrates that the output length limit can be broken by injecting a single poisoning sample designed for DoS purposes. Experiments reveal that an attacker can easily compromise models such as GPT-4o and GPT-4o mini by injecting a single poisoning sample through the OpenAI API at a minimal cost of less than $1. To understand this, it is easier to think about simple programming - for example, if you put an inescapable loop statement in your code, it can hang the computer (in fact, the IDE will warn you before it compiles). And if the network does not have a Spanning Tree Protocol, it will loop and hang the router. So same things happens on prompt injection. When using this idea LLLM-DOS, we must consider that such input should be blacklisted, so the simple way of using inescapable loop is impossible. Also, even if it is possible against WhiteBox, but we do not know what kind of attack is possible in BlackBox. However, according to "Crabs: Consuming Resource via Auto-generation for LLM-DoS Attack under Black-box Settings", a Prompt input to the BlackBox can generate multiple sub-prompts (e.g., 25 sub-prompts). Its experiments show that the delay could be increased by a factor of 250. Given these serious safety concerns, researchers advocate further research aimed at defending against LLM-DoS threats in custom fine tuning of aligned LLMs. What will happen in 2025 and beyond? Some news site predicts an intensifying AI arms race in coming year. I would like to share an article on AI security predictions for the coming year and beyond. According to an article by EG Secure solutions, the generative AI makes it possible to create a malware without specialized skills, that makes easier to do cyber attacks. Thus, the article predicted that cyber attacks by malware created by generative AI would increase. The article also points out that LLM-generated applications such as RAGs are being used, but their code may contain vulnerabilities, and that will be another threat in 2025 and beyond. McAfee has released "McAfee Unveils 2025 Cybersecurity Predictions: AI-Powered Scams and Emerging Digital Threats Take Center Stage". According to the article, cyber attacks by malicious attackers will be highly optimized by generative AI, and the quality of DeepFake and AI-generated images/videos will increase, making it difficult to determine whether they are created by humans or generative AI. Thus it is expected that fake emails generated by generative AI, such as phishing emails, will also become harder to distinguish from real emails. Furthermore, the article points out that malware which is using (maybe created by) generative AI will become more sophisticated, thereby breaking through conventional security defense systems and may succeed to extracting personal information and sensitive data. Finally, the "Infosec experts divided on AI's potential to assist red teams" discusses the pros and cons of using generative AI for red teaming, one type of security audit. According to the article, the benefit of using generative AI is that it accelerates threat detection by allowing AI to scour multiple data feeds, applications, and other sources of performance data and run them as part of a larger automated workflow. On the other hand, the article also argues that using generative AI for red teaming is still limited, because the vulnerability discovery process by AI is a black box so the pen-tester cannot explain how they discovered to their clients.APM Advanced Customization Examples with Modern Template, v15.1+
Introduction This guide will walk through how the logon, webtop, and other UI pages are created by APM, how it works, and some examples.The new APM modern template has an updated look in both mobile and desktop browsers. It uses the popular Preact framework to provide a consistent and familiar end user experience. How to activate the new customization system New policies created in 15.1 and later default to the new Modern template. Existing policies made before 15.1 continue to use the Standard template. When creating a new access policy: You can see the customization types applied to all access policies in the Per-Session access policy menu: Customization Sections Basic, General, and Advanced Customization APM has different ways to customize, depending on the desired complexity. Some administrators simply want to change colors, while others would prefer to completely rewrite the APM user-facing HTML and CSS so they have similar branding to other corporate web properties. As is typical with CSS, style customizations can be applied simultaneously with later style changes overriding earlier ones. Basic Customization Simple customization settings such as images, titles, captions, and colors are applied to resources and policies using Basic Customization. The tables and screenshot below detail the settings. Elements in Basic Customization Header/Footer/Title Header Image for Desktop (Max height: 60px) Header Image for Mobile (Max height: 30px) Layout Settings Maximum viewport width for applying small (mobile) screen styles (px) Browser width for mobile clients Minimum viewport width for applying large (desktop) screen styles (px) Browser width for desktop clients Colors (see image for sections) Active Links and Buttons Color Footer Background Color Form Background Color Header Color Page Background Color Solid Button Text Color Text Color Top Strip Color General Customization General Customization offers a more advanced tree view of the Basic Customization settings as well as text options for user-facing messages. Like Basic customization, the settings are applied individually to each access policy and policy item via the item’s XML file specified in the cache-pathparameter of the associated customization group configuration object. To use General Customization Create the policies and/or resources you would like to customize. Find them in the tree view. Make the changes. Perform the standard 3-step save process: Save Draft, Save, then Apply the access policy. You use General Customization to apply changes to the informational text strings and error messages that are displayed to users. Browse the configuration tree to see the available customization areas. The settings are divided into Branding and Text. Text are the localized messages that are displayed to the end users, including associated HTML. User-facing status and text messages can be selected in the Text tab.Branding options are about page styling, colors, fonts, and the like. These are selected in the Branding tab. Special General Options APM customization has a few non-branding and non-text special options in the configuration tree. Disable all external scripts and styles The new Modern customization includes a new resource loader feature. This feature loads all added CSS and JS resources dynamically, including 3 rd party external code. You use this option like a “Revert” to restore the default branding in case there is some unknown trouble. If enabled, it disables loading of all external CSS and JS, including the APM-hosted user-XXXX.js and user-XXXX.css files. External Javascript / CSS You can now easily add external javascript references, for libraries such as JQuery that you wouldlike your users to load from an external CDN. Historically this would present a security problem because the CDN content may be vulnerable to malicious injection. APM uses the W3C subresource integrity feature(https://www.w3.org/TR/SRI/) mechanism to ensure that the external files are not tampered. You can also specify external scripts manually in user-XXXX.js, but using the inbuilt APM script-loader mechanism allows us to trap loading errors and disable all external scripts globally, in case of any problems (see the previous section). To use this feature: Find the checksum* and URL of your resource. jQuery makes this very simple: It’s directly on their CDN page. Alternatively, you can compute them using srihash.org. Place the values into External Scripts / Styles. Save, Apply the access policy, and visit the access policy virtual. *Note*: APM’s end-user pages are built using Preactwith built-in libraries, so don't load another copy of Preact using this mechanism. See the Advanced Examples section below for usage ideas. If the checksum is incorrect the stock APM javascript will function correctly, but the external resource will not be loaded and the browser will produce a “Failed to find a valid digest in the integrity attribute for resource ‘xxxxxx’” error in the console similar to this screenshot: * Supported checksum mechanisms are SHA-256, SHA-384, or SHA-512. Advanced Customization Use Advanced Customization to edit or place code directly into the files that are referenced from the primary APM user-facing HTML. Common settings are available which load on all pages, along with separate CSS and JS for each policy item that is present in the policy. Generally, the CSS/JS for each policy item load after the common settings so later settings will override earlier ones. You must first add policy items to customize before customizing them. This is a customization tree view before and after adding Logon Page to access policy: Before After Operation of Advanced Customization With Advanced Customization, you can do essentially any styling you want using standard CSS. Advanced Customization has some common settings, agent settings, and some special settings. After making any change, Save Draft, then Save., then Apply the access policy. Common settings These two files (user-common.css and user-common.js) are loaded on all* APM user-facing pages, including policy evaluation (logon, message, etc), webtop, and logout. Use these if you want to change a page style in all areas. For example, perhaps we always want to hide the header and footer and add a background image. To do that, we can simply add some CSS to user-common.css to set a few properties targeting the apmui-header, apmui-main, and apmui-footer CSS selectors. Example: logon page customization Hide header and footer, and add a picture: *Note*: You should usually make logon-specific changes on the logon page rather than “common”, since the webtop places some GUI links in apmui-header. Hiding the header removes access to these links! You can useuser-common.jsto load a tracker such as Google Analytics. Example: Google Analytics Customization Types There are two broad categories for the customization of APM objects: Resources areAssigned during per-session access policy execution. They include customizable icons, captions, and descriptions that are visible on the APM full webtop (sometimes called a portal). OAuth Client App OAuth Scope App Tunnel Network Access Remote Desktop SAML Web App (Portal Access) Webtop Link Webtop Section Non-Resourceseach have different configuration properties General Framework Installation EPS Logout (Ending Denied) Error message Decision Box Confirm/Continue Ending Denied Message Box Oauth Authz Webtop Screenshots *Example*: Simple resource customization of a webtop link resource End-User view from APM webtop: Troubleshooting Tips: Configuration Structure Resource customization settings, text strings, and image files are stored as interdependent configuration and file objects. When troubleshooting, check the following configuration areas. This diagram represents the dependencies: This table represents the item details, and troubleshooting tips: NOTE: To create resource customization using scripting or automation, they must be created all at once using a TMSH transaction rather than individually because of the interdependency between resources, profiles, policies, policy items, agents, and customization groups. To get started, use the GUI to create a policy you like, then review the configuration objects defined in tmsh list apm.The objects inter-referred-to must be copied into a transaction. equivalent create apm xxxx commands inside of a transaction. For detail on transactions with APM policies, see tmsh help apm policy access-policy tmsh help cli transaction HTML Rendering Details Access profiles, Per Request Policies and other objects (customized independently from an access profile) share similar syntaxand structure. Each object has customization settings. Access Profiles have multiple groups of customization settings. Every time you change customization, it generates a set of files that are combined to form the user-displayed page. Settings (color, font, text, and so on) for the header and footer can be defined in access profile customization. Settings for the location and alignment of the content area can also be defined in access profile customization. Settings forresourcesdisplayed in the APM Webtop can be defined in the resource's configuration area (see payroll example above). APM Sandbox / Image Hosting To place images or other files in APM for convenient access by end users, use the Hosted Content feature. On a BIG-IP system, on the Main tab, clickAccess > Webtops > Hosted Content > Manage Files. Upload an image file. Click Upload >> Manage Access, and make sure the checkbox for your access policy attached to the virtual server is selected. Access the file at the location indicated in thePublicly Accessible URIcolumn. General Examples Execute external javascript code after Logon Page browser rendering is complete. This example can be placed into user-logon.js to use the D3 library to display a small pop-up message. Additional code can be inserted for custom functions. define(["require", "exports", "tslib", "module", "apmui/page/logon/View"], function (require, exports, tslib_1, module, View_1) { "use strict"; Object.defineProperty(exports, "__esModule", { value: true }); requirejs.config({ map: { 'apmui/master/View': { 'apmui/page/logon/View': module.id, }, }, }); /* Replacement View component */ var CustomLogonView = /** @class */ (function (_super) { tslib_1.__extends(CustomLogonView, _super); function CustomLogonView() { return _super !== null && _super.apply(this, arguments) || this; } CustomLogonView.prototype.componentDidMount = function () { _super.prototype.componentDidMount.call(this); requirejs(['https://d3js.org/d3.v6.min.js'], function (d3) { // Place your code inside this function d3.select("form").append("span") .text("Hello from D3 library"); }); }; return CustomLogonView; }(View_1.default)); exports.default = CustomLogonView; }); Execute local javascript code inside Logon Page. This example can be placed into user-logon.js to perform custom actions. define(["require", "exports", "tslib", "module", "apmui/page/logon/View"], function (require, exports, tslib_1, module, View_1) { "use strict"; Object.defineProperty(exports, "__esModule", { value: true }); requirejs.config({ map: { 'apmui/master/View': { 'apmui/page/logon/View': module.id, }, }, }); /* Replacement View component */ var CustomLogonView = /** @class */ (function (_super) { tslib_1.__extends(CustomLogonView, _super); function CustomLogonView() { return _super !== null && _super.apply(this, arguments) || this; } CustomLogonView.prototype.componentDidMount = function () { _super.prototype.componentDidMount.call(this); alert('PLACE CUSTOM CODE HERE'); }; return CustomLogonView; }(View_1.default)); exports.default = CustomLogonView; }); Advanced Examples These use TypeScript and preact You should be familiar with these technologies and their usage. To use these examples, you need a standard TypeScript/NodeJS+NPM build environment. This can be most easily achieved by using Linux, Microsoft Windows Subsystem for Linux (WSL), or Mac, then installing NodeJS which includes NPM. The examples are attached to this article as a ZIP archive. Download and decompress this file to a suitable location on your workstation. Read README.md from the package. Each example here assumes you have already downloaded the package and run npm install; npm run build. The compilation result is placed in the dist directory. For each one of the examples, you simply copy the user-xxxx.css and user-xxxx.js files into the correct object in Advanced Customization. To make changes to these examples, modify the files in src, then npm run build, as specified in README.md. Example 1: Decision box with more options By default, the APM Decision Box has only two choices. We can use this advanced customization example to append additional choices. Follow this procedure: Add a decision box to your access policy. Navigate to customization-examples/dist/decisionBox-more-options and copy the contents of user-decision.js to the appropriate area in Advanced Customization. Click Save Draft, Save, and apply the access policy. As a user, navigate to the decision box on the APM virtual server. Now the decision box has 4 options rather than two. The option and icon detail are in the example user-decision.ts source file: The result: value is the raw POST data, which is transferred from the client browser when the my.policy page is submitted. It must match an agent expression in the branch rules defined for the decision box object. As with all other agents, the branch rules must be defined in the policy-item configuration so that the additional branches are available in the VPE for use: Once these additional branch rules are defined, they can be added to the VPE flow: When a user makes a choice, it appears in log files thusly: To host your own icons, you can use the APM sandbox hosting feature, discussed elsewhere in this doc. Example 2: Logon box custom component This example adds a custom Preactcomponent to the Logon Box. Add a Logon Page to your access policy, then copy the example dist code into your user-logon.js and user-logon.css files. Output: Example 3: Logon custom view This is an example of how to obtain a JSON-formatted dump of data available programmatically. Add the code from logon-custom-view to your APM policy files, then visit the APM virtual. You will see JSON data that provides the detailed data available. Example 4: PIN Pad replaces standard forms logon page This is an example of an alternative method of rendering a standard forms logon page with a polymorphic virtual PIN pad. It uses Preactand CSS to achieve this result. Note: A similar result with a virtual keyboard is possible as well, using other modules available via npm. This requires Preactdevelopment. As with the other examples, compile the TypeScript and place the dist’s user-logon.css and user-logon.js into the APM’s advanced customization area for your logon agent. The result when visiting this logon page is illustrated in this screenshot: Example 5: Validation of input fields logon-validate-domain contains a sample that has an example of input field validation: The input validation logic can be changed with the following TypeScript: This kind of validation logic can be extended for almost any purpose. Example 6: Pin resource to top of webtop Recently-used-resources implements a mechanism that uses local storage to track how many times a resource has been clicked. It also creates a new webtop section that displays most-clicked-on resources. You must have a full webtop and multiple resources assigned to the user (any type is fine). Use this example like the others: Copy the dist directory files user-webtop.css and user-webtop.js to the advanced customization object and click Save Draft, then Save, and apply the access policy. Note that you may have to clear BIG-IP or browser cache to see the update. Take a few minutes to examine the browser's Local Storage contents while clicking various favorites assigned to the user. Example 7: Pin resources on full webtop Most application portals offer some kind of system to save often-used resources at the top of the list. This example uses HTML5 Browser Local Storage to save the user’s resources and render them at the top of the webtop application portal. You must assign a full webtop and multiple resources to the user. Use this example like the others: Copy the dist directory files user-webtop.css and user-webtop.js to the advanced customization object and click Save Draft, then Save, and apply the access policy. Note that you may have to clear BIG-IP or browser cache to see the update. Afterwards, logon as a user to the webtop and click the corner pin icon to add the resource to Pinned Resources. Try to log out and back in and see that the resource(s) are saved. Check the browser developer tools to query the local storage contents. Examples Conclusion We hope these examples are helpful to performing customization of APM web pages. Please let us know of any further examples that you would like to share! Request For Examples We have received the following requests for examples and hope to add these soon. Let us know if you can contribute! Simplest way to add an HTML link and text into the logon page Simplest way to add a select box to a logon page Example virtual keyboard logon page Attributions / Licensing / Support Status Support Status: F5 Support cannot provide assistance with TypeScript, JavaScript, or Preactcoding or web development. To validate the operation of any of these examples, standard web development practices should be used. F5 code: These examples include code produced by F5 intended to showcase the possibilities of the v15.1.0 APM customization system and can be used by any APM customer. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 3 rd Party Code: As with most open source software, each module in this example includes a separate license (MIT, CC, etc). Before using any of these in a production environment, please review the licensing requirements for each NPM package in node_modules. Media: Beach scene used in customization examples:Stones in the Beach By Xavierfsc - Own work, CC BY 4.0, https://commons.wikimedia.org/w/index.php?curid=84430607
