OWASP Tactical Access Defense Series: Broken Object Property Level Authorization and BIG-IP APM
AUTHOR NOTE: Unauthorized access to private/sensitive object properties may result in data disclosure, data loss, or data corruption. Under certain circumstances, unauthorized access to object properties can lead to privilege escalation or partial/full account takeover. In this article we are going through API3 item from OWASP top 10 API Security risks exploring BIG-IP Access Policy Manager (APM) role in our arsenal. Identifying Vulnerable APIs In order to identify the API endpoint is vulnerable to Broken Object Property Level Authorization, Sensitive properties exposure of certain object for non-intended user (Excessive Data Exposure). import requests # Assuming the API endpoint for retrieving user data is /api/users api_endpoint = "https://example.com/api/users" # Sending a GET request to the API endpoint response = requests.get(api_endpoint) # Checking if the request was successful (status code 200) if response.status_code == 200: # Printing the response content (which could contain excessive data) print(response.json()) else: print("Failed to retrieve data from the API") API allow to change, add or delete sensitive object property for non-intended user (Mass assignment). import requests # Assuming the API endpoint for updating user information is /api/users api_endpoint = "https://example.com/api/users" # Malicious payload containing additional fields malicious_payload = { "username": "malicious_user", "password": "password123", "isAdmin": True # Malicious user attempts to elevate privileges } # Sending a POST request with the malicious payload response = requests.post(api_endpoint, json=malicious_payload) # Checking if the request was successful (status code 200) if response.status_code == 200: print("User information updated successfully") else: print("Failed to update user information") Object Property Level Authorization involves controlling access to specific properties or attributes of an object within a system. Instead of granting blanket access to an entire object, this approach enables fine-grained control, allowing administrators to restrict or permit access to individual properties based on user roles or permissions. While implementing protection against such security risk involves different aspects, one is making sure the user is authorized to access object property, and here BIG-IP APM plays crucial role. Mitigating Risks with BIG-IP APM BIG-IP APM per-request granularity. With per-request granularity, organizations can dynamically enforce access policies based on various factors such as user identity, device characteristics, and contextual information. This enables organizations to implement fine-grained access controls at the API level, mitigating the risks associated with Broken Object Property Level Authorization. Key Features: Dynamic Access Control Policies: BIG-IP APM empowers organizations to define dynamic access control policies that adapt to changing conditions in real-time. By evaluating each API request against these policies, BIG-IP APM ensures that only authorized users can access specific resources and perform permitted actions. Granular Authorization Rules: BIG-IP APM enables organizations to define granular authorization rules that govern access to individual objects or resources within the API ecosystem. By enforcing strict authorization checks at the object level, F5 APM prevents unauthorized users from tampering with sensitive data or performing unauthorized actions. Conclusion In conclusion, BIG-IP APM per-request granularity is a powerful tool for defending against Broken Object-Level Authorization vulnerabilities in APIs. By enforcing fine-grained access controls at the API level, organizations can mitigate the risks associated with unauthorized access to sensitive data. Additionally, proactive security assessments and vulnerability scans are essential for identifying and addressing vulnerabilities in APIs, thereby strengthening overall security posture in the digital ecosystem. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller) OWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APMOWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APM
The threat of broken authentication poses a significant risk to organizations, potentially leading to unauthorized access and data breaches. In the face of this formidable challenge, F5's Access Policy Manager (APM) emerges as a robust and indispensable solution. By seamlessly integrating advanced authentication mechanisms and comprehensive access controls, F5 BIG-IP APM stands as a stalwart guardian against the vulnerabilities associated with broken authentication. This article explores the pivotal role played by BIG-IP APM in fortifying authentication protocols, mitigating risks, and ensuring a resilient defense against unauthorized access, ultimately safeguarding the integrity and security of sensitive data in today's dynamic digital environment. Broken Authentication Broken Authentication Examples BIG-IP APM and Broken Authentication Related Content Broken Authentication Authentication mechanism is an exposed target due to the nature of this function, as authentication is the first point of entry to any platform. The difficulty to exploit authentication weaknesses differs based on how the authentication platform is secured. In the current digital era the security perimeters are very fluid, and so are the trust boundries for our authentication platforms those require more cautions from the developers and security architects regarding authentication flows. Not only we need to protect authentication endpoints and flows, but also some overlooked items like forget and reset password endpoints. How can we consider endpoint to be vulnerable? Credential stuffing. Brute force attacks targetting users' accounts. Weak Passwords. Sensitive details in the URL (passwords, Tokens). Allow users sensitive actions without confirmation. No validation for the tokens authenticity. Accept unsigned or weak jwt tokens. No validation for jwt expiration. Use of plain-text, non-encrypted or non-hashed passwords. Use of weak encryption algorithms. Endpoint can access each other without proper authentication. Use weak or predictable tokens for intra-endpoint authentication. Broken Authentication Examples Making use of GraphQL query patching to bypass API ratelimiting and brute force user's login. POST /graphql [ {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, ... {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, ] Update / modify user's sensitive information without API authorization token. PUT /account Authorization: Bearer <token> { "newpassword": "<new_password>" } BIG-IP APM and Broken Authentication We start with creating our Per-Request policy, this policy works in a different way than the per-session policy, as the flow will be evaluted on a per-request basis, making sure to consider variations throught the session life-time. Below are some of the key benefits: Wide range of Authentication, SSO, and MFA mechanisms to properly identify the initiating machine or user. Ability to integrate with 3rd parties to provide additional enforcement decisions based on the organization's policy. Ability to apply endpoint checks on the client side before session initiation. This goes to BIG-IP in general, the ability to apply custom traffic control on both of the traffic sides, Client and Server. The ability to create whitelist / blacklist for API Access tokens, JSON Web Tokens ID (JTI) or a different element based on the used authentication method, below example steps for JWT: Extract JTI value from Access token. Add JTI value to whether Allow/Block lists. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller)Crafting Secure Paths: The Intricacies of VPN Solutions on BIG-IP APM
Introduction In this article we are exploring Virtual Private Networks (VPN) solutions on F5 BIG-IP Access Policy Manager (APM), In today's digital landscape, secure connectivity is paramount, and BIG-IP APM stands at the forefront, offering a diverse array of VPN options to suit various needs. In this article, we'll delve into the world of BIG-IP APM VPNs, from their different flavors to the tight integration with other modules that enrich the overall solution. Join us as we unravel the complexities, uncover the nuances, and discover how F5 Networks empowers organizations to craft robust, tailored VPN solutions for their unique requirements. BIG-IP APM VPN Solutions VPN is a mean to connect trusted sites over untrusted medium, a user to a corporate portal, branch to main office or between different data centeres. What makes VPN solutions unique with BIG-IP APM is not just the VPN element but the whole ecosystem within your hands, with multiple Multi-Factor Authenticaiton (MFA) and Single Sign-On (SSO) supported protocols. In addition to tight integration with different modules in BIG-IP. All this gives you as Solution Architect the flexibility to come up with different solutions that suits organizations security posture and expand well in the future for any new requirements. IPSEC VPN You can configure an IPsec tunnel to secure traffic that traverses a wide area network (WAN), from a BIG-IP system to third-party device. You start by configuring an IKE peer to negotiate Phase 1 Internet Security Association and Key Management Protocol (ISAKMP) security associations for the secure channel between two systems. You can also configure a custom traffic selector and a custom IPsec policy that use this secure channel to generate IPsec Tunnel mode (Phase 2) security associations (SAs). While IPSEC is configured via BIG-IP LTM, I've added this one here to cover the different VPN solutions, interesting set of articles already published covering different use cases and troubleshooting items for IPSEC VPN via BIG-IP. BIG-IP to Azure Dynamic IPsec Tunneling Securing ExpressRoute with the BIG-IP and IPsec Simple BIG-IP to BIG-IP, On-prem to Public Cloud IPsec Configuration Guide Understanding IPSec IKEv1 negotiation on Wireshark Understanding IPSec IKEv2 negotiation on Wireshark Passthrough IPSec with AFM SSL VPN Because an SSL VPN uses standard web browsers and technologies, it gives users secure remote access to enterprise applications without requiring the installation and maintenance of separate client software on each user’s computer. Most SSL VPNs also integrate with multiple authentication mechanisms. With the growth of the remote workforce, SSL VPNs are critical to keeping employees connected to the work applications they need—and for IT to ensure that only authorized users gain access. SSL VPNs provide a secure way for your workforce, contractors, and partners worldwide to gain access to sensitive information from virtually any computer or device. Furthermore, they give IT full, granular control over data access. SSL VPNs are becoming more common in the workplace, and the learning curve to implement and use them is minimal. Below are some of the use cases and education resources for VPN deployments via BIG-IP APM. Deploying a VPN on the BIG-IP APM Creating a SSL VPN Using F5 Full Webtop F5 VPN Client from Raspberry Pi SSL VPN Split Tunneling and Office 365 Scaling SSL VPN using BIG-IP Local Traffic Manager (LTM) Rate Limiting SSL VPN User Traffic VPN Split Tunneling: The Benefits and Risks SSL VPN Split Tunneling and Office 365 Remote Desktop Protocol (RDP) using an SSL VPN VPN Access with MFA using Edge Client 7.2.1 and APM 16.0 Connect to the F5 VPN with BIG-IP Edge Client How to optimize SSL VPN connections when BIG-IP is reaching 100% CPU Per-App VPN The Per-Application (Per-App) VPN feature makes sure that specific mobile applications and their data remain secure and protected, and only data relevant from the application is sent to the internal network. With the Per-App VPN capabilities of the BIG-IP APM, combined with a mobile device management (MDM) solution, enterprise organizations can be sure only authenticated and authorized mobile users are able to access and send data to the organization from approved mobile applications or mobile containers. Per-App VPN deploys using an existing MDM solution. Depending on the authentication in use, Per-App VPN can offer a seamless or relatively simple way to access internal resources. You can apply per-user bandwidth policies and ACLs to make sure that users comply with network use policies. Detailed user activity auditing is also possible with ACL logging or solutions based on iRules. You must create the following BIG-IP components for this implementation: A connectivity profile An application tunnel profile (Java and per-App VPN) An MDM-enrolled mobile device An MDM-deployed application BIG-IP Edge Client 2.0.1+ for L3 and Per-App VPN Application tunnel An application tunnel provides secure, application-level TCP/IP connections from the client to the internal network. Application tunnels use iSession, an F5 proprietary protocol for transport. Application tunnels can be started using native Windows binary components or with a browser-based Java applet on Windows, Mac, and Linux platforms. Per-user session-level bandwidth policy and ACLs can be applied to application tunnels. You must create the following BIG-IP components for this implementation: A connectivity profile A full webtop An application tunnel resource An access policy that assigns a webtop and an application tunnel resource Related content Configuring a Per-App VPN Using F5 App Tunnels Deploying a VPN on the BIG-IP APM Creating a SSL VPN Using F5 Full Webtop F5 VPN Client from Raspberry Pi SSL VPN Split Tunneling and Office 365 Scaling SSL VPN using BIG-IP Local Traffic Manager (LTM) How to optimize SSL VPN connections when BIG-IP is reaching 100% CPU BIG-IP to Azure Dynamic IPsec Tunneling Understanding IPSec IKEv1 negotiation on Wireshark Understanding IPSec IKEv2 negotiation on Wireshark Passthrough IPSec with AFM K08200035: Use cases | BIG-IP APM operations guide Configuring IPsec in Tunnel Mode between a Remote Device and BIG-IP using Dynamic TemplateF5 BIG-IP Access Policy Manager (APM) - Google Authenticator and Microsoft Authenticator
Introduction Lab guide Phase 1: Token Generation Phase 2: Token verification Related Content Introduction In our walkthrough we are refreshing an existing time-based one-time password (TOTP) deployment Two-Factor Authentication With Google Authenticator And APM In our walkthrough we are following the below assumptions, Secret key is generated outside of F5 and saved to Active Directory (AD) user attribute. F5 APM should be able to query AD user attribute (for example, in our case it's called serialNumber). We have two separate portals, One portal for Token generation and QR scanning. One portal for Application access. Lab guide Phase 1: Token Generation User logs in to the token generation portal and authenticates with AD credentials. F5 APM authenticates the user with AD and query the attribute for the secret key. F5 APM presnets the QR code for the user to be scanned whether by Google or Microsoft Authenticators. Phase 2: Token verification User Access the application and authenticates with AD credentials. Once user is successfully authenticated, the user is prompted to provide the one-time password (OTP). Once F5 verifies the provided OTP, the user is allowed to access the application. Verification iRule when ACCESS_POLICY_AGENT_EVENT { if { [ACCESS::policy agent_id] eq "ga_code_verify" } { ### Google Authenticator verification settings ### # lock the user out after x attempts for a period of x seconds set static::lockout_attempts 3 set static::lockout_period 30 # logon page session variable name for code attempt form field set static::ga_code_form_field "ga_code_attempt" # key (shared secret) storage method: ldap, ad, or datagroup set static::ga_key_storage "ad" # LDAP attribute for key if storing in LDAP (optional) set static::ga_key_ldap_attr "google_auth_key" # Active Directory attribute for key if storing in AD (optional) set static::ga_key_ad_attr [ACCESS::session data get "session.ad.last.attr.serialNumber"] # datagroup name if storing key in a datagroup (optional) set static::ga_key_dg "google_auth_keys" ##################################### ### DO NOT MODIFY BELOW THIS LINE ### ##################################### # set lockout table set static::lockout_state_table "[virtual name]_lockout_status" # set variables from APM logon page set username [ACCESS::session data get session.logon.last.username] set ga_code_attempt [ACCESS::session data get session.logon.last.$static::ga_code_form_field] # retrieve key from specified storage set ga_key "" switch $static::ga_key_storage { ldap { set ga_key [ACCESS::session data get session.ldap.last.attr.$static::ga_key_ldap_attr] } ad { set ga_key [ACCESS::session data get "session.ad.last.attr.serialNumber"] } datagroup { set ga_key [class lookup $username $static::ga_key_dg] } } # increment the number of login attempts for the user set prev_attempts [table incr -notouch -subtable $static::lockout_state_table $username] table timeout -subtable $static::lockout_state_table $username $static::lockout_period # verification result value: # 0 = successful # 1 = failed # 2 = no key found # 3 = invalid key length # 4 = user locked out # make sure that the user isn't locked out before calculating GA code if { $prev_attempts <= $static::lockout_attempts } { # check that a valid key was retrieved, then proceed #Update the key length based on the organization requirements if { [string length $ga_key] == 16 } { # begin - Base32 decode to binary # Base32 alphabet (see RFC 4648) array set static::b32_alphabet { A 0 B 1 C 2 D 3 E 4 F 5 G 6 H 7 I 8 J 9 K 10 L 11 M 12 N 13 O 14 P 15 Q 16 R 17 S 18 T 19 U 20 V 21 W 22 X 23 Y 24 Z 25 2 26 3 27 4 28 5 29 6 30 7 31 } set ga_key [string toupper $ga_key] set l [string length $ga_key] set n 0 set j 0 set ga_key_bin "" for { set i 0 } { $i < $l } { incr i } { set n [expr $n << 5] set n [expr $n + $static::b32_alphabet([string index $ga_key $i])] set j [incr j 5] if { $j >= 8 } { set j [incr j -8] append ga_key_bin [format %c [expr ($n & (0xFF << $j)) >> $j]] } } # end - Base32 decode to binary # begin - HMAC-SHA1 calculation of Google Auth token set time [binary format W* [expr [clock seconds] / 30]] set ipad "" set opad "" for { set j 0 } { $j < [string length $ga_key_bin] } { incr j } { binary scan $ga_key_bin @${j}H2 k set o [expr 0x$k ^ 0x5C] set i [expr 0x$k ^ 0x36] append ipad [format %c $i] append opad [format %c $o] } while { $j < 64 } { append ipad 6 append opad \\ incr j } binary scan [sha1 $opad[sha1 ${ipad}${time}]] H* token # end - HMAC-SHA1 calculation of Google Auth hex token # begin - extract code from Google Auth hex token set offset [expr ([scan [string index $token end] %x] & 0x0F) << 1] set ga_code [expr (0x[string range $token $offset [expr $offset + 7]] & 0x7FFFFFFF) % 1000000] set ga_code [format %06d $ga_code] # end - extract code from Google Auth hex token if { $ga_code_attempt eq $ga_code } { # code verification successful set ga_result 0 } else { # code verification failed set ga_result 1 } } elseif { [string length $ga_key] > 0 } { # invalid key length, greater than 0, but not length not equal to 16 chars set ga_result 3 } else { # could not retrieve user's key set ga_result 2 } } else { # user locked out due to too many failed attempts set ga_result 4 } # set code verification result in session variable ACCESS::session data set session.custom.ga_result $ga_result } } Related Content Two-Factor Authentication With Google Authenticator And APM Demystifying Time-based OTP Google Authenticator Token Verification iRule For APM APM Google Authenticator HTTP API Google Authenticator Verification iRule (TMOS v11.1+ optimized) UDF Lab Configuring MFA OTP Note, Scan the Article photo for more BIG-IP Access Policy Manager (APM) info.OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10
In an era where cyber threats loom large, safeguarding digital assets has become paramount. Among the vanguard of defenders stands the F5 BIG-IP Access Policy Manager (APM), a stalwart guardian against the notorious OWASP Top 10 vulnerabilities. In this article, we embark on a journey through the tactical strategies employed by BIG-IP APM, unraveling how it reinforces the fortifications against these pervasive threats. From dynamic access controls to multifaceted authentication protocols, BIG-IP APM stands as a beacon of resilience in the face of evolving security challenges. Join us as we delve into the intricacies of BIG-IP APM's role in shoring up defenses, ensuring your digital landscape remains a fortress impervious to OWASP's formidable arsenal. OWASP The OWASP (Open Web Application Security Project) API (Application Programmable Interface) Security project aims to help the organizations by providing a guide with a list of the latest top 10 most critical API vulnerabilities and steps to mitigate them. As part of updating the old OWASP API Security risk categories of 2019, recently OWASP API Security Top 10 2023 is released. Introduction to OWASP API Security Top 10 2023 lists the updated top 10 list and the explanation for each one, in our series we focus more on the access related items. BIG-IP APM Within the realm of access security, BIG-IP APM emerges as a pivotal player, offering more than just session awareness and enforcement capabilities. Its unique strength lies in its capability to handle per-request calls, providing an unprecedented level of granularity in securing API endpoints. BIG-IP APM's prowess extends beyond session management; it boasts per-request awareness, enforcing rigorous authentication and authorization protocols on API requests directed towards safeguarded endpoints. This distinctive feature ensures robust protection for your digital assets. As we delve deeper into this series of articles, we'll uncover how BIG-IP APM significantly bolsters your defense strategy in addressing the critical challenges outlined in the OWASP top 10 API vulnerabilities. Stay engaged to explore the comprehensive capabilities of BIG-IP APM and how it plays a pivotal role in fortifying your security posture against these formidable threats. Related Content F5 BIG-IP Access Policy Manager | F5 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM
Addressing Broken Object Level Authorization (BOLA) vulnerabilities requires a multifaceted approach, combining robust coding practices, secure development methodologies, and powerful tools. Among these tools, F5 BIG-IP Access Policy Manager (APM) stands out as a crucial component in the arsenal of security measures. This article, the second in a series of articles dedicated to fortifying application security, delves into the pivotal role that BIG-IP APM plays in identifying, mitigating, and ultimately preventing OWASP top 10 API vulnerabilities byproviding developers and security professionals with a comprehensive guide to bolstering application security in the face of evolving cyber threats. Broken Object Level Authorization This is one of the most common and severe vulnerabilities within APIs and is related to Insecure Direct Object References (IDOR). Starting with, what's Object Level Authorization? This is an access control mechanism that's in place to validate which user has access to a specific endpoint and what actions to be performed. BOLA and IDOR refer to situations where the endpoints fail to enforce specific authorization rules on endpoints, or the user is successfully able to access unauthorized endpoints and perform unauthorized actions. The weakness that can lead to this vulnerability is the server component fails to track client state and rely on other parameters that can be tweaked from the client side, for example (Cookies, object IDs). BOLA Example Let's assume this backend directory, - /uploads/ - user1/ - file1.txt - file2.txt - user2/ - file3.txt - file4.txt The expected user1 usage is as follows, https://example.com/viewfile?file=file1.txt the user can access file1. If the server is vulnerable to BOLA, let's have user2 accessing the server, then try to navigate to file1 as follows, https://example.com/viewfile?file=user1/file1.txt What could help us in this situation? Yes, we need granular endpoint authorization with proper client state tracking. That's where our lovely friend BIG-IP APM comes into the picture. Let's see how BIG-IP APM can help us. BIG-IP APM and BOLA protection BIG-IP APM provides API protection through its Per-Request policy, where the it applies granular Access protection to each API endpoint. How BIG-IP APM enhancesdefenses We start with creating our Per-Request policy, this policy works in a different way than the per-session policy, as the flow will be evaluted on a per-request basis, making sure to consider variations throught the session life-time. Below are some of the key benefits: Wide range of Authentication, SSO, and MFA mechanisms to properly identify the initiating machine or user. Ability to integrate with 3rd parties to provide additional enforcement decisions based on the organization's policy. Ability to apply endpoint checks on the client side before session initiation. This goes to BIG-IP in general, the ability to apply custom traffic control on both of the traffic sides, Client and Server. Using BIG-IP API protection profile. Protection profiles are an easy way to deploy both APM (Per-Request policy) and Advanced Web Application Firewall (AWAF). As a pre-requisite, you need APM, AWAF licensed and provisioned. Use OpenAPI Spec 2.0 as an input to the API protection. Apply different Authentication methods, whether Basic, Oauth (Directly from the template), or once we have the API protection profile created, we can customize policy elements to our needs. Using Hybrid approach with F5 Distributed Cloud (F5 XC) + BIG-IP APM We had this approach discussed in details through F5Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller) Stay engaged to explore the comprehensive capabilities of BIG-IP APM and how it plays a pivotal role in fortifying your security posture against these formidable threats. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller)Federated AWS Console Access Made Easy: F5 BIG-IP Access Policy Manager Access Guided Configurations
Introduction In the following guide we are configuring Federated AWS Console Access through BIG-IP APM as Identity Provider (IdP). With AWS console we need to be very careful about granting access, checking endpoint and apply Multi-Factor Authentication (MFA). Architecture The expected traffic flow follows the below path, User Access F5 APM portal. F5 APM applies EndPoint inspection and user authentication. Once the user is authenticated, APM redirects user browser to AWS Console with SAML assertion. AWS Console verifies the assertion, the assigned role and allow the proper access to the user. Configurations steps let's list the steps to perform the configurations. F5 APM Configurations Head to Access > Access Guided Configurations > Select SAML Identity provider template Configure IdP settings. Configure Virtual Server settings or select one that's already created. Specify Authentication and MFA settings. Select proper SaaS Application template (Amazon Web Services in our case) Configure the AWS Application settings, Mention IdP name configured at AWS console. Mention IdP role name created at AWS console. EndPoint checks and inspection Then adjust session management parameters as per requirements and customization for the web portal and Deploy. Here's how the final policy should look like, Note, you can make use of authentication part to fetch the proper role per user and communicate that to AWS Console, so each user is assigned to the proper role. AWS Console Configurations Create IdP settings from AWS Console > IAM > Identity Providers Make sure to assign proper roles to the Identity Provider and make sure the role got "sts:AssumeRoleWithSAML" Allow. Conclusion Using Access Guided Configurations, it's easy to secure and simplify access to AWS Console and we can extend our existing Identity services to facilitate and authorize access to AWS Console. In addition to authorizing users, you can make use of F5 APM endpoint inspection and further integrations with 3rd parties through HTTP connectors and iRules. Related Contents Overview of F5 Guided Configuration Guided Configuration 10.0 Creating IAM identity providers Enabling SAML 2.0 federated users to access the AWS Management ConsoleHarnessing the power of F5 BIG-IP Access Policy Manager (APM) and Microsoft
A key element to F5 BIG-IP Access Policy Manager (APM) wide range of use cases has always been the ease of integration with other technology partners. Not only BIG-IP APM own capabilities but extending other technologies capabilities to make a more robust and flexible uses cases. This ease of integration and flexibility make it easy for organizations to make the best out of their security investments. Below are some of the integration examples to get an idea: BIG-IP APM and AzureAD: F5 APM as Service Provider (SP) and AzureAD as Identity Provider (IDP), where user authenticates through AzureAD and got SAML insertion in the response while being redirected to BIG-IP APM. Leverage F5 BIG-IP APM and Azure AD Conditional Access Easy button, where AzureAD policies can be enabled and slected from BIG-IP APM dashboard when creating the policies. Zero Trust building blocks - Leverage Microsoft Intune endpoint Compliance with F5 BIG-IP APM AccessZero Trust building blocks - Leverage Microsoft Intune endpoint Compliance with F5 BIG-IP APM Access, BIG-IP APM and Microsoft Intune to make use of the end point compliance. BIG-IP APM and ADFS: ADFS Proxy Replacement on F5 BIG-IP , F5 can act as a ADFS proxy to proxy and authenticate users as a replacement for the WAP component of the ADFS. F5 LTM can be used to load balance only traffic to ADFS environment. BIG-IP APM with Kerberos for authentication and Single Sign-On. Some common use case is using F5 APM to simplify migration between different deployment models, BIG-IP APM can front ADFS and hence decouple both sides of the flow, the client traffic to BIG-IP APM and traffic towards ADFS. Once we have the traffic decoupled, we can further migrate the ADFS to AzureAD. BIG-IP APM SSO helps with utilizing modern authentication and federation technologies at client side, and back end can still integrate with legacy SSO technologies. BIG-IP APM helps if the application is not yet ready for advacned and cloud identity integrations, so F5 client side integrate with the modern identity services, and backend can be developed on a different pace. Related content leverage BIG-IP APM Azure AD with Conditional Access Easy button Zero Trust - Making use of a powerfull Identity Aware Proxy Leverage Microsoft Intune endpoint Compliance with F5 BIG-IP APM Access - Building Zero Trust strategy F5 BIG-IP Access Policy Manager (APM) - Google Authenticator and Microsoft Authenticator APM Cookbook: SAML IdP Chaining - DevCentral Technology Alliances | Partners | F5 Secure hybrid access with F5 deployment guide - Microsoft Entra | Microsoft Learn Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm” Big-IP and ADFS Part 2 - APM: An Alternative to the ADFS Proxy Big-IP and ADFS Part 3 - “ADFS, APM, and the Office 365 Thick Clients”Zero Trust building blocks - Leverage F5 NGINX Plus Single Sign-On (SSO) and F5 XC
As part of your organization journey to build a Zero Trust strategy with distributed Microservices, you would think of a light weight engine that allows to perform request authentication and authorization. While keeping the continuous monitoring and the protection provided by F5 Distributed Cloud Web App & API Protection (WAAP), you can provide the authentication and authorization required to your microservices by implementing F5 NGINX Plus for Single Sign-On SSO. In our article we will explore the path through previously created articles and how we can make use of it to achieve our organization strategy. Deployment options We have multiple deployment options to suit your needs, below are two examples: Using F5 Hybrid Security Architecture Article, there's more to follow on series-f5-hybrid-architecture. You can deploy and NGINX Plus instance in AWS and manually create an HTTP LoadBalancer in Distributed Cloud, F5 Distributed Cloud - Introduction to Deployment Models and Services. SSO with NGINX Plus Once you have completed your infrastructure deployment it's time to delpoy the Identity layer and this was discussed over hereEnhanced Modern Applications and MicroServices SSO with NGINX Summary In this article we utilized both Distributed Cloud WAAP and the NGINX Plus SSO feature to allow for continuous monitoring and protection for users traffic and maintaining authentication and authorization through our microservices deployment. Related Content Deploy WAAP Anywhere with F5 Distributed Cloud How to get started with F5 Distributed Cloud Managed Services F5 Hybrid Security Architectures: One WAF Engine, Total Flexibility F5 Hybrid Security Architectures for DevSecOps: F5's Distributed Cloud WAF and BIG-IP Advanced WAF F5 Hybrid Security Architectures for DevSecOps: F5's Distributed Cloud WAF and NGINX App Protect WAF F5 Hybrid Security Architectures: F5 XC API Protection and NGINX Ingress Controller F5 Hybrid Security Architectures for DevSecOps: F5's Distributed Cloud WAAP Bot and DDoS Defense and BIG-IP Advanced WAF Installing NGINX Plus | NGINX Documentation Leveraging NGINX Plus for Modern Apps SSOZero Trust building blocks - F5 BIG-IP Access Policy Manager (APM) and PingIdentity
We started a discussion on Machine Identity and Zero Trust building blocks in Zero Trust building blocks - Machine Identity Management (MIM) and Workload Protection . In that article we talked about one of the main items on NIST ZTNA framework which is the presence of Policy Decision Point (PDP) and Policy Enforcement Point (PEP). The way F5 as Full Proxy is installed allow to have flexible deployments with multiple components, at a point BIG-IP APM acts on its own as both PDP and PEP. Also, F5 APM can act as PEP and rely on different Identity Providers as a decision point (PDP). In this article we are going to take a deeper look at BIG-IP integration with PingIdentity . where PingIdentity acts as the PDP and BIG-IP APM acts as PEP. How F5 simplifies PingIdentity integration F5 deployment guide presents two main use cases when intergating with PingIdentity, Horizontal Scaling and offloading PingAccess Agent functionality to BIG-IP APM. PingIdentity as Identity Provider and BIG-IP APM as Service Provider. Horizontal Scaling and offloading PingAccess Agent functionality to BIG-IP APM BIG-IP APM allows the distribution of application access requests to multiple PingAccess nodes depending on constraints and availability. The client requests access to a protected resource. BIG-IP APM built-in PingAccess agent functionality requests a decision from PingAccess policy server. PingAccess checks the URL policy and determines that the requested resource is protected. It then responds to BIG-IP APM indicating that the user should be redirected to PingFederate for authentication. BIG-IP APM redirects the user to PingFederate. After successful authentication, the user is redirected to BIG-IP APM with a PingFederate token. BIG-IP APM passes the PingFederate token to PingAccess, which validates the PingFederate response and provides BIG-IP APM with the decision to allow or deny access to the resource. The decision comes with an expiration and will be cached in BIG-IP APM which enforces the decision until its expiration. PingIdentity as Identity Provider and BIG-IP APM as Service Provider BIG-IP APM acts as Service provider and PingIdentity the Identity provider. BIG-IP APM gives support to modern and legacy authentication systems which allows for robust Single Sign-On (SSO) integration with on-premises and cloud-based identity providers and supports Virtual Desktop Infrastructure (VDI). Build SAML trust between BIG-IP APM and PingFederate. User requests access to the protected web resource through BIG-IP APM. BIG-IP APM redirects user browser to PingFederate for Authentication. User's browser is redirected back to BIG-IP APM with assertion response. BIG-IP APM validates the assertion and allow access. If SSO is used (for example Kerberos), BIG-IP APM use kerberos delegation with information obtained from sesssion's variables for SSO. Once successfull, the user is allowed to access the protected resource. Related Content BIG-IP APM and PingIdentity deployment guide. Configuring NGINX API micro-gateway to support Open Banking's Advanced FAPI security profile Integrating NGINX Controller API Management with PingFederate to secure financial services API transactions Zero Trust building blocks - Machine Identity Management (MIM) and Workload Protection
