supachai-j/F5-Access-Policy-Manager-APM-Solution-Guide

F5-Access-Policy-Manager-APM-Solution-Guide

Welcome to the Access Policy Manager (APM) lab guide.

The following labs and exercises will instruct you on how to configure and troubleshoot various APM use cases. This guide is intended to complement lecture material provided during the course as well as a reference guide that can be referred to after the class as a basis for configuring Access solutions in your own environment.

Original Lab Guide

Table of Contents

- Class 1 – Access Policy Manager Solution (F5 APM)

• Module 1: APM GUI Overview
• Module 2: Building a Basic Access Policy
• Module 3: Server-Side Single Sign-On
• Module 4 Part 1: SAML SP Access Guided Configuration (AGC)
• Module 4 Part 2: SAML Identity Provider (IdP) - Certificate Auth

- Class 2 – API Protection with AWAF and APM modules

• Module 5 Part 1: Deploy an APM API Protection Profile
• Module 5 Part 2: Deploy an AWAF Bot Defense and WAF protection

Environment Overview

UDF Blueprint

Access Labs & Solutions (Version 16.0)

Lab Topology

The following components have been included in your lab environment:

Note

BIG-IP2 and BIG-IP6 are offline by default. Only boot these BIG-IPs when the lab specifies to do so.

4 x F5 BIG-IP VE (v16.0) 1 x Windows Server 2016 - jumphost.f5lab.local 1 x Windows 2016 Server - dc1.f5lab.local (AD, CA, OCSP & internal DNS) 1 x Windows 2016 Server - iis.f5lab.local 1 x Centos 7 - web.f5lab.local

Lab Components

The following table lists VLANS, IP Addresses and Credentials for all components:

jumpbox.f5lab.local

Management 10.1.1.10 External 10.1.10.10 Internal 10.1.20.10

Credentials: f5lab\user1 user1 f5lab\user2 user2 f5lab\admin admin

bigip1.f5lab.local

Management 10.1.1.4 External 10.1.10.4 10.1.10.100 10.1.10.101 10.1.10.102 10.1.10.103 10.1.10.104 10.1.10.105 10.1.10.106 10.1.10.107 10.1.10.108 10.1.10.109 10.1.10.110 10.1.10.111 10.1.10.112 10.1.10.113 Internal 10.1.20.4

Credentials: admin/admin

bigip2.f5lab.local

Management 10.1.1.5 External 10.1.10.5 10.1.10.200 10.1.10.201 10.1.10.202 10.1.10.203 10.1.10.204 10.1.10.205 10.1.10.206 10.1.10.207 10.1.10.208 10.1.10.209 10.1.10.210 10.1.10.211 10.1.10.212 10.1.10.213 Internal 10.1.20.5

Credentials: admin/admin

bigip5.f5lab.local

Management 10.1.1.11 External 10.1.10.11 10.1.10.99 Internal 10.1.20.11 10.1.20.99

Credentials: admin/admin

bigip6.f5lab.local

Management 10.1.1.12 External 10.1.10.12 10.1.10.199 Internal 10.1.20.12 10.1.20.199

Credentials: admin/admin

dc1.f5lab.local

Management 10.1.1.7 Internal 10.1.20.7

Credentials: admin/admin

iis.f5lab.local

Management 10.1.1.6 Internal 10.1.20.6 10.1.20.16

Credentials: admin/admin

web.f5lab.local

Management 10.1.1.9 Internal 10.1.20.9 10.1.20.19

Credentials: admin/admin

radius.f5lab.local

Management 10.1.1.8 Internal 10.1.20.8 10.1.20.18

Credentials: admin/admin

Module 1

Module 1 : APM GUI Overview

Objectives The intention of this lab will be to show how to enable Access Policy Manager (APM) through resource provisioning. Next we will explore all the components within the Access left menu. This is not a deep dive on the components but an overview of the components, features and concepts of APM.

Setup Lab Environment To access your dedicated student lab environment, you will need a web browser and Remote Desktop Protocol (RDP) client software. The web browser will be used to access the Unified Demo Framework (UDF) Training Portal. The RDP client will be used to connect to the jumphost, where you will be able to access the BIG-IP management interfaces (HTTPS, SSH).

1. Click DEPLOYMENT located on the top left corner to display the environment

2. Click ACCESS next to jumphost.f5lab.local

3. Select your RDP resolution.

4. The RDP client on your local host establishes a RDP connection to the Jump Host.

5. Login with the following credentials:

User: f5lab\user1 Password: user1

6. After successful logon the Chrome browser will auto launch opening the site https://portal.f5lab.local. This process usually takes 30 seconds after logon.

7. Click the Classes tab at the top of the page. Scroll down the page until you see 101 Intro to Access Foundational Concepts on the left.

8. Hover over tile APM GUI Overview. A start and stop icon should appear within the tile. Click the Play Button to start the automation to build the environment

9. After the click it may take up to 30 seconds before you see processing

10. Scroll to the bottom of the automation workflow to ensure all requests succeeded. If you experience errors try running the automation a second time.

Task 1: Resource Provisioning¶

Access Policy Manager (APM) is a module available for use on the BIG-IP platform (Hardware and Virtual). Unlike other modules, APM can be provisioned with limited functionality on any BIG-IP platform without a specific license (see F5 KB15854). APM is licensed based on the number of Access Sessions and Concurrent Users Sessions (see APM Operations Guide). You can provision APM limited and immediately start using all the functions of APM with a limitation of 10 Access and Concurrent user session.

Important

APM has already been provisioned for this lab. The next step would be completed if you are provisioning on your own BIG-IP.

1. Open new tab and log in to bigip1.f5lab.local with administrative credentials provided

2. On the left menu navigate to System –> Resource Provisioning

Click box and on the drop down next to the module and choose Nominal

Note

In most use cases you will want to use Nominal for provisioning modules. What does each setting mean?

Dedicated Specifies that all resources are dedicated to the module you are provisioning. For all other modules, the level option must be set to none.

Minimum Specifies that you want to provision the minimum amount of resources for the module you are provisioning.

Nominal Specifies that you want to share all of the available resources equally among all of the modules that are licensed on the unit.

4. Before you click on Submit note that this operation will halt operations while the module provisions. Do not do this on an active unit processing traffic unless you are in an outage window. This will not require a reboot but will take approximately 1 to 5 minutes to complete.

Note

Resource Provisioning is not a synced item between HA pairs. You will need to provision the module on all devices in the cluster.

Task 2: Guided Configuration¶

Access Guided Configuration (AGC) provides an easy way to create BIG-IP configurations for categories of Access use cases. This feature is an independent release from TMOS and requires updates for new configurations from time to time. To find updates and expanded use cases it will be necessary to download and install updates from https://downloads.f5.com. In this task we are going to explore the menu and take a look at a few options. We will not be deploying any of these solutions in this lab.

1. Go to Access –> Guided Configuration

2. A set of tiles appears at top listing the areas of use cases where Guided Configuration can be used

3. Click on the Federation Tile.

4. Under this tile are several Identity Federation use cases available. Each use case has an accompanying guide to walk you through the configuration. This is not designed for already deployed applications but used for new deployments. All the components needed to create the configuration will be deployed on the BIG-IP through this guide. Editing and configuring of the solution will be maintained within this menu.

5. Click on SAML Service Provider

6. Here you will find there are couple topologies. SAML SP Initiated and SAML IdP Initiated.

7. If there are any required configuration pieces missing to complete guided configuration they will appear in the right panel

8. Below the topologies you will find all the components that will be configured using the guided configured

9. From here you would click next to begin configuration. (We will explore this further in next labs)

10. Click on the Guide Configuration bread crumb at the top of the screen to return to the main menu.

11. Click on the Zero Trust tile.

12. Zero trust follows the principle never trust, always verify and thus enforces authentication and verification for every user or device attempting to access resources whether from within or outside of the network.

About Identity Aware proxy

The easiest way to create policies to support zero trust security is to use the Zero Trust-Identity Aware Proxy template in Access Guided Configuration. The template takes you through the steps needed to create an Identity Aware Proxy. Access Policy Manager (APM) acts as the Identity Aware Proxy helping to simplify client access to both multi-cloud and on-premise web applications, and securely manage access from client devices.

On APM, you can develop per-request policies with subroutines that perform different levels of authentication, federated identity management, SSO (single sign on), and MFA (multi-factor authentication) depending on the requirements. Subroutines perform continuous checking based on a specified duration or gating criteria. Policies can be as complex or as simple as you need them to be to provide seamless yet secure access to resources. Refer to Implementing Zero Trust with Per-Request Policies for many examples of per-request policies that implement different aspects of zero trust.

For additional security, device posture checking provides instantaneous device posture information. The system can continuously check clients to be sure, for example, that their antivirus, firewall, and patches meet company requirements, ensuring that the device maintains trust at all times.

On the client side, F5 Access Guard allows real-time posture information to be inspected with per-request policy subroutines. F5 Access Guard generates posture information asynchronously, and transparently transmits it to chosen APM server endpoints using special HTTP headers. Refer to BIG-IP Access Policy Manager: Configuring F5 Access Guard for details on client requirements.

13. Click on the Identity Aware Proxy configuration option

14. There are two topologies available:

Single Proxy

**Multi-Proxy **

15. Proceeding with this configuration will create a number of object as seen here.

Note

If you are interested in learning more on this specific solution please consider taking the Zero Trust Identity Aware Proxy class.

Note

Webtop is available as of version 16.0

Task 3: Overview

The Overview menu is where an administrator can view active sessions, previous sessions, and view various reports.

1. Click on Access –> Overview from the left menu

2. Here is where we would see Active Sessions. When users login to applications using APM policies the sessions will appear in this pane.

3. This is also where you will be able to kill sessions. For more on logging see next lab

4. Click on Access –> Overview –> Access Report

5. This section will give you details on the all sessions active and inactive. Each log item is a message on the policy flow as a user walks through an Access policy. (We will cover Per Session policies in in more detail later).

6. You will be prompted to enter a time period to run the report

Note

This is how you can view past sessions. Pick a time frame and run a report.

7. There are two other reporting functions in this screen, OAuth Report and SWG Reports. We will not cover these reports in this lab.

8. The last section is Event Logs.

Note

URL Request Logs is part of SWG functionality and will not be covered in this lab

9. From the top menu bar Click on the drop down next to Event Logs and choose Settings. This is where you can create logging profiles for access policies. From here you can specify what information to collect and to what detail.

10. Click the Create button

11. We will create a new APM Log profile

General Information	Name	basic_log_profile
	Enable Access System Logs	Check box
Access System Logs	Publisher	/Common/sys-db-access-publisher
	Access Policy	Debug
	ACL
	Secure Web Gateway	Notice
	OAuth	Notice
	VDI	Notice
	ADFS Proxy	Notice
	Per-Request Policy	Notice
	SSO	Notice
	ECA	Notice
	PingAccess Profile	Notice
	Endpoint Management System	Notice
Access Profile	Selected	(leave this blank for now)

Note

Within the Access System Logs section of the log profile is where you can change the logging for various portions of the APM Policies. The one you will use most will be to move Access Policy from Notice to Debug and/or Pre-Request Policy from Notice to Debug. As you can see you can pick and choose what level of notifications you want in your logs. This will impact what you see in Access Reports for a session and what appears in /var/log/apm.

12. Click OK

13. From the left menu go to Access –> Overview –> Dashboard

14. The Dashboard can give you a quick synopsis on Access Session, Network Access Session, Portal Access and Access control Lists.

Note

For more reporting on APM stats look to BIG-IQ or exporting logs to 3rd party SIEMs and create your own dashboard.

Task 4: Profile/Policies

Profiles and Policies are where we begin to learn about what makes APM function. In order for APM functions to be added to a Virtual server we need to create Access Profiles and Policies. These entities take all the components we will look at below and put them in a logical flow through the Visual Policy Editor (VPE). These entities are things like login pages, authentication, single sign on methods and endpoint checks. To being we have to create an Access Profile. Within that profile we create a per session policy. When that is completed we attach that profile to a Virtual Server.

Note

You can associate one Access Profile (which includes a per-session policy) and one per-request policy per virtual server.

Important

We will creating objects for use within this task.

