NGINX Management Suite API Connectivity Manager - Modern API driven Applications
Introduction API based applications benefits NGINX Management Suite API Connectivity Manager capabilities API Connectivity Manager use case API Connectivity Manager use case overview API Connectivity Manager traffic flows API Connectivity Manager lab & implementation References Introduction API based applications benefits Before we dive into our API gateway use case, we will go one step back and check why the move to API driven applications, below are some of the benefits for this move: Loose coupling: API-based applications can be built and maintained independently, allowing for faster development and deployment cycles. Reusability: APIs can be reused across multiple applications, reducing the need to duplicate code and effort. Scalability: API-based architecture allows for easier scaling of individual services, rather than having to scale the entire application. Flexibility: APIs allow for different client applications to consume the same services, such as web, mobile, and IoT devices. Interoperability: APIs facilitate communication between different systems and platforms, enabling integration with third-party services and data sources. Microservices: API-based architecture allows developers to build small, modular services that can be developed, deployed, and scaled independently. NGINX Management Suite API Connectivity Manager capabilities NGINX Management Suite API Connectivity Manager adds to the capabilities of the API driven applications a secure approach to authenticate, access and developing those API based applications. API Connectivity Manager is used to connect, secure, and govern our APIs. In addition, API Connectivity Manager lets us separate infrastructure lifecycle management from the API lifecycle, giving the IT/Ops teams and application developers the ability to work independently. API Connectivity Manager provides the following features: Create and manage isolated Workspaces for business units, development teams, and so on, so each team can develop and deploy at its own pace without affecting other teams. Create and manage API infrastructure in isolated workspaces. Enforce uniform security policies across all workspaces by applying global policies. Create Developer Portals that align with your brand, with custom color themes, logos, and favicons. Onboard your APIs to an API Gateway cluster and publish your API documentation to the Dev Portal. Let teams apply policies to their API proxies to provide custom quality of service for individual applications. Onboard API documentation by uploading an OpenAPI spec. Publish your API docs to a Dev Portal while keeping your API’s backend service private. Let users issue API keys or basic authentication credentials for access to your API. Send API calls by using the Developer Portal’s API Reference documentation. API Connectivity Manager use case API Connectivity Manager use case overview In our case we will have three teams, Infrastructure team, this one will be responsible for setting up the infrastructure, domains and access policies. API team, this one will be responsible for setting up the API documentation, QoS and gateway for both production and developer portals. Application team, this one will be responsible for learning the APIs through the developer portal and use the APIs through the production portal. Authentication in our case is done via two methods, API Key authentication for API version 1. OAuth2 introspection for API version 2. Note, More Authentication methods can be used (JSON Web Token Assertion) included in the following tutorial. API authentication more detailed discussion can be found here Application Programming Interface (API) Authentication types simplified Additional features like API rate limiting can be applied as well, here's a toturial to enable that feature. API Connectivity Manager traffic flows In our use case will have three flows, Management flow, illustrated below. Metrics and events collection flow, illustrated below Data flow illustrated below NGINX tutorial on how to streamline API operations with API Connectivity Manager, API Connectivity Manager lab & implementation ِThe steps we are going to follow with some useful tutorial videos are highlighted below, Setup backend API application (This step has been already done for you in the lab). Setup API Connectivity Manager infrastructure and policies. Enable API Key Authentication via the following Youtube toturial Enable API Key Authentication with API Connectivity Manager. Publish APIs and Documentation through API Connectivity Manager. Test APIs through API Developer Portal The detailed lab guide and the implementation videos Cloud labs detailed guide https://clouddocs.f5.com/training/community/nginx/html/class10/class10.html UDF lab can be found here as well https://udf.f5.com/b/ed5ffb71-bcce-47ec-9d9f-307441e4c12c#documentation Below a recorded Lab walkthrough by our awesome guru Matt_Dierick References API Connectivity Manager NGINX Management Suite NGINX Docs API Connectivity Manager UDF Lab
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 10Zero Trust building blocks - Leverage Microsoft Intune endpoint Compliance with F5 BIG-IP APM Access
Use case summary Conclusion Additional resources Use case summary Let's walk through a real life scenario, we have company A that's building its Zero Trust strategy and of course it will be great to make use of existing solutions to reach our target. Microsoft Intune introduces a great source of intelligence and compliance enforcement for endpoints, combined with F5 BIG-IP Access Policy Manager (APM) integrated with AzureAD this extends the enforcement to the endpoints accessing Company A resources whether it's a SAAS or locally hosted. Below is the flow of some use cases that leverage how F5 BIG-IP APM and Microsoft Intune pave the way to achieve Zero Trust strategy. We've an endpoint Managed by Microsoft Intune. Microsoft Intune contains device compliance policy to determine the conditions at which the machine to be considered compliant and the configuration profile determine the configurations for specific applications in our case (F5 Access VPN). We have the following use cases, User tries to access web application through F5 BIG-IP APM, BIG-IP is already integrated with Microsoft Intune and Azure AD. F5 BIG-IP APM acts as SP, that directs user request to AzureAD for authentication and compliance check. If the user successfully authenticate and pass compliance policy, user will be redirected back to the application with SAML assertion response otherwise the user will be denied to acces. A demo was created by our awesome Access guru Matt_Dierick User tries to use SSL VPN to access corporate resources, User click on F5 Access VPN connection pushed to the endpoint via configuration profile at Microsoft Intune. User selects the proper authentication method (Username&Password, Smart Card or Certificate based Authentication). Once user successfully authenticate and pass compliance check, a temporary certificate is pushed to the machine. The temporary certificate is used to authenticate with F5 BIG-IP APM and then the user is granted access to SSL VPN connection. A demo was created for this use case as well by our awesome Access guru Matt_Dierick , as Microsoft Intune portal got updated, we may now perform the endpoint management related tasks through endpoint.microsoft.com portal instead of portal.azure.com, make sure to follow Microsoft documentations for any new updates. Conclusion In conclusion to the highlighted use cases, we can see that we can make use of existing solutions and extend their capabilities with the ease of integration to acheive our organization Zero Trust strategy. F5 BIG-IP in general allows the organization to decouple client side connection from server side, which simplifies further services integration to boost organization security posture. F5 BIG-IP APM allows us to integrate with different parties to extend their capabilties whether they endpoint compliance, risk factor or IDaaS to use such insights for securing application or network access. In addition to corporate related secure access, if we have customers accessing applications and need integration with Google or other Open ID Connect (OIDC) provider, you can make use of F5 BIG-IP APM OIDC integration to that 3rd party for customers' access. Additional resources Configuring Access Policy Manager for MDM applications BIG-IP Access Policy Manager: Third-Party Integration OAuth and OpenID Connect - Made easy with Access Guided Configurations templatesApplication Programming Interface (API) Authentication types simplified
API is a critical part of most of our modern applications. In this article we will walkthrough the different authentication types, to help us in the future articles covering NGINX API Connectivity Manager authentication and NGINX Single Sign-on.F5 BIG-IP Access Policy Manager (APM) - Idp integration - Cisco vManage
Introduction Lab setup F5 BIG-IP APM configurations User testing Notes Introduction Cisco vManage allows administrators to configure Single Sign-on through Idp (Identity Provider) for users (administrators) authentication. Integrating with F5 BIG-IP APM as Idp, we are able to use a wide range of authentication methods and Multi-Factor Authenticaiton techniques to enhance admins secure access. Below are the main parts: 1- Identity Provider (Idp): In our case, F5 acts as Idp that integrate with different authentication services with MFA if required. 2- Service Provider (SP): In our case, Cisco vManage. 3- Users: Whether admins, guests or operator level users, they are the one initiating the access and providing the credentials. Lab setup Below is the lab setup used in our test, Cisco vManage acting as the service provider, with the below notes, Organization name is configured under Administrator > Settings. Idp enabled and download the SAML service provider metadata. F5 BIG-IP APM acting as Idp and as a simple test we are using localdb on APM, but in production environment it's recommended to use other options like Active Directory (AD). Configure Idp settings. Import Cisco vManage metadata to create SP connector. Create SAML resource that will be used in the policy. Create Virtual Server with the access policy related to SAML. Note, It's doable to add MFA and different authentication schemes. F5 BIG-IP APM configurations At F5 BIG-IP APM side, we need to configure the below elements, Configuer Access Policy and assign it to virtual server. Logon page, Authentication. Variable assign to fetch user group membership to send it over to vManage based on the user name. Configure Idp elements: Local Idp service (Access > Federation > SAML Identity Provider > Local Idp services) Idp identity ID, this reflects the virtual server used for Idp. Assertion settings Attributes need to be sent within the SAML assertions, note here we added the Groups attribute that reflects the adminitrator privilege level. Security settings define the certificate and key used for SAML signing. Now, we need to import the Service Provider Metadata (Federation > SAML Identity Provider > External SP Connectors) Click on the arrow at create word and select Import from Metadata Select the metadata file you downloaded from vManage administrator page Type a service provider name (any name). In the sigining certificate select None. After the file is successfully imported, we need to bind this SP connector the the Idp service we created. From (Federation > SAML Identity Provider > Local Idp services) select the Idp service we created then click on bind then selct the SP Connector we created in the previous step. One final step to finalize the SAML configuration elements, Configure the SAML resource that will be used in the access policy (Access > Federation > SAML Resource) and click create, then select the Idp resource referencing our Idp service. Create Full webtop, Access > Webtops > Webtop list User testing User tries to login to Cisco vManage administration page. Browser is redirected to F5 APM login page, for user to provide the credentials. F5 APM then validates the credentials with the configured authentication service. F5 redirect the browser back with the SAML assertion to Cisco vManage and user is logged in successfully. Notes Some notes for modification might need to be done. Make sure to send the SAML attribute Groups as without it, vManage automatically assign the user as basic group. Based on your authentication service, the variable where the Group name is obtained might be different. When you try to upload the metadata to F5 SP connector, it will give an xml signed error, so you need to remove the part in the xml between the tags (<ds:Signature ….. </ds:Signature>) , then upload the metadata and choose signed certificate as none. The metadata will automatically create the .crt / .key files.OWASP 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)Harnessing 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”Multi-Stores Citrix environment BIG-IP APM
Introduction In this article we are going to discuss a use case, where we have multiple stores URIs hosted at the same Citrix StoreFront. Following Citrix deployment guide , we end up with the below policy configurations, The created Form Based Single Sign-On look like the below, Note, Make sure to validate the strart URI and form action if any customization done at store front side. Additional configurations In order to adjust the configurations to match our multi-store setup, we will follow the below, As a start we will need to replicate the SSO settings to match the number of hosted stores, below example for additional two stores (StoreB, StoreC) StoreB StoreC Then we create an iRule similar to the below and attach it to XML HTTPS virtual server created by the iapp. when ACCESS_ACL_ALLOWED { switch -glob -- [string tolower [HTTP::uri]] { /citrix/storea/explicitauth/login* { WEBSSO::select Citrix_storea_sso_form_based } /citrix/storeb/explicitauth/login* { WEBSSO::select Citrix_storeb_sso_form_based } /citrix/storec/explicitauth/login* { WEBSSO::select Citrix_storec_sso_form_based } } } At the end, we remove the SSO settings under the access policy to allow our iRule to control the SSO selection. References Citrix XenApp or XenDesktop deployment guideOAuth and OpenID Connect - Made easy with Access Guided Configurations templates
Introduction Lab walk through Access Guided Configuration support Lab steps summary Create DNS Resolver. From Access Guided configuration choose proper template. Create OAuth Provider. Create OAuth Server. Create OAuth Policy (Scope). Create Virtual Server. Optional: Single Sign-On configurations. Lab configurations steps Create DNS Resolver Access Guided configuration template Create OAuth Provider, Server and Policy Create Virtual Server Introduction OpenID Connect (OIDC) is an open authentication protocol that works on top of the OAuth 2.0 framework. The purpose of OIDC is for users to provide one set of credentials and access multiple sites. Each time users sign on to an application or service using OIDC, they are redirected to their OP (OpenID Provider), where they authenticate and are then redirected back to the application or service. OpenID is decentralized and not owned by anyone, nor should it be. Today, anyone can choose to use an OpenID or become an OpenID Provider for free without having to register or be approved by any organization. OpenID Connect adds an identity layer on top of OAuth 2.0. When configured as an OAuth client / resource server, Access Policy Manager (APM) can interact with an OpenID Connect provider to get this data: UserInfo requests APM can make UserInfo requests to an endpoint that is specified for that purpose on an OAuth provider. APM supports UserInfo requests from the OAuth Scope and OAuth Client agents in an access policy or a per-request policy subroutine. ID Token As defined in the OpenID Connect core 1.0 spec, an ID Token contains claims by an authorization server about the authenticated user when using a client. APM obtains an ID Token from an OAuth provider when OpenID Connect is enabled in the OAuth Client agent in an access policy or a per-request policy. (The OAuth provider must support OpenID Connect.) The OAuth 2.0 spec has four important roles: OAuth role Description Resource Owner Can grant access to a protected resource. A resource owner can be an end-user (person) or another entity. Resource Server Hosts protected resources, and can accept and respond to requests for protected resources using access tokens. Client Makes requests for protected resources on behalf of, and with authorization from, the resource owner. The client is an application. Authorization Server Issues access tokens to the client after successfully authenticating the resource owner and obtaining authorization. APM in OAuth resource server and client roles When Access Policy Manager ® (APM ® ) acts as an OAuth resource server, users can log on using external OAuth accounts to gain access to the resources that APM protects. External OAuth accounts can be social accounts, such as Facebook and Google, or enterprise accounts, such as F5 (APM) and Ping Identity (PingFederate). In this configuration, APM becomes a client application to an external OAuth authorization server, such as F5, on another BIG-IP ® system, or Google. APM in the OAuth authorization server role When Access Policy Manager ® (APM ® ) acts as an OAuth authorization server, APM can grant authorization codes, access tokens, and refresh tokens, and APM can perform token introspection. A great series was created by the APM guru Matt_Dierick https://www.youtube.com/watch?v=vpYfm_YCBRA https://www.youtube.com/watch?v=JuVLwbffQ8s https://www.youtube.com/watch?v=ABt3UD5q7f4 More Federated labs can be access through Lab docs, https://clouddocs.f5.com/training/community/iam/html/archived/archived.html Lab walk through Access Guided Configuration support Here's the support matrix for the templates using OAuth. Use case/Component Version Compatible BIG-IP versions OAuth Authorization Server 4.3.0 14.1.x, 15.0.x, 15.1.x, 16.0.x, 16.1.x OAuth Client and Resource Server 4.4.0 14.1.x, 15.0.x, 15.1.x, 16.0.x, 16.1.x UDF Lab access: https://udf.f5.com/b/cd258f67-afbd-45c8-a2c9-9201a9f2f6c4#components Lab steps summary Create DNS Resolver. From Access Guided configuration choose proper template. Create OAuth Provider. Create OAuth Server. Create OAuth Policy (Scope). Create Virtual Server. Optional: Single Sign-On configurations. Lab configurations steps Create DNS Resolver This DNS resolver will be responsible for resolving the dns name for the Identity provider URL. Create the Forward zone to reach (if you are using DNS Proxy, specify it) - Either use the OpenID provider zone name or use (.) to forward all queries. Note, DNS Address needs to be reachable over TMM interface (not mgmt interface). Access Guided configuration template In our case we are going to deploy F5 as Client and Resoure Server Select the proper DNS Resolver Create OAuth Provider, Server and Policy Audience: Use the Client ID provided by the OpenID provider. Below we select the OAuth provider and configure the server and scope settings. Create Virtual Server Configure the required virtual server settings Assign the pool to the policy And that's it you have the configurations ready, and can start testing them, Below is the testing behavior. 1- Access URL for the virtual server. 2- User is redirected to google for user authentication. 3- User authentication pass successfully. Access OAuth dashboard
