Lab 2: Custom Per Request Policy

The purpose of this lab is to build a custom Per Request Policy (PRP) flow and then extend that policy with additional subroutines to perform dynamic updates to access controls and authentication requirements. Per Request Policies will restrict or grant access based on dynamic queries of AD Group Membership and the URI accessed. Step-up authentication will also be leveraged. Students will configure the various aspects using the Visual Policy Editor, review the configuration and perform tests of the deployment.

Objective:

• Gain a deeper understanding of Per Request Policies and their applicability in various delivery and control scenarios
• Gain a further understanding of Per Request Policy subroutines and their use in dynamic queries and step-up authentication.

Lab Requirements:

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

Lab 2 Tasks:

TASK 1: Prepare Lab Environment

From the Jumphost desktop, click on the Remove-User1-from-App2 PowerShell Script. This prepares the environment for further user testing.

TASK 2: Review Existing Configuration

On bigip1.f5lab.local, navigate to Local Traffic -> Virtual Servers -> Virtual Server Lists. Click on the link for the app.acme.com_vs.

Within the app.acme.com_vs configuration, scroll down to the Access Policy section, note the Per Session and Per Request policies applied.

Navigate to Access -> Profiles/Policies -> Access Profiles (Per-Session Policies) and then click the Edit link for the app.acme.com_psp Per Session Policy.

Note that the app.acme.com_psp Access Policy simply has Start -> Allow. All Access configurations will occur in the Per Request Policy.

Navigate to Access -> Profiles/Policies -> Per-Request Policies and then click the Edit link for the app.acme.com_prp Per Request Policy.

Review the app.acme.com_prp Per Request Policy and the subroutine. Click on the + (Plus Symbol) to expand the Logon Subroutine at the bottom of the policy window. Then click on the Subroutine Settings / Rename link.

Review the Logon subroutine settings. These settings will determine inactivity timers and session lifetime.

Open Firefox, click on the app.acme.com link provided in the Bookmark toolbar. Logon to the resulting logon page with UserID: user1 and Password: user1 Note: User1 has buttons to all applications even though user1 does not currently have the necessary group access for all applications.

TASK 3: URI Dynamic Filtering (via AD Group Membership)

Note: This provides the ability to dynamically deploy new applications based on standardized URI paths and control access to those applications (via group membership) without needing to re-entrantly edit the Per Request Policy again. Navigate to Access -> Profiles/Policies -> Per-Request Policies and then click the Edit link for the app.acme.com_prp Per Request Policy. In the resulting Visual Policy Editor window, click on the + (Plus Symbol) on the apps branch following URL Branching. In the pop-up window, select the General Purpose tab, then click the radio button on the Empty action line, then click Add Item.

Enter URI - Dynamic Mapping in the Name field.

In the next window, click the Add Branch Rule. In the new section, enter App Access in the Name field. Click the change link.

In the resulting window, click on the Advanced tab. Paste the expression below into the provided window and then click Finished. Explanation: The expression shown parses the incoming URI to extract a portion of the URI to use as a variable in determining an AD Group Name dynamically.

Expression is shown below for copy and paste convenience

expr {[mcget {subsession.ad.last.attr.memberOf}] contains "CN=[findstr [mcget {perflow.category_lookup.result.url}] "http" 26 "/"],OU=Groups,DC=f5lab,DC=local"}

Click Save in the resulting window.

Review the added URI - Dynamic Mapping agent. Ensure the Allow and Reject endings are set as shown.

TASK 4: URI DataGroup Filtering (via AD Group Membership)

Note: This provides the ability to dynamically deploy new applications based on standardized URI paths defined in DataGroups and control access to those applications (via group membership) without needing to re-entrantly edit the Per Request Policy again. In the Visual Policy Editor window, click on the + (Plus Symbol) on the members branch following URL Branching. In the pop-up window, select the General Purpose tab, then click the radio button on the Empty action line, then click Add Item.

Enter URI - DataGroup Mapping in the Name field.

In the next window, click the Add Branch Rule. In the new section, enter Member Access in the Name field. Click the change link.