1. From the left menu go to Access –> Profiles/Policies –> Access Profiles (Per-Session Policies)

The per-session policy runs when a client initiates a session. (A per-session policy is also known as an access policy.) Depending on the actions you include in the access policy, it can authenticate the user and perform other actions that populate session variables with data for use throughout the session.

2. Click on the Create button on the far right or the + sign

General Properties	Name	server1-psp
	Profile Type	All
	Profile Scope	Profile
	Customization Type	Modern
Language Settings	Accepted Languages	English

Note

Customization Type is a newer setting that changes the look and feel of login pages. For the traditional look you can Standard

3. Click Finished

4. Now we have a basic profile. There were a number of other settings to modify and use in the profile. For now we will focus just on the basics.

5. From the Access Profiles (Per-Session Policies) section locate the server1-psp

6. There are two ways to edit the Policy piece of the profile.

First way | Click on the profile | | Click on Access Policy from the top menu bar | | Click on the link to Edit Access Policy for Profile “server1-psp” | | This will take you to the Visual Policy Editor (VPE) |

Second way | Locate the server1-psp in the Profile list and follow the line to the right. | | Middle of the line there will be an Edit link | | Click the Edit link |

7. Close the VPE (we will visit the VPE and policy in more detail later)

8. Return to Access –> Profiles/Policies –> Access Profiles (Per-Session Policies)

9. Click on the server1-psp and explore the settings for the Profile.

Settings - Here you can manage settings for the profile. You may want to change timeouts, max sessions and login attempts. These are settings specifically for this profile.

Configurations - These are more advanced options and covered in other labs

Language Settings - You have to set this at creation.

Note

If you are unsure of the settings you need at profile creation you can see that you can return to the profile and make adjustments.

10. Still in the profile click on SSO/Auth Domain at the top

BIG-IP APM offers a number of Single Sign On (SSO) options. The SSO/Auth Domain tab in a Per Session Profile is where you will select what SSO method to use for your application. In Task 6 we will cover the objects that need to be created in order to associate that SSO method to a policy. At this time the drop down for the SSO Configuration will have a pre-built SSO object we will use later.

Note

We will not discuss Multi-Domain in this lab but you can find more information in later chapters

11. From the top menu bar click on Logs

12. The log profile we created earlier is now listed here. The Default log profile is attached but we can remove that and add the basic_log_profile

13. Click Update.

That concludes the review of the Per Session policy.

Note

A per session profile is required (even if it is blank) to be deployed with a per request policy

Per Request policies

1. From the left menu navigate to Access –> Profiles/Policies –> Per Request Policies

APM executes per-session policies when a client attempts to connect to the enterprise. After a session starts, a per-request policy runs each time the client makes an HTTP or HTTPS request. Because of this behavior, a per-request policy is particularly useful in the context of a Secure Web Gateway or Zero Trust scenario, where the client requires re-verification on every request, or changes based on gating criteria.

A per-request policy can include a subroutine, which starts a subsession. Multiple subsessions can exist at one time. You can use nearly all of the same agents in per-request policies that you can use in per-session policies. However, most of the agents (including authentication agents) have to be used in a subroutine in per-request policies.

2. Click Create

General Properties	Name	server1_prp_policy
	Profile Type	All
	Incomplete Action	Deny
	Customization Type	Modern
Language Settings	Accepted Languages	English

3. Click Finished

4. Click Edit

A per request policy creation will work the same way as a per session policy allowing you to add various items to the main policy and create macros. In addition a per request policy can also contain subroutines.

Note

A per-request policy subroutine is a collection of actions. What distinguishes a subroutine from other collections of actions (such as macros), is that a subroutine starts a subsession that, for its duration, controls user access to specified resources. If a subroutine has an established subsession, subroutine execution is skipped. A subroutine is therefore useful for cases that require user interaction (such as a confirmation dialog or a step-up authentication), since it allows skipping that interaction in a subsequent access.

You cannot use subroutines in macros within per-request policies. Subroutine properties specify subsession timeout values, maximum macro loop count, and gating criteria. You can reauthenticate, check for changes on the client, or take other actions based on timeouts or gating criteria.

Note

A subsession starts when a subroutine runs and continues until reaching the maximum lifetime specified in the subroutine properties, or until the session terminates. A subsession populates subsession variables that are available for the duration of the subsession. Subsession variables and events that occur during a subsession are logged. Multiple subsessions can exist at the same time. The maximum number of subsessions allowed varies across platforms. The total number of subsessions is limited by the session limits in APM (128 * max sessions). Creating a subsession does not count against the license limit.

5. If you click on the plus between Start and Allow a new box will appear and you can explore the various components that can be added. At this time we will leave the policy blank and return to populate it in later tasks.

6. Close the VPE tab when you are done exploring.

Policy Sync

1. Click on Access –> Profiles/Policies –> Policy sync

BIG-IP APM Policy Sync maintains access policies on multiple BIG-IP APM devices while adjusting appropriate settings for objects that are specific to device locations, such as network addresses. You can synchronize policies from one BIG-IP APM device to another BIG-IP APM device, or to multiple devices in a device group.

A sync-only device group configured for automatic and full sync is required to synchronize access policies between multiple devices.

Important

USE WITH CAUTION. This is an advanced feature and you should consult with your F5 Account team or Professional Services before implementing this configuration.

Note

In BIG-IP 13.1.0, a maximum of eight BIG-IP APM systems are supported in a sync-only group type.

Customization

1. Click on Access –> Profiles/Policies –> Customization

What are customization and localization?

Customization and localization are ways to change the text and the language that users see, and to change the appearance of the user interface that Access Policy Manager presents to client users. Customization provides numerous settings that let you adapt the interface to your particular operation. Localization allows you to use different languages in different countries.

About the Customization tool

The Customization tool is part of Access Policy Manager (APM). With the Customization tool, you can personalize screen messages and prompts, change screen layouts, colors, and images, and customize error messages and other messages using specific languages and text for policies and profiles developed in APM. You can customize settings in the Basic Customization view (fewer settings) or change the view to General Customization (many settings). In the General Customization view, you can use the Customization tool in the BIG-IP admin console, or click Popout to open it in a separate browser window. In either view, you can click Preview to see what an object (such as Logon page or Deny Ending Page) will look like.

After you personalize settings, remember to click the Save icon to apply your changes.

2. About basic, general, and advanced customization

The Customization tool provides three views that you can use to customize the interface. The General Customization view provides the greatest number of options and is where most of the customization takes place.

Note

See the APM Customization guide for further details on customization

3. Under Available Profiles choose the /Common/server1-psp

4. Select Language: English

5. Let’s upload a new image. Click Upload New Image

6. Browse to Desktop and locate the Lab01_images folder

7. Choose an image from the selection and click Open

8. Pick a Background color

9. Pick a Header Background color

10. Change the footer Text

11. Remember to click Save icon at the bottom

12. Click on the Preview button (At the top right)

13. Assign Access Profile server1-psp to server1-https Virtual Server under the settings in Local Traffic -> Virtual Servers -> Virtual Server List -> server1-https

14. In the browser open new tab and go to https://10.1.10.101/. What is the result? Why you are blocked and don't see any logon pages?

15. Choose Access Profiles –> /Common/server1-psp –> Access Policy –> Edit Access Policy for Profile "server1-psp" -> Edit Endings

Bonus Answer: Why don’t we see logon pages?

Hint

What is in the policy so far?

Task 5: Authentication¶

BIG-IP APM serves as an authentication gateway or proxy. As an authentication proxy, BIG-IP APM provides separate client-side and server-side authentication. Client-side authentication occurs between the client and BIG-IP APM. Server-side authentication occurs between BIG-IP APM and servers.

Loose coupling between the client-side and server-side layers allows for a rich set of identity transformation services. Combined with a Visual Policy Editor and an expansive set of access iRules functionality, BIG-IP APM provides flexible and dynamic identity and access, based on a variety of contexts and conditions.

For example, a client accessing Microsoft SharePoint through BIG-IP APM in a corporate environment may silently authenticate to BIG-IP APM with NT LAN Manager (NTLM) or Kerberos credentials. On leaving that environment, or on using a different non-sanctioned device, the client may be required to go through another potentially stronger authentication, such as a smart card or other client certificate, RSA SecurID, or one-time passcode. You can require additional device vetting such as file, folder, and registry checks and antivirus and firewall software validation.

A BIG-IP APM authentication and SSO features access and identity security posture can automatically change depending on environmental factors, such as who or where the user is, what resource the user is accessing, or when or with what method the user is attempting to gain access.

Data centers and Cloud deployments often face the challenge of offering multiple applications with different authentication requirements. You can deploy BIG-IP APM to consolidate and enforce all client-side authentication into a single process. BIG-IP APM can also perform identity transformation on the server side to authenticate to server services using the best-supported methods. This can reduce operational costs since applications remain in the most-supported and documented configurations. Common examples of identity transformation are client-side public key infrastructure (PKI) certificate to server-side Kerberos and client-side HTTP form to server-side HTTP Basic.

The following figure shows BIG-IP APM acting as an authentication gateway. Information received during pre-authentication is transformed to authenticate to multiple enterprise applications with different requirements.

1. Client-side authentication

Client-side authentication involves the client (typically a user employing a browser) accessing a BIG-IP APM virtual server and presenting identity. This is called authentication, authorization, and accounting (AAA).

BIG-IP APM supports industry standard authentication methods, including:

• NTLM
• Kerberos
• Security Assertion Markup Language (SAML)
• Client certificate
• RSA SecurID
• One-time passcode
• HTTP Basic
• HTTP Form
• OAuth 2.0
• OpenId Connect

After access credentials are submitted, BIG-IP APM validates the listed methods with industry-standard mechanisms, including:

• Active Directory authentication and query
• LDAP and LDAPS authentication and query
• Remote Authentication Dial-in User Service (RADIUS)
• Terminal Access Controller Access Control System (TACACS)
• Online Certificate Status Protocol (OCSP) and Certificate Revocation List Distribution Point (CRLDP) (for client certificates)
• Local User Database authentication

2. Go to Access –> Authentication –> Active Directory

3. Click on basic-ad-servers and review the settings. You can choose to use go direct or use a pool of AD servers.

General Properties	Name	basic-ad-servers
Configuration	Domain Name	f5lab.local
	Server Connection	Use Pool
	Domain Controller Pool Name	/Common/basic-ad-pool
	IP Address	10.1.20.7
	Hostname	dc1.f5lab.local
	Admin Name	admin
	Admin Password	admin

Note

If you choose to use a pool you can create the pool as you create the AD object. You can also choose to use Direct which allows you to only use one server. Go back and click create to see what this looks like.

You now have an object that can be used to facilitate Active Directory authentication in front of any application. The application itself does not need to require authentication. If you were to deploy a policy with AD Auth on a Virtual Server for a web application the policy would preset a login page, prompt for credentials, verify the credentials against this AD object before allowing a user to access the web application.

4. Go to Access –> Profiles/Policies –> Access Profiles (Per-Session Policies)

5. Locate the server1-psp and click Edit

6. Click the + symbol between Start and Deny.

7. From the Logon tab select the Logon Page radio button

8. Click Add Item

9. Notice that you can add fields and change the names of the fields. Click Save

10. Click the + between Logon Page and Deny

11. Click the Authentication tab

12. Choose the AD Auth radio button and click Add Item

13. Under the Server field click on the drop down menu and choose the AAA server basic-ad-servers

14. Click Save

15. On the Success branch click on the Deny end point and choose Allow then click Save

16. Click Apply Access Policy

Now you have a basic policy with AD Authentication that you can leverage for Web Pre-Authorization in front of any application.

17. Go to Local Traffic –> Virtual Servers

18. Locate server1-https and click on it

19. Scroll down to the Access Policy section. Next to Access Profile click the drop and chose server1-psp

20. Scroll down to the bottom and click Update

21. In a new browser tab go to http://server1.acme.com and Login

username	user1
password	user1

22. After correct login attempt you should see ACME backend app.

23. Review Access Session logs and reports.

Task 6: Single Sign-On

Note All the objects used to demonstrate Server-side Single Sign-On have already been created. The next steps will walk you through what the configuration looks like.

Client side and server side are loosely coupled in the authentication proxy. Because of this, BIG-IP APM can transform client-side identity values of one type into server-side identity values of another type. You configure SSO within an SSO profile, which is applied to an access profile. The system triggers SSO at the end of successful access policy evaluation and on subsequent client-side requests.

BIG-IP APM supports industry standard authentication methods, including:

• NTLM
• Kerberos
• HTTP Basic
• HTTP Form
• Security Assertion Markup Language (SAML)

Note

Client-side authentication methods outnumber server-side methods. This is because BIG-IP APM does not transmit client certificate, RSA SecurID, or one-time passcodes to the server on the client’s behalf.

1. Go to Access –> Single Sign-On –> HTTP Basic

2. Click basic-sso

General Properties	Name	basic-sso
Credential Source	Username Source	session.sso.token.last.username
	Password Source	session.sso.token.last.password
SSO Method Conversion	Username Conversion unchecked

Note

Username conversion can be enabled if you want domain\username or username@domain to convert to just username.

3. Click on Access –> Profiles/Policies –> Access Profiles (Per-Session Policies)

4. Locate the basic-psp profile and click on the name

5. Click on SSO/Auth Domains

6. Under SSO Configuration notice basic_sso is selected

7. From the top menu bar click Access Policy and click Edit Access Policy for Profile “basic-psp” link

8. Click on SSO Credential Mapping

Note

You can modify these options based on the variables collected in the user’s session. In this case we accept the defaults.

9. Open an incognito window and try go to https://basic.acme.com

10. You should have been prompted with a windows login. Close the Window

11. Go to Local Traffic –> Virtual Servers and open basic-https

12. Scroll to Access Policy and click the drop down next to Access Profile. Choose basic-psp

13. Scroll down click Update

14. Open a new incognito tab. Go to https://basic.acme.com

15. Login user1 and user1

16. Now you should have been signed in to the backend server with Single Sign On.

Task 7: Federation

Note

In this task we will examine SAML IDP and SP configuration. All the configuration has been completed the next several steps you will just be examining the objects and testing the configuraiton. For more in depth instruction on Federatoion consider taking a 300 series course.

BIG-IP APM federation with SAML

BIG-IP APM supports SAML 2.0 and can act as the IdP for popular SPs, such as Microsoft Office 365 and Salesforce. The system supports both IdP- and SP-initiated identity federation deployments.

IdP-initiated federation with BIG-IP APM

• The user logs in to the BIG-IP APM IdP and the system directs them to the BIG-IP APM webtop.
• The user selects the SP they want, such as Salesforce.
• The system retrieves any required attributes from the user data store to pass on to the SP.
• The system uses the browser to direct the request to the SP, along with the SAML assertion and any required attributes.

1. In a new tab go to https://idp.acme.com

2. Login to the SAML IdP

username	user1
password	user1

3. You are logged in to a webtop where a SAML SP object resides. Click on the SAML Resource sp.acme.com

4. Since you authenticated through the SAML IdP you will not be prompted for authentication again and are connected to the SAML SP resource.

5. Return to bigip1.f5lab.local. From the left menu click Access –> Profiles/Policies –> Access Profiles (Per-Session Policies)

6. Locate the policy idp-psp and click on Edit

7. Click AD Auth* object within the Policy. Examine the settings

Note

If you look at the AAA server under Active directory you will find the idp-ad-server object. We are leveraging Active Directory as the credential verification but BIG-IP is acting as a SAML Identity Provider. BIG-IP will verify the credentials against Active Directory and create a SAML Assertion for the user requesting access. That assertion can then be used by the SAML Service Provider to provide access to the SAML SP resource.

8. Click Advanced Resource Assign. Examine the settings

Note

You can click on the Add/Delete button and add other SAML Resources (if available). We will cover more on Webtop in next labs.

9. Return to the BIG-IP click on Access –> Federation –> SAML Identity Provider

In order for the BIG-IP to be configured as a SAML IdP you must define the Identity provider and bind it with a SAML Service Provider. This object contains the settings required to configure BIG-IP as a SAML SP. For more information on SAML and uses with BIG-IP consider taking the Federation lab.

Note

You can export the Metadata of the SAML IdP in this menu by clicking the SAML IdP and clicking the Export Metadata button. It will output an XML file that you can use to upload in to a SAML Service Provider with all the IdP setting particular to this IdP.

SP-initiated federation with BIG-IP APM

• The user logs in to the SP, such as Salesforce.
• The SP uses the browser to redirect the user back to the BIG-IP APM IdP.
• The BIG-IP APM IdP prompts the user to log in.
• The system retrieves any required attributes from the user data store to pass on to the SP.
• The system uses the browser to send the SAML assertion and any required attributes to the SP.

1. Open a new incognito window and go to https://sp.acme.com

2. Notice that you get redirected to https://idp.acme.com for authentication

username	user1
password	user1

3. Once logged in you arrive at https://sp.acme.com

4. Return to the BIG-IP. From the left menu navigate to Access –> Profiles/Policies –> Access Profiles (Per-Session Policies)

5. Locate the sp-psp profile and cick Edit

6. Return to the BIG-IP and navigate to Access –> Federation –> SAML Service Provider

The SAML SP object contains information about the SAML SP object and the binding to the SAML Identity Provider. You can see on the screen that we have a Service Provider object defined and it is bound to a SAML Identity Provider. The configuration of these objects is covered in more detail in the Access Federation labs.

Task 8: Connectivity/VPN

Note In interest of time the VPN configuration has already been completed. The next several steps will be observing what the configuration looks like and testing out the connectivity.

Policy Walk-Through

1. Navigate to Access –> Profiles/Policies –> Access Profiles (Per-Session Policies)

2. Locate profile vpn-psp and click on Edit. This opens the Visual Policy Editor (VPE) and we can take a look at the policy

3. A user enters their credentials into the logon page agent. - Those credentials are collected, stored as the default system session variables of session.logon.last.username and session.logon.last.password.

4. The AD Auth Agent validates the username and password session variables against the configured AD Domain Controller.

5. The user is assigned resources defined in the Advanced Resource Assign Agent

6. The user is granted access via the Allow Terminal

7. If unsuccessful, the user proceeds down the fallback branch and denied access via the Deny Terminal

Policy Agent Configuration

The Logon Page contains only the default setting

The AD Auth agent defines the AAA AD Servers that a user will be authenticated against. All Setting are the default.

The Advanced Resource Assign agent grants a user access to the assigned resources.

Supporting APM Objects

Network Access Resource

Navigate to Access –> Connectivity/VPN –> Network Access (VPN) –> Network Access Lists

Click the vpn Network Access Profile

The Properties page contains the Caption name VPN. This is the name displayed to a user.

• The Network Settings tab assigns the lease pool of ip addresses that will be used for the VPN.

• Split Tunneling is configured to permit only the 10.1.20.0/24 subnet range inside the VPN.

Lease Pool

Navigate to Access –> Connectivity/VPN –> Network Access (VPN) –> IPV4 Lease Pools

Click vpn-vpn_pool lease pool object

A single address of 10.1.20.254 is assigned inside the lease pool.

Webtop Sections

Navigate to Access –> Webtops –> Webtop Sections

Click on vpn-network_access

A single section is configured to display a custom name.

Webtop Lists

Navigate to Access –> Webtops –> Webtop Lists

Click on vpn-webtop

• A Full Webtop was defined with modified default settings.
• The Minimize to Tray box is checked to ensure the Webtop is not displayed when a user connects to the VPN.

The Policy from a user’s perspective

1. The connects to https://vpn.acme.com with the following credentials

username	user1
password	user1

2. Once authenticated the user is presented a Webtop with a single VPN icon.

3. Assuming the VPN has already been installed the user is notified that the client is attempting to start

Note

You may be prompted to download the VPN update. This is what a user will experience if you have auto-update enabled in the VPN Connectivity Profile. Click Download and wait for the components to update.

4. A popup opens displaying the status of the VPN connection. The status will eventually become Connected

Note

If you lose the pop-up check the system tray for the little red ball. Right click and choose restore

5. Click Disconnect

Note

For more information on API Protection consider taking the API Protection lab. For more information on SWG, ACL and Webtops see the appendix or further APM labs.

Task 9: Lab Cleanup

1. Open a new tab and click on the Access: PORTAL bookmark then select CLASSES

2. Locate the APM GUI Overview Tile and click on the Stop button

3. Wait about 30 seconds for the processing to begin

4. This process will take up to 30 seconds. Scroll to the bottom of the script and verify no issues.

Module 1 is now complete.

Module 2

Module 2: Building a Basic Access Policy

The environment is the same, but you will have to build the configuration with Postman/Newman scrits automating the configuration.

1. Click the Classes tab at the top of the page.

2. Scroll down the page until you see 102 Access Building Blocks on the left

3. Hover over tile Building a Basic Acces Policy. A start and stop icon should appear within the tile. Click the Play Button to start the automation to build the environment

4. After the click it may take up to 30 seconds before you see processing

5. Scroll to the bottom of the automation workflow to ensure all requests succeeded.

Intro to Access Profiles and Policies

Access Policy Manager (APM) provides two types of policies.

Per-session policy

The per-session policy runs when a client initiates a session. (A per-session policy is also known as an access policy.) Depending on the actions you include in the access policy, it can authenticate the user and perform other actions that populate session variables with data for use throughout the session. Per-request policy

After a session starts, a per-request policy runs each time the client makes an HTTP or HTTPS request. Because of this behavior, a per-request policy is particularly useful in the context of a Zero Trust scenario, where the client requires re-verification on every request. A per-request policy can include a subroutine, which starts a subsession. Multiple subsessions can exist at one time. You cannot use subroutines in macros within per-request policies.

You can associate one access policy and one per-request policy with a virtual server.

Access Session

An access session is recorded when a client initiates a connection through a per-session policy. Once an access session is established it has a set of timeouts set within the Access profile. A session will terminate if it reaches a timeout or the client ends the session. An access session is now not limited by a license but by the platform running APM. For more information on APM licensing see K15624537: BIG-IP APM Licensing for BIG-IP Standard Platforms

Subsession

A subsession is part of the per-request policy framework. It starts when a subroutine (within a per-request policy) runs and continues until reaching the maximum lifetime specified in the subroutine properties, or until the session terminates. A subsession populates subsession variables that are available for the duration of the subsession. Subsession variables and events that occur during a subsession are logged.

Multiple subsessions can exist at the same time. The maximum number of subsessions allowed varies across platforms. The total number of subsessions is limited by the session limits in APM (128 * max sessions). Creating a subsession does not count against the license limit.

Objectives

The lab has a pre-configured test Virtual Server which will be used throughout the lab. You will use the Visual Policy Editor (VPE) to create and attach a simple Access Profile which performs user authentication.

Lab Requirements

• A pre existing virtual server at 10.1.10.101 or https://app.acme.com

Task 1: Define an Authentication Server

Before we can create an access profile, we must create the necessary AAA server profile for our Active Directory.

1. Click the bigip1 bookmark from within Chrome and login to the BIG-IP, admin/admin

2. From the main screen, browse to Access > Authentication > Active Directory

3. Click Create in the upper right-hand corner

4. Configure the new server profile as follows:

Name:	lab_sso_ad_server
Domain Name:	f5lab.local
Server Connection:	Direct
Domain Controller:	10.1.20.7
User Name:	admin
Password:	admin

5. Click Finished

Note

If you wish you can simply use the **app-ad-servers**.

Task 2: Create a Simple Access Profile¶

1. Navigate to Access > Profiles / Policies > Access Profiles (Per-Session Policies)

2. From the Access Profiles screen, click Create… in the upper right-hand corner

3. In the Name field, enter MyAccessPolicy and for the Profile Type, select the dropdown and choose All

4. Under “Language Settings”, choose English and click the << button to slide over to the Accepted Languages column.

5. Click Finished, which will bring you back to the Access Profiles screen.

6. On the Access Profiles screen, click the Edit link under the Per-Session Policy column.

The Visual Policy Editor (VPE) will open in a new tab.

7. On the VPE page, click the + icon on the fallback path, to the right of the Start object.

8. On the popup menu, choose the Logon Page radio button under the Logon tab and click Add Item

9. Accept the defaults and click Save

Now let’s authenticate the client using the credentials to be provided via the Logon Page object.