In the resulting window, click on the Advanced tab. Paste the expression below into the provided window and then click Finished. Explanation: For environments in which URI’s and AD Groups may not be standardized, parsing the URI and then leveraging a Data Group match allows for non-standard matching between URI and AD Groups. (Data Groups can be updated via REST (AS3 Declarations) calls.

Expression is shown below for copy and paste convenience

expr {[mcget {subsession.ad.last.attr.memberOf}] contains "[class match -value [findstr [mcget {perflow.category_lookup.result.url}] "http" 28 "/"] eq acme_app.acme.com_dg]"}

Click Save in the resulting window.

Review the added URI - DataGroup Mapping agent. Ensure the Allow and Reject endings are set as shown.

In the administration window, navigate to Local Traffic -> iRules -> Data Group List and then click the acme_app.acme.com_dg data group link.

In the String field, enter serviceB and in the Value field enter CN=member-services-B,OU=Groups,DC=f5lab,DC=local then click the Add button. When correctly added, click the Update button.

TASK 5: Testing URI Dynamic & DataGroup Filtering

Return to Firefox test access to all the applications again for app.acme.com. Access to App1, Member Services A and the Admin application is still granted based on current AD Group Membership for user1.

Access to App2 and Member Services B are denied based on current AD Group Membership for user1.

TASK 6: Adding a new Application (App3)

Deploy App3 by clicking on the Deploy App3 PowerShell link provided on the jumphost desktop.

Return to Firefox to see the newly deployed App3 and test access to it. You may need to refresh your browser to see the new App3 applicationn button. Even though App3 is newly deployed, user1 access is still blocked based on AD Group membership. Note: No policy changes were required due to the dynamic URI mapping configured.

TASK 7: Dynamic Group Checks

Note: This provides the ability to dynamically enforce controlled application access without requiring the user to logon/logoff to acquire new permissions or restrictions. Navigate to Access -> Profiles/Policies -> Per-Request Policies and then click the Edit link for the app.acme.com_prp Per Request Policy (or use the already open browser tab). In the resulting Visual Policy Editor window, click on the Add New Subroutine link.

Enter Dynamic GroupCheck in the Name field and then click Save.

Click on the + (Plus Symbol) to expand the Dynamic GroupCheck Subroutine. Then click on the + (Plus Symbol) between the In and Out tags.

In the resulting window, click the Assignment tab, then select the radio button on the Variable Assign row, then the click Add Item button.

In the Variable Assign window, click the Add new entry button. In the new added row, click the Change link.

Modify the empty assignment as follows, then click the Finished button. Custom Variable: subsession.logon.last.username Session Variable: session.logon.last.username

Verify the variable assignment, then click the Save button.

In the Dynamic GroupCheck Subroutine click the + (Plus Symbol) following the Variable Assign

In the resulting window, click the Authentication tab, then select the radio button on the AD Query row, then click Add Item.

In the resulting AD Query window, select /Common/f5lab.local from the Server dropdown. Enter the following sAMAccountName=%{subsession.logon.last.username} in the SearchFilter field. Under the Required Attributes section click the X icon for all attributes except memberOf (row 9). Click the Save button when completed.

In the Dynamic GroupCheck Subroutine, click the Subroutine Settings/Rename link.

In the Dynamic GroupCheck Subroutine Settings change the following values: Inactivity Timeout (sec): 60 Max Subsession Life (sec): 60 Subroutine Timeout (sec): 120 Click the Save button.

Verify the Dynamic GroupCheck Subroutine contains both AD Query and Variable Assign objects.

In the main section of the app.acme.com_prp policy click the + (Plus Symbol) in both the apps and member branches. In the resulting pop-up window, click the Subroutines tab, the click the radio button on the Dynamic GroupCheck and then click the Add Item button. Do this for both branches.

Review the policy changes to confirm subroutines have been added correctly.

TASK 8: Testing Dynamic Group Checks

Add user1 to the app2, app3 and member-service-B AD Groups by clicking on the Add-User1-to-App2, Add-User1-to-App3 and Add-User1-to-MemberServiceB PowerShell scripts on the jumphost desktop.

Return to Firefox test access to applications app1, app2 and app3. Note: 60 seconds should elapse (the subsession timeout) before testing access to the applications begin.

Test access to the ServiceB application. Note: 60 seconds should elapse (the subsession timeout) before testing access to the application begins.

Return to Jumphost desktop and run the Remove-User1-from-App2. Return to Firefox test access to application app2. Note: 60 seconds should elapse (the subsession timeout) before testing to the application begins. Note: No user logon/logoff event needed to occur to change application access!

TASK 9: Step-Up Authentication (Client Cert Auth)

Note: This provides the ability to require additional authentication/authorization to priviledged pages or resources. Navigate to Access -> Profiles/Policies -> Per-Request Policies and then click the Edit link for the app.acme.com_prp Per Request Policy (or use the already open browser tab). In the resulting Visual Policy Editor window, click on the Add New Subroutine link

Enter CertAuth in the Name field and then click Save.

Click on the + (Plus Symbol) to expand the CertAuth Subroutine. Then click on the + (Plus Symbol) between the In and Out tags.

In the resulting window, click the Authentication tab, then select the radio button on the 0n-Demand Cert Auth row, then click Add Item.

In the resulting On-Demand Cert Auth** window, select Require from the Auth Mode dropdown and click Save.

In the On-Demand Cert Auth Subroutine, click the Edit Terminals link.

In the Terminals window, click the Add Terminal link. In the resulting section, change the Name to Fail, select the red color (#2) from the dropdown and then click Save. The arrows can be used to change positions.

In the On-Demand Cert Auth Subroutine, click the Out terminal link and change the value the Fail by clicking the radio button and then clicking Save.

In the main section of the app.acme.com_prp policy click the + (Plus Symbol) in the admin branch. In the resulting pop-up window, click the Subroutines tab, the click the radio button on the CertAuth and then click the Add Item button.

Review the added CertAuth Subroutine. Ensure the Allow and Reject endings are set as shown.

TASK 10: Testing Step-Up Authentication (Client Cert Auth)

Return to Firefox. Test access to the Admin application.

A Certificate Authentication prompt will now display. Review the certificate and click the OK button.

Access is now correctly granted to the Admin application.

TASK 11: End of Lab2

This concludes Lab2, feel free to review and test the configuration.