10. Between the Logon Page and Deny objects, click the + icon, select AD Auth found under the Authentication tab, and click the Add Item button

11. Accept the default for the Name and in the Server drop-down menu select the AD server created above: /Common/lab_sso_ad_server, then click Save

12. On the Successful branch between the AD Auth and Deny objects, click on the word Deny to change the ending

13. Change the Successful branch ending to Allow, then click Save

14. In the upper left-hand corner of the screen, click on the Apply Access Policy link, then close the window using the Close button in the upper right-hand. Click Yes when asked Do you want to close this tab?

Task 3: Associate Access Policy to Virtual Servers¶

Now that we have created an access policy, we must apply it to the appropriate virtual server to be able to use it.

1. Navigate to Local Traffic –> Virtual Servers –> Virtual Server List and click the name of the virtual server created previously: app-https

2. Scroll down to the Access Policy section, for the Access Profile dropdown, select MyAccessPolicy

3. Click Update at the bottom of the screen

Task 4: Testing

Now you are ready to test.

1. Open a new browser window and open the URL for the virtual server that has the access policy applied:

https://app.acme.com

You will be presented with a login window

2. Enter the following credentials and click Logon:

username	user1
password	user1

You will see a screen similar to the following:

Task 5: Troubleshooting tips

You can view active sessions by navigating Access/Overview/Active Sessions

You will see a screen similar to the following:

Click on the session id for the active session. If the session is active it will show up as a green in the status.

Click on the “session ID” next to the active session. Note every session has a unique session id. Associated with it. This can be used for troubleshooting specific authentication problem.

Once you click on the session id you will be presented with a screen that is similar to the following.

Note that the screen will show all of the log messages associated with the session. This becomes useful if there is a problem authenticating users.

The default log level shows limited “informational” messages but you can enable debug logging in the event that you need to increase the verbosity of the logging on the APM policy. Note you should always turn off debug logging when you are finished with trouble shooting as debug level logging can generate a lot of messages that will fill up log files and could lead to disk issues in the event that logging is set to log to the local Big-IP.

Please review the following support article that details how to enable debug logging.

https://support.f5.com/csp/article/K45423041

Step up Authentication with Per-Request Policies

Objectives

The purpose of this lab is to familiarize the Student with Per Request Policies. The F5 Access Policy Manager (APM) provides two types of policies.

Access Policy - The access policy runs when a client initiates a session. Depending on the actions you include in the access policy, it can authenticate the user and perform group or class queries to populate session variables with data for use throughout the session. We created one of these in the prior lab

Per-Request Policy - After a session starts, a per-request policy runs each time the client makes an HTTP or HTTPS request. A per-request policy can include a subroutine, which starts a sub-session. Multiple sub-sessions can exist at one time. One access policy and one per-request are specified within a virtual server.

It’s important to note that APM first executes a per-session policy when a client attempts to connect to a resource. After the session starts then a per-request policy runs on each HTTP/HTTPS request. Per-Request policies can be utilized in a number of different scenarios; however, in the interest of time this lab will only demonstrate one method of leveraging Per-Request policies for controlling access to specific URI’s and submitting information from Active Directory as a header to the application.

Objective:

• Gain an understanding of Per Request policies
• Gain an understanding of use for Per Request Policy

Lab Requirements:

All lab requirements will be noted in the tasks that follow

• Estimated completion time: 15 minutes

TASK 1: Create Per Session Policy

Refer to the instructions and screen shots below:

1. Login to your lab provided Virtual Edition BIG-IP

   • On your jumphost launch Chrome and click the bigip1 link from the app shortcut menu
   • Login with credentials admin/admin

2. Begin by selecting: Access -> Profiles/Policies -> Per Session Policies ->

3. Click the + Sign next to Access Profiles (Per-Session Policies)

4. Enter the name of the policy, profile type, and profile scope

Name:	app.acme.com-PSP
Profile Type:	All
Profile Scope:	Profile
Accept Languages:	English (en)

Note

You will need a per session policy and a per request policy but we will be leaving the per session policy blank and performing our auth in per Request

5. On the app.acme.com-PSP policy click Edit

6. Click on the Deny and change the Select Ending to Allow

7. Click Save

8. Click Apply policy

Note

Nothing will be set in this policy we will simply establish a session and manage all the authentication in the Per-Request Policy

9. Close Visual Policy Editor

Task 2: Step Up Authentication with Per Request Policies

Step-up authentication can be used to protect layers or parts of a web application that manage more sensitive data. It can be used to increase protection by requiring stronger authentication within an already authenticated access to the web application. Step-up authentication can be a part of using the portal access or web application management (reverse proxy) features of Access Policy Manager.

In this example we’re going to use a Per-Request Policy with a subroutine to authenticate user when they access a specific URI, extract information from Active Directory and submit that information as a header

1. Begin by selecting: Access -> Profiles/Policies -> Per Request Policies ->

2. Click the Create button (far right)

3. Give the policy a name and select the Language Settings

Name:	app.acme.com-PRP
Accept Languages:	English (en)

4. Click Finished

5. Back in the Access –> Profiles/Policies –> Per-Request Policies screen locate app.acme.com-PRP policy you just created.

6. Click Edit to the right of the name

7. Click on Add New Subroutine

8. Give it a name of AD_Subrutine and Click Save

When you edit created subrutine once again click Subrutine Settings / Rename

9. Click the + between In and Out In the subroutine

10. Click the Logon Tab

11. At the middle of the list choose Logon Page and click Add Item

12. Select Save at the bottom of the Logon Page dialog box

13. In the subroutine, between the Logon page and the green out terminal click the + and select the Logon Tab and click the Logon Page radio button

14. Click the + sign between Logon Page and Out and select the Authentication tab and click the AD Auth radio Button

15. Select AD Auth and click Add Item at the bottom

16. Give the item a name of AD_Auth

17. Select /Common/lab_sso_sd_server for the Server option

Note

The lab_sso_ad_server object was created in previous lab

18. Click the Save

19. Between AD Auth and the Out endpoint click the + Sign

20. Select Authentication and Select the AD Query radio button and click Add Item

21. Change the Server option to /Common/lab_sso_ad_server and click Save

22. Between AD Query and the Out endpoint click the + Sign

23. Navigate to the Assignment tab and select Variable Assign and click Add Item

24. Under Variable Assign click Add New Entry

25. Next to “Empty” click the Change link

26. Change the drop down on the right hand side to Session Varaible and input the following value subsession.ad.last.attr.memberOf

27. In the left hand box type the following value session.adgroups.custom and then click Finished and Save

28. Click the + sign between Start and Allow directly under the Per Request Policy at the top of the page

29. Select the Classification tab, click the URL Branching Radio Button and click Add Item

30. Click the Branch Rules tab and then click the change hyperlink

31. Change the value domain.com to app.acme.com/apps/app1/ and click finished

32. Change the name from Allow to /apps/app1/ and then click Save

33. Click the + sign after the /apps/app1/ branch you just added and select the subroutines tab and click the AD_Subroutine radio button and click Add Item

34. Click the + sign after the AD_Subroutine Box you just added and select the General Purpose tab and click the HTTP Headers radio Button

35. Under HTTP Header Modify, click Add new entry

36. Type AD_Groups for header name and %{session.adgroups.custom} for Header Value and click Save

37. In the Per-Request Policy follow the fallback branch for the URL Branching. Click on the Reject terminal and change to Allow

38. Your Per-Request Policy should now look like this

39. Navigate back to Local Traffic -> Virtual Servers and select your VIP, under the Access policy section of your VIP bind your Per-Session and Per Request policies

40. In a browser on your jumphost access https://app.acme.com you should see the webpage listed below, click the Application1 link

41. Authenticate with the user1 username and user1 password

42. Notice the Ad-Groups header which contains the extracted AD group information submitted to the application as a HTTP Header

What we have demonstrated here is the application of step-up authentication to a portion of the webpage, from there we extracted information from Active Directory to submit to the application in the form of an HTTP Headers

Module 2 is now complete.

Module 3

Module 3: Server-Side Single Sign-On and Webtop Access Policy Build

The purpose of this lab is to demonstrate Single Sign-On capabilities of APM. The SSO Credential Mapping action enables users to forward stored user names and passwords to applications and servers automatically, without having to input credentials repeatedly. This allows single sign-on (SSO) functionality for secure user access. As different applications and resources support different authentication mechanisms, the SSO system may be required to store and transform credentials to meet these requirements. For example, username and password may be transformed into forms-based authentication, a SAML assertion into Kerberos or Kerberos authentication into SAML.

Although a number of different SSO methods exist, this lab will demonstrate access single SSO method certificate authentication on the client side to Kerberos authentication to the backend server

Objective:

• Gain an understanding of authentication transformation through APM, client side vs server side
• Gain an understanding of the leveraging different auth methods
• Develop an awareness of the different deployment models for single sign on

Lab Requirements:

Virtual Servers policies and configuration for this lab were completed through the automation run in previous lab. We will review the components involved in this SSO solution.

Estimated completion time: 15 minutes

Task 1: Policy review

Note All the objects and configuration have been completed for you. In this lab we will explore the configuration and test.

1. From the jumphost launch Chrome and login to bigip1.f5lab.local as admin/admin

2. Navigate to Access -> Profiles/Policies -> Access Profiles (Per-Session Policies)

3. Locate solution6-psp and click Edit

Let’s walk through the policy flow:

• A user is prompted to select their certificate.
• The validation of the user certificates is controlled via CA bundles selected in the Client-side SSL Profile.
• The certificate is validated by OCSP if the user presents a certificate issued by a trusted CA
• The othername field is extracted from the certificate
• A LDAP query is performed to collect the sAMAccountName of the user
• The domain and username variables are set
• The user is granted access via the Allow Terminal
• If the LDAP Query is unsuccessful, the user proceeds down the fallback branch to the Deny Terminal
• If the OCSP check is unsuccessful, the user proceeds down the fallback branch to the Deny Terminal
• If the user fails to present a certificate, the user proceeds down the fallback branch to the Deny Terminal

Task 2: Supporting APM Objects review

1. Navigate to Access -> Authentication -> OCSP Responder and click on the AAA OCSP Responder object solution6-ocsp-servers

2. Change the configuration from Basic to Advanced. The OCSP Responder has been configured with the following settings:

   • URL: this field is only used if you check the Ignore AIA field
   • Certificate Authority File: contains the root ca bundle
   • Certificate Authority Path: this field is only used if you check the Ignore AIA field
   • The rest of the settings are default

3. Navigate to Access -> Authentication -> LDAP for the AAA LDAP Object

4. Click on solution6-ldap-servers. A single LDAP server of 10.1.20.7 has been configured with a admin service account to support queries

5. Navigated to Access -> Single Sign-On -> Kerberos and review the Kerberos SSO Object solution6-kerbsso

   • The Username Source field has been modified from the default to reference the sAMAccountName stored in session.logon.last.username
   • Kerberos Realm has been set to the Active Directory domain (realms should always be in uppercase)
   • The service account used for Kerberos Constrained Delegation (Service Account Names should be in SPN format)
   • SPN Pattern has been hardcoded to HTTP/solution6.acme.com (This is only necessary if the SPN doesn’t match the FQDN typed in the web browser by the user)

Task 3: Access Profile Configuration

1. Navigate to Access -> Profiles/Policies -> Access Profiles (Per-Session Policies) and locate the solution6-psp profile. Click on the profile and review the customized APM Profile Settings

2. Click on the SSO/Auth Domains of the APM profile and note it is configured with the Kerberos SSO Profile which will be used to authenticate to the backend server.

3. Click on Access Policy and the Edit Access Policy for Profile “solution6-psp” link

Note

`You can also see from this screen any AAA server objects associated with this profile/policy. You can see we will be using the OCSP responder.

4. Click on the On-Demand Cert Auth box in the VPE. The agent uses the default settings of Auth Mode = Request

5. Click Cancel

6. Click on the OCSP Auth box. The OCSP Agent validates the certificate against the OCSP responder configured

7. Click Cancel

8. Click the upn extract box. Under Assignment click on the Change link

9. Note that a custom variable will be created called session.custom.upn. We will write an expression that will extract the othername:UPN field from the certificate for a new custom variable.

set x509e_fields [split [mcget {session.ssl.cert.x509extension}] "n"];
# For each element in the list:
foreach field $x509e_fields {
# If the element contains UPN:
if { $field contains "othername:UPN" } {
## set start of UPN variable
set start [expr {[string first "othername:UPN<" $field] +14}]
# UPN format is <user@domain>
# Return the UPN, by finding the index of opening and closing brackets, then use string range to get everything between.
return [string range $field $start [expr { [string first ">" $field $start] - 1 } ] ];  } }
# Otherwise return UPN Not Found:
return "UPN-NOT-FOUND";

10. Click Cancel twice

11. Click the LDAP Query box. The LDAP query connects to the LDAP server to the dc=f5lab,dc=local DN for a user that contains the userPrincipalName matching the value stored in session.custom.upn.

12. You can see that we are using the AAA LDAP object created early to validate the variable** session.custom.upn**. The LDAP query requests the sAMAccountName attribute if the user is found.

13. Click on Branch Rules. The branch rule was modified to only require a LDAP Query passed condition

14. Click Cancel

15. Click the set_variables box. Two session variables are set

• session.logon.last.username is populated with the value of the sAMAccountName returned in the LDAP query
• session.logon.last.domain is populated with a static value for the Active Directory domain F5LAB.LOCAL

Task 4: Customized LTM Profile settings

We will need to make some modifications to the client SSL profile to accommodate Certificate authentication.

1. Navigate to Local Traffic from the left menu. Under Partitions select the drop down and choose solution6. This will change the partition so that you can see the LTM objects used in this lab.

Note

We deployed the LTM objects in to another administrative partition for the purposes of separating the objects. If you were to deploy this in your own environment using a partition is not a requirement.

2. Navigate to Local Traffic -> Profiles -> SSL -> Client. Click on solution6-clientssl.

3. In he Client-side SSL profile scroll down to the Client Authentication section and notice it has been modified to support certificate authentication

Trusted Certificate Authorities has been set to ca.f5lab.local

• The bundle validates client certificates by these issuers
• The bundle must include all CAs in the chain

Advertised Certificate Authorities has ben set to ca.f5lab.local

• The bundle controls which certificates are displayed to a user when they are prompted to select their certificate

Task 5: Logging in from a user’s perspective

1. Open an incognito window in the Chrome browser and access https://solution6.acme.com

2. You will be presented with three possible certificates. Choose User1 and click OK

3. If successful the user is granted access to the application

Task 5: Webtop Access Policy Build - Create a Webtop resource

In this lab, we will add a Webtop resource to the Access Policy created in the previous lab. A full webtop provides an access policy ending for an access policy branch to which you can optionally assign portal access resources, app tunnels, remote desktops, and webtop links, in addition to network access tunnels. Then, the full webtop provides your clients with a web page on which they can choose resources, including a network access connection to start.

1. Expand the Access tab from the main menu on the left and navigate to Webtops > Webtop Lists.

2. Click Create to create a new Webtop called MyFullWebtop, select Type Full , uncheck Minimize To Tray and click Finished.

Task 6: Create Webtop Item

1. Browse to Access > Webtops >** Webtop Link** and click create.

2. Complete the following entries.

   • Name: F5Rocks
   • Link Type Dropdown: Application URI
   • Applicatoin URI : https://www.f5.com
   • Application Caption : F5 Rocks.

Task 7: Add Webtop resource to existing Access Policy

1. Browse to Access > Profiles / Policies > Access Profiles (Per-Session Policies), click on Edit for MyAccessPolicy. A new tab should open to the Visual Policy Editor for MyAccessPolicy.

2. In between the AD Auth APM Item and the Allow APM item click the + option to add an item.

3. Select the Advanced Resource Assign object. Click on the “Assignment Tab” and select the “Advanced Resource Assign” radio button. Click Add Item.

4. Then Click the “Add New Entry” button.

5. Then under the “Expression Section” click the “Add/Delete” button

6. Click on the Webtop tab, select the radio button for MyFullWebtop. Click on the Webop Links tab, and select the radio button for F5Rocks then click the Update button at the bottom of the screen.

7. Click Save.

8. At the top left of the browser window, click on Apply Access Policy, then close the tab. Replace the Access Profile on your app-https VIP with your myaccesspolicy Access profile and set the Per-Request Policy to None

9. Navigate to Local Traffic –> Virtual Servers –> Virtual Server List

Note

`Make sure you are in the Common Partition`

![image](https://user-images.githubusercontent.com/51786870/210735880-e6eb387a-f708-4eaa-9751-e5d09dc4e6b9.png)

10. Open the app-https Virtual server, scroll down to the Access Policy section and ensure that MyAccessPolicy has been assigned to this virtual server.

Task 8: Testing

1. Open a New Incognito web browser to the virtual server created in the previous lab by navigating to https://app.acme.com. You will be presented with a Logon page similar to the one from the last lab.

2. Enter the following credentials:

Username:	user1
Password:	user1

3. Click Logon.

This will open the APM Webtop landing page that shows the resources you are allowed to access. In this lab, we’ve only configured one resource:

F5 Rocks, but you can add as many as you want and they will appear on this Webtop page.

Task 9: Lab Cleanup

1. Open a new tab and click on the Access: PORTAL bookmark then select CLASSES

2. Locate the 102 Access Building Blocks Tile and click on the Stop button

3. Wait about 30 seconds for the processing to begin

4. This process will take up to 30 seconds. Scroll to the bottom of the script and verify no issues.

Module 3 is now complete.

Module 4 Part 1

Module 4: Part 1 - SAML SP Access Guided Configuration (AGC)

The purpose of this lab is to configure and test SAML Federation Services. This lab will be configured in two parts.

Students will leverage Access Guided Configuration (AGC) to configure the various aspects of a SAML Service Provider (SP), import and bind to a SAML Identity Provider (IdP) and test SP-Initiated SAML Federation.

Objective:

• Gain an understanding of SAML Federation configurations and their component parts through Access Guided Configuration (AGC)
• Gain an understanding of the access flow for IDP & SP Initiated SAML

Lab Requirements:

• All Lab requirements will be noted in the tasks that follow
• Estimated completion time: 25-30 minutes

Task 1 - Setup Lab environment

1. Open Chrome browser and launch the site https://portal.f5lab.local.

2. Click the Classes tab at the top of the page.

3. Scroll down the page until you see 202 - Federation on the left

4. Hover over tile SAML SP Access Guided Configuration(AGC) Lab. A start and stop icon should appear within the tile. Click the Play Button to start the automation to build the environment

10. The screen should refresh displaying the progress of the automation within 30 seconds. Scroll to the bottom of the automation workflow to ensure all requests succeeded.

Task 2: Configure a SAML Service Provider (SP) via AGC

1. Navigate to Access -> Guided Configuration in the left-hand menu.

2. Once Guided Configuration loads, click on Federation.

3. In the resulting Federation sub-menu click, SAML Service Provider.

4. In the resulting SAML Service Provider window, review the (SP-Initiated) flow and then click the right arrow.

5. Review the IdP-Initiated flow and then scroll down to the bottom of the window.

6. Review the configuration objects to be created and the click Next.

Task 3: Configure the Service Provider

1. In the Service Provider Properties section, enter the following values in the fields provided:

   • In the Configuration Name field input sp.acme.com.
   • In the Entity ID field input https://sp.acme.com.

2. In the Security Settings section, check the checkbox next to Sign Authentication Requests.

3. In the updated Security Settings section, use the dropdowns to select the following:

   • For the Message Signing Key select sp.acme.com.
   • For the Message Signing Certificate select sp.acme.com.

4. Click Save & Next.

Task 3: Configure the Virtual Server

1. In the Virtual Server Properties section, enter the following values in the fields provided:

   • In the Destination Address field input 10.1.10.103.
   • In the Service Port field input 443 HTTPS
   • In the Redirect Port field input 80 HTTP

2. In the Client SSL Profile section, use the arrows to move only the wildcard.acme.com profile to the right-hand column as shown.

3. Click Save & Next.

Task 4: Configure External IdP Connector¶

1. In the External Identity Provider Connector Settings section, use the first dropdown Select Method to configure your IdP Connector to select Metadata.

2. In the updated window, click the Choose File button and then browse the Jumphost desktop and select the file idp_acme_com.xml.

3. In the Name field, input idp.acme.com

4. Click Save & Next.

Task 5: Configure Pool

1. Click Show Advanced Setting in the upper right of the Guided Configuration.

2. In the Pool Properties section, use the dropdown to select Create New for Select a Pool.

3. In the Health Monitors section, use the arrows to move only the /Common/http health monitor to the right-hand column as shown.

4. In the Resource Properties section, use the dropdown to select Least Connections (member) for Load Balancing Method.

5. For the Pool Servers section, use the first dropdown for IP Address/Node Name to select /Common/10.1.20.6. Ensure port 80 and HTTP are set for the Port.

6. Click Save & Next.

Task 6: Configure SSO

1. In the Single Sign-On Settings section, check the Enable Signle Sign-On checkbox.

2. Use the Selected Single Sign-On Type dropdown to select HTTP header-based.

3. In the Header Value field, ensure session.saml.last.identity is present.

4. In the SSO Headers section, makes sure the following values are correct:

   • Header Operation: replace
   • Header Name: Authorization
   • Header Value: %{session.saml.last.identity}

5. Scroll to the bottom of the window and Click Save & Next.

Task 7: Configure Endpoint Checks

1. In the Endpoints Checks Properties window, click Save & Next.

Task 8: Configure Session Management

1. Review the Session Managment settings, in the Timeout Settings section then scroll to the bottom of the window and click Save & Next.

Task 9: Review the Summary and Deploy

1. Review the Summary, then scroll to the bottom of the window and click Deploy.

2. The application is now deployed click Finish.

3. Review the Access Guided Confguration window, Status for sp.acme.com is DEPLOYED.

Task 10: Testing the SAML Service Provider (SP)

1. Open Firefox from the Jumphost desktop and navigate to https://sp.acme.com

Note

If you have issues, open Firefox in a New Private Window (Incognito/Safe Mode)

2. Once the page loads, enter user1 for username and user1 for password in the Secure Logon form and click the Logon button.

3. The sp.acme.com application will now open if successfully configured.

Task 11: Lab CleanUp

1. Navigate to Access -> Guided Configuration in the left-hand menu.

2. Click the Undeploy button

3. Click OK when asked, “Are you sure you want to undeploy this configuration?”

4. Click the Delete button once the deployment is undeployed

5. Click OK when asked, “Are you sure you want to delete this configuration?”

6. The Configuration section should now be empty

7. From a browser on the jumphost navigate to https://portal.f5lab.local

8. Click the Classes tab at the top of the page.

9. Scroll down the page until you see 202 - Federation on the left

10. Hover over the tile SAML SP Access Guided Configuration(AGC) Lab. A start and stop icon should appear within the tile. Click the Stop Button to start the automation to delete any prebuilt objects

11. The screen should refresh displaying the progress of the automation within 30 seconds. Scroll to the bottom of the automation workflow to ensure all requests succeeded.

This concludes Part 1

Module 4 Part 2

Module 4: Part 2 - SAML Identity Provider (IdP) - Certificate Auth

To access your dedicated student lab environment, you will need a web browser and Remote Desktop Protocol (RDP) client software. The web browser will be used to access the Unified Demo Framework (UDF) Training Portal. The RDP client will be used to connect to the jumphost, where you will be able to access the BIG-IP management interfaces (HTTPS, SSH).

Estimated completion time: 25 minutes

Task 1 - Setup Lab Environment

1. Open the site https://portal.f5lab.local.

2. Click the Classes tab at the top of the page.

3. Scroll down the page until you see 301 SAML Federation on the left

4. Hover over tile SAML Identity Provider (IdP) - Cert Auth. A start and stop icon should appear within the tile. Click the Play Button to start the automation to build the environment

5. The screen should refresh displaying the progress of the automation within 30 seconds. Scroll to the bottom of the automation workflow to ensure all requests succeeded.

Task 2 ‑ Configure the SAML Identity Provider (IdP)

IdP Service

1. Begin by selecting: Access ‑> Federation ‑> SAML Identity Provider ‑> Local IdP Services

2. Click the Create button (far right)

3. In the** Create New SAML IdP Service** dialog box, click General Settngs in the left navigation pane and key in the following:

   • IdP Service Name: idp.acme.com
   • IdP Entity ID: https://idp.acme.com

Note

The yellow box on “Host” will disappear when the Entity ID is entered

4. In the Create New SAML IdP Service dialog box, click Assertion Settings in the left navigation pane and key in the following:

   • Assertion Subject Type: Persistent Identifier (drop down)
   • Assertion Subject Value: %{session.logon.last.username} (drop down)
   • Authentication Context Class Reference urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI

5. In the Create New SAML IdP Service dialog box, click Security Settings in the left navigation pane and key in the following:

   • Signing Key: /Common/idp.acme.com (drop down)
   • Signing Certificate: /Common/idp.acme.com (drop down)

Note

The certificate and key were previously imported

6. Click OK to complete the creation of the IdP service

SP Connector

1. Click on External SP Connectors (under the SAML Identity Provider tab) in the horizontal navigation menu

2. Click specifically on the Down Arrow next to the Create button (far right)

3. Select From Metadata from the drop down menu

4. In the Create New SAML Service Provider dialogue box, click Browse and select the sp_acme_com.xml file from the Desktop of your jump host

5. In the Service Provider Name field, enter the following: sp.acme.com

6. Click OK on the dialog box

Note

The sp_acme_com.xml file was created previously. Oftentimes SP providers will have a metadata file representing their SP service. This can be imported to save object creation time as has been done in this lab.

7. Click on Local IdP Services (under the SAML Identity Provider tab) in the horizontal navigation menu

8. Select the Checkbox next to the previously created idp.acme.com and click the Bind/Unbind SP Connectors button at the bottom of the GUI

9. In the Edit SAML SP’s that use this IdP dialog, select the /Common/sp.acme.com SAML SP Connection Name created previously

10. Click the OK button at the bottom of the dialog box

11. Under the Access ‑> Federation ‑> SAML Identity Provider ‑> Local IdP Services menu you should now see the following (as shown):

• Name: idp.acme.com
• SAML SP Connectors: sp.acme.com

Task 3 - Create a SAML Resource

1. Begin by selecting Access ‑> Federation ‑> SAML Resources >> + (Plus Button)

2. In the New SAML Resource window, enter the following values:

   • Name: sp.acme.com
   • SSO Configuration: idp.acmem.com
   • Caption: sp.acme.com

3. Click Finished at the bottom of the configuration window

Task 4 - Create a Webtop

1. Select Access ‑> Webtops ‑> Webtop Lists >> + (Plus Button)

2. In the resulting window, enter the following values:

   • Name: full_webtop
   • Type: Full (drop down)
   • Minimize To Tray: uncheck

3. Click Finished at the bottom of the GUI

Task 5 - Create an OCSP Responder

1. Navigate to Access >> Authentication >> OCSP Responder >> Click the Plus (+) Sign.

2. Enter the following information for the OCSP Responder configuration:

   • Name: ocsp_servers
   • Configuration: Advanced
   • URL: http://dc1.f5lab.local
   • Certificate Authority File ca.f5lab.local
   • Certificate Authority Path: /ocsp
   • Options: Uncheck Nonce

3. Click Finished

Task 6 - Create an AAA LDAP Server

1. Navigate to Access >> Authentication >> LDAP >> Click the Plus (+) Sign.

2. Enter the following information for the LDAP Server configuration:

Name: ldap_servers Server Connection: Use Pool Server Pool Name: ldap_pool Server Addresses: 10.1.20.7 Admin DN: CN=admin,CN=Users,DC=f5lab,DC=local Admin Password: admin

3. Click Finished

Task 7 - Create a SAML IdP Access Policy

1. Select Access ‑> Profiles/Policies ‑> Access Profiles (Per-Session Policies)

2. Click the Create button (far right)

3. In the New Profile window, enter the following information:

   • Name: idp.acme.com‑psp
   • Profile Type: All (drop down)
   • Profile Scope: Profile (default)
   • Customization Type: modern (default)

4. Scroll to the bottom of the New Profile window to the Language Settings section

5. Select English from the Factory Built‑in Languages menu on the right and click the Double Arrow (<<), then click the Finished button.

6. The Default Language should be automatically set

7. From the Access ‑> Profiles/Policies ‑> Access Profiles (Per-Session Policies) screen, click the Edit link on the previously created idp.acme.com-psp line

8. Click the Plus (+) Sign between Start and Deny

9. In the pop-up dialog box, select the Logon tab and then select the Radio next to On-Demand Cert Auth, and click the Add Item button

10. Click Save in the resulting Logon Page dialog box

11. On the successful branch of the On-Demand Cert Auth Policy-Item click the Plus (+) Sign

12. In the pop-up dialog box, select the Authentication tab and then select the Radio next to OCSP Auth, and click the Add Item button

13. Select /Common/ocsp_servers from the OCSP Responder drop down menu.

14. Click Save at the bottom of the window

15. Click the Plus (+) Sign on the successful branch between OCSP Auth and Deny

16. In the pop-up dialog box, select the Assignment tab and then select the Radio next to Variable Assign, and click the Add Item button

17. Enter the Name upn_extract

18. Click Add new entry

19. Click Change

20. Enter the Custom Variable session.custom.upn

21. Select Custom Expresssion from the right drop down menu

22. Enter the text below for the custom expression.

set x509e_fields [split [mcget {session.ssl.cert.x509extension}] "\n"];
# For each element in the list:
foreach field $x509e_fields {
# If the element contains UPN:
if { $field contains "othername:UPN" } {
## set start of UPN variable
set start [expr {[string first "othername:UPN<" $field] +14}]
# UPN format is <user@domain>
# Return the UPN, by finding the index of opening and closing brackets, then use string range to get everything between.
return [string range $field $start [expr { [string first ">" $field $start] - 1 } ] ];  } }
#Otherwise return UPN Not Found:
return "UPN-NOT-FOUND";

23. Click Finished

24. Click Save

25. Click the Plus (+) Sign between upn_extract and Deny

26. In the pop-up dialog box, select the Authentication tab and then select the Radio next to LDAP Query, and click the Add Item button

27. In the LDAP Query Properties window, enter the following information:

• Server: /Common/ldap_servers (drop down)
• Search DN: dc=f5lab,dc=local
• SearchFilter: (userPrincipalName=%{session.custom.upn})

28. Click Add new entry

29. Add sAMAccountName to the list of Required Attributes

30. Click the Branch Rules tab

31. Click the X on the User Group Membership line

32. Click Add Branch Rule

33. Enter the name LDAP Query Passed

34. Click change

35. Click Add Expression

36. Select LDAP Query from the Context dropdown menu

37. Select LDAP Query Passed from the Condition dropdown menu

38. Click Add Expression

39. Click Finsished

40. Click Save

41. Click the Plus (+) Sign on the LDAP Query Passed branch between LDAP Query and Deny

42.In the pop-up dialog box, select the Assignment tab and then select the Radio next to Variable Assign, and click the Add Item button

43. Enter the Name set_username

44. Click Add new entry

45. Click Change

46. Enter the Custom Variable session.logon.last.username

47. Select Session Variable from the right drop down menu

48. Enter the session variable name session.ldap.last.attr.sAMAccountName

49. Click Finished

50. Click Save

51. Click the Plus (+) Sign between set_username and Deny

52. In the pop-up dialog box, select the Assignment tab and then select the Radio next to Advanced Resource Assign, and click the Add Item button

53. In the new Resource Assignment entry, click the Add/Delete link

54. In the resulting pop-up window, click the SAML tab, and select the Checkbox next to /Common/sp.acme.com

55. Click the Webtop tab, and select the Checkbox next to /Common/full_webtop

56. Click the Update button at the bottom of the window to complete the Resource Assignment entry

57. Click the Save button at the bottom of the Advanced Resource Assign window

58. In the Visual Policy Editor, select the Deny ending on the fallback branch following Advanced Resource Assign

59. In the Select Ending dialog box, selet the Allow radio button and then click Save

60. In the Visual Policy Editor, click Apply Access Policy (top left), and close the Visual Policy Editor

Task 8 - Create a Client-side SSL Profile

1. Navigate to Local Traffic ‑> Profile -> SSL -> Client. Click the Plus (+) Sign

2. Enter the Name idp.acme.com-clientssl

3. Check the custom box on the Certificate Key Chain Line

4. Click Add

5. Select acme.com-wildcard from the Certificate dropdown menu

6. Select acme.com-wildcard from the Key dropdown menu

7. Click Add

8. Check the custom box on the Trusted Certificate Authorities Line

9. Select ca.f5lab.local from the Trusted Certificate Authorities dropdown menu

10. Check the custom box on the Advertised Certificate Authorities Line

11. Select ca.f5lab.local from the Advertised Certificate Authorities dropdown menu

12. Click Finished

Task 9 - Create the IdP Virtual Server

1. Begin by selecting Local Traffic ‑> Virtual Servers

2. Click the Create button (far right)

3. In the New Virtual Server window, enter the following information:

   • General Properties
   • Name: idp.acme.com
   • Destination Address/Mask: 10.1.10.102
   • Service Port: 443

• Configuration
• HTTP Profile: http (drop down)
• SSL Profile (Client): idp.acme.com-clientssl

• Access Policy
• Access Profile: idp.acme.com-psp

4. Scroll to the bottom of the configuration window and click Finished

Task 10 - Test the Configuration

1. From the jumphost, navigate to the SAML IdP you previously configured at https://idp.acme.com.

2. Select the user1 certificate

3. Click OK

4. Click sp.acme.com

5. You are then successfully logged into https://sp.acme.com and presented a webpage.

6. Review your Active Sessions (Access ‑> Overview ‑> Active Sessions)

7. Review your Access Report Logs (Access ‑> Overview ‑> Access Reports)

Task 11 - Lab Cleanup

1. From a browser on the jumphost navigate to https://portal.f5lab.local

2. Click the Classes tab at the top of the page.

3. Scroll down the page until you see 301 SAML Federation on the left

4. Hover over tile SAML Identity Provider (IdP) - Cert Auth. A start and stop icon should appear within the tile. Click the Stop Button to trigger the automation to remove any prebuilt objects from the environment

5. The screen should refresh displaying the progress of the automation within 30 seconds. Scroll to the bottom of the automation workflow to ensure all requests succeeded.

6. This concludes the lab.

Class 2

Class 2 – API Protection with AWAF and APM modules

Module 5 Part 1

Module 5 Part 1: Deploy an APM API Protection Profile

Section 1.1 - Setup Lab Environment

1. Open the Chrome browser and open the site https://portal.f5lab.local.

2. Click the Classes tab at the top of the page.

3. Scroll down the page until you see 304 API Protection on the left

3. Hover over tile Deploy an API Protection Profile. A start and stop icon should appear within the tile. Click the Play Button to start the automation to build the environment

10. The screen should refresh displaying the progress of the automation within 30 seconds. Scroll to the bottom of the automation workflow to ensure all requests succeeded.

Section 1.2 - Implement Course-Graing Access Control

Task 1 - Create a Provider

The cornerstone of the API protection profile is the ability to authorize users using JWT. Unlike Guided Configuration that creates the JWT Provider for you based on a few defined parameters, you must create the provider manually.

1. From bigip1.f5lab.local - 10.1.1.4 (Click bigip1 tab in Chrome browser), than login as admin/admin and navigate to Access >> Federation >> OAuth Client/Resource Server >> Provider. Click the + (Plus Symbol)

2. Configure the following parameters:

   • Name: api-as-provider
   • Trusted Certificate Authorities: ca.acme.com
   • OpenID URL: replace f5-oauth.local with as.acme.com

3. Click Discover

4. The Authentication URI, Token URI, Token Validation Scope URI, UserInfo URI and keys should be updated.

5. Click Save

Task 2 - Create a JWT Provider

1. Navigate to Access >> Federation >> JSON Web Token >> Provider List. Click the + (Plus Symbol).

2. Enter the name: as-jwt-provider

3. Click Add so api-as-provider is added to list of providers

4. Click Save

Task 3 - Create an API Protection Profile

1. Navigate to API Protection >> Profile. Click the + (plus symbol)

Note

The JSON file is located on the jumpbox in c:\access-labs\class3\module4\student_files

2. Enter the following parameters:

   • Name: api-protection
   • OpenAPI File: Active Directory OpenAPI.json
   • DNS Resolver: internal-dns-resolver
   • Authorization: OAuth 2.0

3. Click Add

4. Click Save

Task 4 - Explore the Path Configuration

1. Note the Spec file contained a single path of /user but it supports four different request methods.

2. The API server that all requests will be sent to is http://adapi.f5lab.local:81

Task 5 - Associate a JWT Provider

1. Click Access Control from the top ribbon

2. Click Edit (Per Request Policy)

3. Notice the same paths displayed in the API Protection profile appear here. Currently there is no fine-grained access control. We will implement it later in the lab.

4. Click the + (plus symbol) next the Subroutine OAuth Scope Check AuthZ to expand its properties:

Note

The OAuth scope agent currently has a red asterisk since no provider is associated with it.

5. Click OAuth Scope

6. Enter the following parameters:

   • Token Validation Mode: Internal
   • JWT Provider List: as-jwt-provider
   • Response: api-protection_auto_response1

7. Click Save

Task 6 - Create a virtual server

1. Navigate to Local Traffic >> Virtual Servers >> Virtual Server List. Click the + (plus symbol)

2. Enter the following parameters:

   • Name: api.acme.com
   • Destination Address/Mask: 10.1.10.102
   • Service Port: 443
   • HTTP Profile (Client): http
   • SSL Profile(Client): acme.com
   • Source Address Translation: Auto Map
   • API Protection: api-protection

3. Click Finished

Task 7 - Import Postman Collections

1. From the Jumpbox, open Postman via the desktop shortcut or toolbar at the bottom

2. Click Yes if prompted for “Do you want to allow this app to make changes to your device?”

3. Click Import located on the top left of the Postman application

4. Click Upload Files

5. Navigate to C:\access-labs\class3\module4\student_files, select student-class3-module4-lab01.postman_collection.json, and click Open

6. Click Import

7. A collection called student-class3-module4-lab01 will appear on the left side in Postman

Task 8 - Retreive your OAuth clientID

1. Expand the student-class3-module4-lab01 Collection

2. Select the request Request1: Retrieve Postman ClientID

3. Click Send

4. You receive a 200 OK with a response body. The clientID is now stored as a Postman Variable to be used in future requests. Your ClientID will not be the same as displayed in the screenshot below.

Task 9 - Attempt to Retrieve User1's Attributes without JWT

1. Select the request Request 2: Retrieve User Attributes without JWT

2. Click Send

3. You receive a 403 Forbidden response status code since you do not have a valid JWT

Task 10 - Retrieve User1's Attributes with a JWT

1. Select the request Request 3: Retrieve User Attributes with JWT

2. Select the Authorization tab

3. Click Get New Access Token

4. Login using Username: user1, Password: user1

5. Click Use Token.

6. Notice the Access Token field is now populated

7. Click Send

8. You receive a 200 OK response status code with attributes for user1 in the body of the response

Task 11 - Set a Valid User Attribute

1. Select the request Request 4: Update a Valid User Attribute

2. Select the Authorization tab

3. Select the previously created User1 token from the Available Tokens dropdown

4. The Token field is now populated

5. Click Send

Note

If you receive a 403 response status code, request a new token. You can change the name of the token request prior to sending by setting the Token Name. You can delete expired tokens by clicking the Available Tokens dropdown, clicking Manage Tokens, and then clicking the trashcan next to the Token.

6. You receive a 200 OK response status code with a response body that contains user1’s employeeNumber 123456

Task 12 - Set an Nonexistent User’s Attribute

1. Select the request Request 5: Update a Nonexistent User's Attribute

2. Select the Authorization tab

3. Select the previously created User1 token from the Available Tokens dropdown

4. The Token field is now populated

5. Click Send

Note

If you receive a 403 response status code, request a new token. You can change the name of the token request prior to sending by setting the Token Name. You can delete expired tokens by clicking the Available Tokens dropdown, clicking Manage Tokens, and then clicking the trashcan next to the Token.

6. You receive a 2O0 OK response status code. The request successfully passed through the API Gateway, but the server failed to process the request.

Task 13 - Update a Valid User with PUT

1. Select the request Request 6: Update a Valid User’s Attribute with PUT

2. Select the Authorization tab

3. Select the previously created User1 token from the Available Tokens dropdown

4. The Token field is now populated

5. Click Send

6. You receive a 403 Forbidden response status code. This is expected because the PUT Method was not specified in the API Protection Profile for the path /user

Task 14 - Create a User

1. Select the request Request 7: Create a User

2. Select the Authorization tab

3. Select the previously created User1 token from the Available Tokens dropdown

4. Click Send

5. You receive a 200 OK response status code with a response body that contains Bob Smith’s user attributes

Task 15 - Request invalid endpoint

1. Select the request Request 8: Request Invalid Endpoint

2. Select the Authorization tab

3. Select the previously created User1 token from the Available Tokens dropdown

4. The Token field is now populated

5. Click Send

6. You receive a 403 Forbidden response status code. This is expected because the path /hacker/attack was not specified in the API Protection Profile

Section 1.3 - Implement Fine-Grained Access Controls

Up to this point any authenticated user to the API is authorized to use them. In this section we will restrict user1’s ability to create users, but will still be able to modify a user’s employee number.

Task 1 - Retrieve Group Membership Subsession Variable

Note

In order to implement fine-grained control the session variables that contain the data must be known. This first session shows you how to display the session variables and their values.

1. From the Jumpbox desktop click on the BIG-IP1 Putty icon

2. Enter the command sessiondump –delete all to remove any existing APM sessions

3. Enter the command tail -f /var/log/apm. Hit enter a few times to create some space on the screen

4. From Postman, Select the request Request 3: Retrieve User Attributes with JWT. The Authorization field should already be populated with User1’s token.

5. Click Send

6. You receive a 200 OK response status code with attributes for user1 in the body of the response

Note

Your SessionID will be different

7. Return to the CLI and examine the logs. You will see a message about a new subsession being created. Copy the subsession ID

8. Exit the logs using Ctrl+Z

9. Enter the command sessiondump -subkeys < subsessionID >

10. Scroll through input until you find the session variable for subsession.oauth.scope.last.jwt.groups

Task 2 - Edit the per-request policy

1. Return to BIG-IP1’s management interface and navigate to Access >> API Protection >> Profile. Click Profile to modify the previously created API protection Profile (not the + Plus symbol)

2. Click Edit Under Per-Request Policy

3. Click the Allow terminal located at the end of the POST /user branch

4. Select Reject

5. Click Save

6. Click the + (Plus Symbol) on the POST /user branch

7. Click the General Purpose tab

8. Select Empty

9. Click Add Item

10. Enter the name Claim Check

11. Click the Branch Rules tab

12. Click the Add Branch Rule

13. Enter Name CreateUser

14. Click Change

15. Click the Advanced tab

16. Enter the string in the notes section to restrict access to only members of the CreateUser Group. Make sure the ” characters are properly formatted after pasting. If they aren’t, simply delete and re-enter them manually.

17. Click Finished

Note

expr {[mcget {subsession.oauth.scope.last.jwt.groups}] contains “CreateUser”}

18. Click Save

19. Click Reject on the CreateUser Branch to permit access

20. Select Allow

21. Click Save

22. Review the Policy Flow

Task 3 - Test the Fine-Grained Access Control with user1

1. From Postman select the request Request 7: Create User

2. Select the Authorization Tab

3. Select the previously created User1 token from the Available Tokens dropdown

4. The Token field is now populated

5. Click Send

6. You receive a 403 Forbidden response status code when using user1. User1 does not contain the proper claim data.

Task 4 - Test the Fine-Grained Access Control with user2

1. Select the request Request 7: Create User

2. Select the Authorization tab

3. Ensure the Token Name is set to user2

4. Click Get New Access Token

5. Login using Username: user2, Password: user2

6. Ensure the User2 Token is selected

7. Click Use Token at the top right.

8. The Token field is now populated

9. Click Send

10. You receive a 200 OK response status code when using user2. User2 does contain the proper claim data

Section 1.4 - Implement Rate Limiting

The API Protection Profile allows a BIG-IP administrator to throttle the amount of connections to an API through the use of Key Names.

Task 1 - Test pre-rate limiting Access

1. Click the arrow located to the right of the student-class3-module4-lab01 collection.

2. Click Run

3. Deselect all requests except Request 3: Retrieve User Attributes with JWT

4. Set the iterations to 100

5. Click the blue Run Student-class3-module4-la… button

6. You receive a 200 OK for every request. Leave Runner open

Task 2 - Define the rate limiting keys

1. Navigate to API Protection >> Profile. Click Profile to modify the previously created API protection Profile. Not the + Plus symbol.

2. Click api-protection

3. Click Rate Limiting from the top ribbon

Note

The API protection profile default settings contains five Key Names created, but their values are empty. Additional Keys can be created if necessary

4. Click api-protection_auto_rate_limiting_key1

5. Enter the Key Value %{subsession.oauth.scope.last.jwt.user}

6. Click Edit

7. Click api-protection_auto_rate_limiting_key2

8. Enter the Key Value %{subsession.oauth.scope.last.jwt.groupid}

9. Click Edit

10. Click api-protection_auto_rate_limiting_key3

11. Enter the Key Value %{subsession.oauth.scope.last.jwt.client}

12. Click Edit

13. Click api-protection_auto_rate_limiting_key4

14. Enter the Key Value %{subsession.oauth.scope.last.jwt.tier}

15. Click Edit

16. Click api-protection_auto_rate_limiting_key5

17. Enter the Key Value %{subsession.oauth.scope.last.jwt.org}

18. Click Edit

19. Click Save

Task 3 - Create a Rate Limiting Policy

1. Click Create in the rate limiting section

2. Enter the Name acme-rate-limits

3. Move all five keys under Selected Keys

4. Enter 10 for the number of requests per minute

5. Enter 5 for the number requests per second

6. Click Add.

7. Click Save

Task 4 - Apply the Rate Limiting Policy

1. Click Access Control from the ribbon

2. Click Edit Per Request Policy

3. Click the + (Plus Symbol) on the Out branch of the OAuth Scope Check AuthZ Macro

4. Click the Traffic Management tab

5. Select API Rate Limiting

6. Click Add Item

7. Click Add new entry

8. Select acme-rate-limits

9. Click Save

10. Verify the Rate Limiting agent now appears in the appropriate location

Task 5 - Test Rate Limiting

1. Return to Postman

2. Click Run Again to rerun the request an additional 100 times.

3. On the 6th request you begin to receive a 429 Too Many Requests response status code

Section 1.5 - Onboard a New API

Organizations change. With this change, new APIs are introduced requiring modifications to the API Gateway. In this section you will learn how to add additional paths.

Task 1 - Verify no access to API

1. From Postman, select the request Request 9: Create DNS Entry

2. Select the Authorization tab

3. Select the previously created User1 token from the Available Tokens dropdown

4. The Token field is now populated

5. Click Send

6. You receive a 403 Forbidden response status code because the the new API has not been published at the Gateway.

Task 2 - Add the new API path

1. From the browser, navigate to API Protection >> Profile. Click Profile to modify the previously created API protection Profile (not the + Plus symbol)

2. Click api-protection

3. Click Paths

4. Click Create

5. The URI /dns

6. Select the Method POST

7. Click Add

8. Click Save

Task 3 - Test Access to the new path

1. From Postman, select the request Request 9: Create DNS Entry

2. You receive a 200 OK that the endpoint is now published.

This concludes this lab

Module 5 Part 2

Module 5 Part 2: Deploy an AWAF Bot Defense and WAF protection

The API protection profile provides authorization and basic WAF policy to protect an API. This module will demonstrate how to layer on additional protections to further validate what is accessing the API and that the client is behaving within the norms of the API.

By default, security events are not logged, in this lab the student will create a security logging profile with Application Security, Bot Defense and DOS Protection enabled. The student will also place the waf policy in trasnparent to show the difference in behavior when client traffic that is deemed malicious is and is not blocked.

Section 2.1 - Setup Lab Environment

Task 1 - Import Postman Collection

1. From the Jumpbox, open Postman via the desktop shortcut or toolbar at the bottom

2. Click Yes if prompted for “Do you want to allow this app to make changes to your device?”

3. Click Import located on the top left of the Postman application

image003

4. Click Upload Files

5. Navigate to C:\access-labs\class3\module4\student_files, select student-class3-module4-lab02.postman_collection.json, and click Open

6. Click Import

7. A collection called student-class3-module4-lab02 will appear on the left side in Postman

Task 2 - Add Vulnerable API

Note

Ensure you are logged into BIGIP1

1. From the web browser, navigate to Access >> API Protection >> Profile. Click Profile to modify the existing profile api-protection Profile (not the + Plus symbol)

2. Click Edit Under Per-Request Policy

3. Click the + (Plus Symbol) located between Start and OAuth Scope Check AuthZ

4. Select the Classification tab

5. Select Request Classification

6. Click Add Item

7. Select Branch Rules

8. Click Add Branch Rule

9. Enter name GET /vulnerable

10. Click Change

11. Click Add Expression

12. Select Request from the Context dropdown

13. Click** Add Expression**

14. Click Add Expression on the AND line

15. Select Path (value) from the Request dropdown

16. Enter /vulnerable in the empty text box

17. Click Add Expression

18. Click Finished

19. Click Save

20 Click the + Plus Symbol on the GET /vulnerable branch

21. Click API Server Selection

22. Click Add Item

23. Select api-protection_server1 from the dropdown

24. Click Save

25. Click the Reject terminal at the end of API Server Selection

26. Select Allow

27. Click Save

28. The completed policy should look like the below.

Section 2.2 - Create and Assign Profiles

Task 1 - Create and assign a Security Logging Profile to the virtual¶

1. From the web browser, click on the Security -> Event Logs -> Logging Profile and click Create.

2. For the Profile Name enter api.acme.com_logprofile.

3. Enable Application Security, an Application Security configuration menu will open up at the bottom. Change the Request Type from Illegal requests only to All requests.

4. Enable DoS Protection, a DoS Protection configuration menu will open up at the bottom. Enable Local Publisher

5. Enable Bot Defense, a Bot Defense configuration menu will open up at the bottom. Enable Local Publisher and all other checkboxes, leave Remote Publisher set to none.

6. Click Create

7. Apply the log profile to the api.acme.com virtual by navigating to Local Traffic -> Virtual Servers -> api.acme.com -> Security -> Policies and after choosing “Enabled” from the dropdown, set the Selected Log Profile to api.acme.com_logprofile.

8. Click Update. The virtual will now log Application Security, DoS and Bot related events under Security -> Event Logs when an appropriate security profiles have been applied to the virtual.

Task 2 - Set the WAF policy to Transparent and assign it to the virtual

1. From the web browser, click on the Security -> Application Security -> Security Policies -> Policies List. Click api-protection. Scroll down and you’ll notice the Enforcement Mode is set to Blocking. Set the Enforcement Mode to Transparent. Be sure to click Save, then Apply Policy.

2. Apply the waf policy to the api.acme.com virtual by navigating to Local Traffic -> Virtual Servers -> api.acme.com -> Security -> Policies and set the Application Security Policy to enabled and the Policy to api-protection.

3. Click Update.

Task 3 - Create and assign a Bot Defense Profile

An api’s clients, unlike a typical web application, will often be non-human, maybe even exclusively. This leaves bot defense more difficult to configure in an api protection scenario, for instance javascript such as captcha cannot be used to proactively determine whether the client is human. In this lab, we demonstrate some scenarios the admin may encounter and how to address them.

Note

Ensure you are logged into BIGIP1

1. From the web browser, click on the Security -> Bot Defense -> Bot Defense Profiles and click Create.

2. For the name enter api.acme.com_botprofile, leave all other settings at their defaults.

3. Click Save

The bot profile is left in transparent mode to demonstrate the logging behavior and behavior differences to the client.

4. Apply the bot profile to the api.acme.com virtual by navigating to Local Traffic -> Virtual Servers -> api.acme.com -> Security -> Policies.

For Bot Defense Profile select Enabled and select api.acme.com_botprofile as the Profile. Click Update.

Section 2.3 - Test Bot Protection¶

Task 1 - Test Bot Protection in Transparent Mode

1. Now we will test the Bot Defense Profile to see how it affects clients. Go to Postman, expand the collection student-class3-module4-lab02 and select the request Request 1: Retrieve Attributes and click Send.

2. Return to the bigip01 gui and navigate to Security -> Event Logs -> Bot Defense -> Bot Requests and find the request to the /vulnerable uri as shown below

Note

The student should pay special attention to the Request Status, Mitigation Action and Bot Class. Bot Class will be one of the categories found in **Security -> Bot Defense -> Bot Defense Profiles -> api.acme.com_botprofile -> Bot Mitigation Settings** under **Mitigation Settings**.

Task 2 - Place Bot Profile in blocking and allow appropriate clients

The bot profile was left in transparent to demonstrate the behavior, now we will configure the bot profile to block bot traffic. Keep in mind that the bot profile allows for fine-grained control of categories of bots, which bot fits in those categories. We will explore this later.

1. Navigate back to Security -> Bot Defense -> Bot Defense Profiles -> api.acme.com_botprofile, change the Enforcement Mode to Blocking and click Save.

2. Go back to Postman once again and select the request Request 1: Retrieve Attributes and click Send another time.

3. Return to the bigip01 gui and navigate to Security -> Event Logs -> Bot Defense -> Bot Requests and find the 2nd request to the /vulnerable uri as shown below

Note

Why was this request not blocked? To understand this, we must take a closer look at the Mitigation Settings.

1. Navigate to Security -> Bot Defense -> Bot Defense Profiles -> api.acme.com_botprofile -> Bot Mitigation Settings and examine the Unknown categorization, note that bots that are of category Unknown are simply rate limited.

2. Go back to Postman once again, click on the three dots in the right corner of the collection* student-class3-module4-lab02 collection to open Runner.

3. Click Run Collection

4. Configure Runner so iterations is set to 100 and the only request selected is Request 1: Retrieve Attributes.

5. Click Run student-class3-module4-la….

6. Notice all responses are 200 OKs.

7. Return to the bigip01 gui and navigate to Security -> Event Logs -> Bot Defense -> Bot Requests and find the Denied request to the /vulnerable uri as shown below.

8. We will recategorize the Postman client so that it is a trusted client, this is done via bot signatures. Navigate to Security -> Bot Defense -> Bot Signatures -> Bot Signatures Categories List and click Create.

9. Fill in the Bot Signature Category Name of Trusted Development Tools and select Trusted Bot from the Bot Class dropdown.

10. Navigate to Security -> Bot Defense -> Bot Signatures -> Bot Signatures List and click Create.

11. Fill in the Bot Name, Bot Category and Rule (User Agent) with the following, leaving all other values at their defaults.

12. Click Save.

13. Go back to Postman once again and select the request Request 1: Retrieve Attributes and click Send another time. Note this is done at the main Postman window, not in Runner.

14. Navigate to Security -> Event Logs -> Bot Defense -> Bot Requests and find the Trusted Bot categorized request to the /vulnerable uri as shown below

Section 2.4 - Layer on WAF to provide additional security

APIs are a collection of technologies just like any other application, in the lab the api is built on top of a windows server using powershell. This lab demonstrate how to tune the WAF policy to use attack signatures and meta-character enforcement to provide additional protection against malicious clients.

Meta-character enforcement allows the WAF admin to enforce which characters are allowed into a web application, whether it be in the header, url or parameter. In this lab we examine parameter meta-character enforcement.

Task 1 - Configure Attack Signatures and Change WAF Policy to Blocking

1. Open a command prompt on the jumphost (a shortcut is on the desktop)

2. Run the following command curl -k “https://api.acme.com/vulnerable?Inject=|powershell%20badprogram.ps1” -v

Note

Pay special attention to the double quotes (“”) around the url.

3. Navigate to Security -> Event Logs -> Application -> Requests and find this latest request. Locate the parameter value |powershell badprogram.ps1. Click the parameter and then hover over the parameter value and additional details will describe this part of the attack.

Note

The Enforcement Action is None

The F5 WAF highlights the part of the request it detects as malicious based on the policy’s configuration. This can be very useful for learning and troubleshooting purposes.

4. Next hover over the User-Agent portion of the request.

Notice the user-agent is curl, which may be a legitimate client. Make note of this.

Ideally we want to block any malicious request, in this case the powershell execution attempt, but want to allow curl as it’s a legitimate client in our case. What about the %20 meta character, should it be allowed? Depending on the application, this could be legitimate.

In your environment, you must decide what is legitimate and what is illegitimate traffic, the F5 WAF can guide you via learning and help eliminate noise using Bot Defense, however to increase security beyond a basic WAF policy, understanding the application is needed.

5. Click on the Security -> Application Security -> Policy Building -> Learning and Blocking Settings -> Attack Signatures and click Change

6. Enable Command Execution Signatures and click Change

7. Scroll to the bottom anc click Save.

8. Navigate to Security -> Application Security -> Security Policies -> Policies List.

9. Click api-protection

10. Click Attack Signatures

11. Click the filter icon to easily locate the Automated client access “curl” signature.

12. For the Attack Signature Name enter Automated client access “curl” and click Apply Filter.

The result is

13. Select this signature and click Disable

14. Click General Settings and scroll down to “Enforcement Mode” and change it to “Blocking.” Click Save and then Apply the Policy

15. Once again run the following command curl -k “https://api.acme.com/vulnerable?Inject=|powershell%20badprogram.ps1” -v

Pay special attention to the double quotes (“”) around the url.

16. Navigate to Security -> Event Logs -> Application -> Requests and find this latest request.

Notice the enforcement action is still None but also notice the user-agent curl is no longer highlighted (since the signature was disabled). We changed the Policy to Blocking so why wasn’t the request blocked? Hint: Click the “1” under Occurrences and you’ll see the current status of the Attack Signature.

17. Hover over the highlighted payload and notice that the powershell attack signature is triggered.

Powershell execution via http parameters is now mitigated. If you noticed in the request, that the | is considered illegal. What if that character was a legitimate value for a parameter?

18. Go back to the command prompt on the jumphost and run

curl -k “https://api.acme.com/vulnerable?param1=|legitimate%20value” -v

19. Navigate to Security -> Event Logs -> Application -> Requests and find this latest request. Notice the | is considered illegal. However its not blocked, the Enforcement Action is None

20. To see why this parameter character violation is not being blocked, but is being logged (alarmed). Navigate to Security -> Application Security -> Policy Building -> Learning and Blocking Settings -> Parameters and enable the Block column for the Illegal meta character in value under the Parameters Section

21. Click Save then Apply Policy

22. Go back to the command prompt on the jumphost and run

curl -k “https://api.acme.com/vulnerable?param1=|legitimate%20value” -v

23. Navigate to Security -> Event Logs -> Application -> Requests and find this latest request. Notice the | is considered illegal and is now blocked.

Task 2 - Implement Static Parameter values

1. From Postman, click Send on the Request 2: SSRF Attack-Google request.

2. From Postman, run Request 3: SSRF Attack-unprotected-json. This site contains an example ID and Secret key in JSON format. You can now see the endpoint is vulnerable to Server Side Request Forgery attacks because the endpoint can be directed to locations other than Google. Hackers will uses your servers as a jump off point to gain access to internal resources.

3. Navigate to Security -> Event Logs -> Application -> Requests and find both requests. Notice nothing appears malicious about these requests except for the destinations.

4. We are going to secure the the uri parameter, so it only allows access to Google, but not access to the internal private data.

5. Navigate to Security -> Application Security -> Parameters -> Parameters List. Click the + Plus Symbol

6. Enter the Name uri

7. Uncheck Perform Staging

8. From the Parameter Value Type dropdown select Static Content Value

9. Enter https://www.google.com for the New Static Value

10. Click Add

11. Click Create

12. Click Apply Policy

13. From Postman, run Request 2: SSRF Attack-Google. Access to Google is still allowed.

14. From Post, run Request 3: SSRF Attack-unprotected-json. This site is now blocked as intended

15. Navigate to Security -> Event Logs -> Application -> Requests and find the latest blocked request. The uri parameter is highlighted due to Illegal Static Parameter Value.

This is the end of the lab