Using F5 as a Service Provider with Okta IdP
I've read part 1 and 2 of this article for how to connect F5 as a service provider to Okta: Secure Access to Web Applications with F5 and Okta... - DevCentral However, it doesn't provide instructions for how to get theSingle sign on URLand theAudience URIfor the app, and I also can't find an article for how to connect F5 to the application to pass the header or kerberos auth to. Could someone help me? I'm basically looking for what information I'll need to retrieve and give to the owners of the systems using legacy auth in order to connect those systems to F5 to use Okta auth with them.
Enhanced security with F5 BIG-IP APM and Okta through Multi-Factor Authentication
This article is the third in the three-part series. Go to Part 1 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (1 of 2) Go to Part 2 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (2 of 2) Multi-factor Authentication (MFA) is a security best practice that enhances authentication by requesting two or more verifiable authentication factors. Common authentication factors are: Something You Know, Something You Have, and Something You Are. In addition to configuring native MFA support, the F5 BIG-IP Access Policy Manager (APM) system offers the flexibility to combine multiple authentication mechanisms from partners like Okta. In this DevCentral blog, we will look at how to configure APM for Okta MFA to authenticate using Something You Know and Something You Have. The HTTP connector for Okta MFA is supported in F5 BIG-IP APM system running TMOS v16.0 or later. Setting up Okta MFA Follow the steps below to configure ‘Okta Verify’ for mobile MFA. Navigate to Okta web UI >> Security >> Multifactor and activate Okta Verify. Figure 1: Activate Okta Verify MFA Click on the Factor Enrollment option in the sub menu, then click on the Edit button. On the popup screen, choose Everyone option under Assign to groups. When done, press the Update Policy button. Figure 2: Assign the MFA policy to the user group Configuring F5 BIG-IP APM for Okta MFA Follow the steps below to configure the HTTP connector for Okta MFA. Create a DNS Resolver to Resolve the DNS Queries and Cache the Results On the main menu, navigate to Network >> DNS Resolvers. On the DNS Resolvers web page, click on the Create button. Enter a name and click the Finished button. On the DNS Resolvers web page, click on the above created DNS resolver list name. Navigate to the Forward Zones tab in the sub menu to add any recursive nameservers. When done, press the Finished button. Figure 3: Create the DNS resolver Creating an HTTP Connector and Assign the DNS Resolver Navigate to Access >> Authentication >> HTTP Connector and click on HTTP Connector Transport. On the HTTP Connector Transport web page, click on the Create button. Enter a name and select the above created DNS Resolver and the SSL Server Profile. When done, press the Save button. Figure 4: Sample HTTP connector configuration Creating the Okta Connector and Assigning the HTTP Connector Navigate to Access >> Authentication and click on Okta Connector. On the Okta Connector web page click on the Create button. Enter a name and select the above created HTTP connector. Type the Okta Domain name and paste the Okta API Token from Okta. When done, press the Save button. Figure 5: Sample Okta connector configuration Note: To create a new Okta API token, navigate to Okta web UI >> Security >> API and click on Tokens. Creating and assigning the Access profile and Access Policy to the Application Follow the steps below to create an access profile and per-request access policy for Okta MFA and assign them to the application. Creating the Access Profile and Access Policy Navigate to Access >> Profiles/Policies and click on Access profiles (Per Session Policies). click on the Create button to create a new access profile. Enter a name and select All in the Profile Type drop down-list. Scroll down to the Language Settings section. Select the preferred language and move it to the left into Accepted Languages box. When done, press the Finished button. Figure 6: Sample access profile configuration Next, navigate to Access >> Profiles/Policies and click on Per-Request Policies. Click on Create button to create a new access policy. Enter a name and select All in the Profile Type drop down list. Scroll down to the Language Settings section. Select the preferred language and move it to the left into Accepted Languages box. When done, click on Finished button. On the Per-Request Policies page, click the Edit button next to the above created policy. Create the per-request policy using the Visual Policy Editor as show in the figure 7. Figure 7: Sample per-request policy To add the Okta MFA, click on the + sign. On the popup screen, click on the Authentication tab and select Okta MFA. When done, click on the Add Item button. On the popup screen, enter a name and choose the above configured Okta connector. When done, click the Save button. Figure 8: Sample Okta MFA configuration with ‘Okta Connector’ assigned Assigning the Access Profile and Access Policy to the Virtual Server Navigate to Local Traffic >> Virtual Servers >> Virtual Server List and click on the Virtual server configured for the application. Scroll down to the Access Policy section and select the Access Profile and the Per-request Policy. When done, press the Update button. Figure 9: Assign the access profile and per-request policy to the virtual server Validating and Verifying the Solution Follow the steps below to setup and validate mobile MFA using ‘Okta Verify’. Download the ‘Okta Verify’ app on your mobile device. Login to Okta Web UI using your username and password. On the dashboard, click on the user setting. Under the extra verification section, click on the Setup button. On the resulting web page, click on Configure Factor and choose the Device Type (Android or Apple). Scan the presented barcode with the Okta mobile app for verification, this completes the setup. Access the application app.f5sec.net from a browser. When prompted enter the username and password. After successful authentication, you will be prompted for MFA, click on the Send Push button. Complete the MFA using the Okta Verify app on your mobile device. Figure 10: User prompted for MFA after successful authentication Conclusion The joint F5 and Okta MFA integration offers a compelling solution for customers who are interested in securely accessing enterprise applications on-premises and in any cloud by increasing the assurance of authentication. Additional Resources Part 1 - Secure Access to Web Applications with F5 and Okta using SAML 2.0 Part 2 - Secure Access to Web Applications with F5 and Okta using SAML 2.0 BIG-IP APM Product Information: Knowledge Center Free Training Course: Getting Started with BIG-IP Access Policy Manager (APM) Lightboard Lesson: F5 Access Policy Manager and Okta - Single Sign On and Multi-Factor Authentication External Resource: F5 | Okta partnershipSecure Access to Web Applications with F5 and Okta using SAML 2.0 (2 of 2)
This article is the second in a two-part series. Go to Part 1 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (1 of 2) Step 2: Configure F5 BIG-IP APM as SAML SP for the Application Refer to the step by step instructions and screenshots below to configure F5 BIG-IP APM as SAML SA for a new application called app.f5sec.net. 2.1 Import Certificate for the Application Import the certificate for app.f5sec.net. This certificate will be later referenced when configuring the application. •Log in to the F5 BIG-IP System. • On the F5 Configuration Utility (Web UI) Main menu, navigate to System > Certificate Management > Traffic Certificate Management > SSL Certificate List. •On the Traffic Certificate Management page, click the Import button on the right-hand corner. •On the SSL Certificate/Key Source page, select Key from the Import Type drop-down box. •Specify a Key Name and browse to the folder that contains the Key. After selecting the key file, click Import. • Back in the Traffic Certificate Management page, click on the imported Key name. • In the General Properties page, click on the Import button. •Browse to the folder that contains the Certificate. After selecting the certificate file, click Import. Figure 9: Importing application certificate and key 2.2 Using Guided Configuration The F5 BIG-IP APM Guided Configuration presents a completely new and streamlined user experience. This workflow-based architecture provides intuitive configuration steps tailored for a selected use case. The steps below will walk through the Guided Configuration to build the application and configure F5 BIG-IP APM as SAML SP. •On the F5 Web UI Main menu, navigate to Access > Guided Configuration. •Click on the Federation tile. From the expanded option, click on the SAML Service Provider tile. Figure 10: Guided configuration initial selection. •Take a moment to review the various configuration options on the SAML Service Provider page. Figure 11: SAML Service Provider page •Satisfy any of the DNS, NTP, Interface, VLAN, Route, and Self IP configuration prerequisites from this initial configuration page. •Scroll down and click Next. 2.2.1 Configure Service Provider Properties •To configure these properties, follow the guidance below. Figure 12: Sample ‘Service Provider Properties’ configuration. •Accept the remaining default entries and click Save & Next. 2.2.2 Configure Virtual Server Properties •To configure a virtual server for the app, follow these steps. Figure 13: Sample ‘Virtual Server Properties’ configuration. •Click Save & Next. 2.2.3 Configure Okta Identity Provider Connector •To configure Okta as the external SAML IdP provider, follow the steps below. Figure 14: Sample Okta IdP configuration. •Click Save & Next. 2.2.4 Create a Pool •To create a load balancing pool of application servers, follow the steps below. Figure 15: Sample ‘Pool Properties’ configuration. •Click Save & Next. 2.2.5 Configure Single Sign-On Settings •To configure Okta as the external SAML IdP provided, follow the steps below. Figure 16: Sample ‘Single Sign-on Settings’ configuration. •Click Save & Next. 2.2.6 Endpoint Checks Select the Enable Endpoint Checks radio button to enable endpoint checks. For this demonstration, we will leave this setting at default. Figure 17: 'Endpoint Checks Properties' page to enable and configure endpoint checks. •Click Save & Next. 2.2.7 Session Management Leave the Timeout Settings at default. Figure 18: Default timeout settings •Click Save & Next. 2.2.8 Summary Review the Summary screen. When done, scroll down and click Deploy. Figure 20: Confirmation of a successful deployment. • Click on the Finish button. This completes the F5 BIG-IP APM configuration. Step 3: Verification We will verify the solution by accessing app.f5sec.net. •Open a web browser on an end host and navigate to https://app.f5sec.net. Notice the request will be redirected to Okta.com for user authentication. Figure 21: Redirection to Okta for user authentication. •The application default web page prints all the headers. Notice that the HTTP_MYAUTHORIZATION header has been inserted with the appropriate value. Figure 22: HTTP_MYAUTHORIZATION header inserted with user identity value. Additional Resources Part 1 - Secure Access to Web Applications with F5 and Okta using SAML 2.0 BIG-IP APM Product Information: Knowledge Center Free Training Course: Getting Started with BIG-IP Access Policy Manager (APM) Lightboard Lesson: F5 Access Policy Manager and Okta - Single Sign On and Multi-Factor Authentication External Resource: F5 | Okta partnershipSecure Access to Web Applications with F5 and Okta using SAML 2.0 (1 of 2)
This article is the first in a two-part series. Go to Part 2 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (2 of 2) Introduction Despite recent advances in security and identity management, controlling and managing access to applications through the web—whether by onsite/remote employees or contractors, partners, customers, or the public—is as difficult as ever. IT teams are challenged to control access based on granular characteristics such as user role while still providing fast authentication and, preferably, unified access with single sign-on (SSO) capabilities. The ability to recognize and stop attempts at unauthorized access is critical in today’s security environment. The joint F5 BIG-IP® Access Policy Manager® (APM) and Okta identity management platform solution address these challenges. This solution provides extended access management capabilities across on-premises and cloud environments enabling organizations to secure web applications anywhere.In addition to authentication management and policy-based authorizations, the solution also supports applications with header-based and Kerberos based authentication. The F5 and Okta Solution In this SAML 2.0 integrated solution (shown in Figure 1), •Okta is the Identity Provider (IdP). Users can be defined locally within Okta. In most cases, an on-premises Active Directory and/or LDAP is the source of identities and is integrated with Okta via Okta’s AD/LDAP agent. •Between Okta and the F5 BIG-IP system, a SAML trust is built with the BIG-IP platform acting as a SAML service provider (SP). •The target applications are protected behind the BIG-IP reverse proxy by header-based or Kerberos authentication. •SAML assertion from Okta is consumed by the BIG-IP system, which then translates the assertion appropriately for the downstream application based on its authentication scheme. Figure 1: The basic integration between the F5 BIG-IP system and Okta for single sign-on (SSO) Deployment Procedure This procedure described below is based on a lab environment. The instructions below may be modified to match your specific needs or requirements. Prerequisites •Refer to AskF5 for additional information, including how to initially set up a BIG-IP environment including basic BIG-IP® Local Traffic Manager® (LTM) and BIG-IP APM configurations. F5 BIG-IP TMOS® version 15.1 is used for this demonstration. However, these practices apply for versions 11.0 and later. •For additional information about configuring the Okta portion of the solution, refer to Okta documentation. Step 1: Configure Okta as SAML IDP for a New Application Refer to the step by step instructions and screenshots below to configure Okta as a SAML IdP for a new application called app.f5sec.net. 1.1 Okta Classic User Interface For this lab demonstration, we are using the Okta developer account. Click here to sign up for an Okta developer account, if you don’t already have one. •Log in to the Okta developer portal using your username and password. •For this demonstration, we will be using the Classic UI. On the top left corner of the developer portal, change the drop-down from Developer Console to Classic UI. Figure 2: Switching the Okta user interface to the Classic option. 1.2 Build a New Application We will build a new web application for SAML 2.0 integration. •On the main menu, hover on the Applications tab and click on Applications. •On the Applications page, click on the Add Application button. •On the Add Application page, click on the Create New App button. •In the Create a New Application Integration dialogue box, select the Web option in the Platform drop-down and SAML 2.0 as the Sign on method and click Create. Figure 3: Creating a new application for SSO using SAML 2.0 •On the Create SAML Integration page, under the General Setting section, enter the app name and click Next. Figure 4: Entering the app name •In the SAML Settings section, under the GENERAL options, enter the Single sign on URL and the Audience URI. Figure 5: Sample SAML configuration •Leave all other values as default and click Next. •In the next section, check the radio button that says, “I’m an OKTA customer adding an internal app”. •In the expanded window, select “This is an internal app that we have created” for App Type and click on Finish. Figure 6: Sample feedback configuration •In the resulting application page for app.f5sec.net, navigate to the SAML 2.0 section. •Right-click the Identity Provider Metadata hyperlink and click Save Link As. •Save the metadata.xml to the local system. We will be using this file later when configuring F5 BIG-IP APM as SAML SP. Figure 7: Exporting the IdP metadata 1.3 Assign Users to the Application Next, we will assign users to the application, granting them access. •Scroll up and click on the Assignments tab beneath app.f5sec.net. •Click on the Assign button and then again click Assign to People from the drop-down. •In the pop-up dialog box, click on the Assign button next to all the users that you want to assign access to app.f5sec.net web application. •When finished, click Done. Figure 8: Assigning users to the application This completes the Okta configuration. Next, we will move on to F5 BIG-IP APM for SAML SP and web app configuration. Part 2 - Secure Access to Web Applications with F5 and Okta using SAML 2.0F5 SAML IdP with Okta User Facing
Currently have F5 APM set up as a SAML IdP for ~10 SaaS providers. We also have an Okta environment set up with it's own SAML connections to other SaaS providers. We would like to start sending users 100% through Okta but do not want to migrate the current F5 IdP connections to Okta for reasons too long to describe here. Has anyone ever had users authenticate into Okta and at the same time be given access to all the SAML resources on the F5? If I made the F5 an SP for Okta, could I assign the existing F5 SAML resources and allow the user through? I don't believe this would work but am unable to think of other ways to achieve this. Any thoughts would be appreciated.Lightboard Lessons: F5 Access Policy Manager and Okta - Single Sign On and Multi-Factor Authentication
The F5 BIG-IP Access Policy Manager provides secureaccess to all your web applications. Many companies have a variety of users (Employees, Contractors, Partners, Suppliers, Customers, etc) and they also have a variety of web applications. Some of these applications are capable of utilizing advanced forms of authentication while others might require older or proprietary authentication mechanisms. This common situation presents a challenge to many companies because they want to give their users a "Single Sign-On" capability but it's very hard to do that when the various web applications require all different forms of authentication. The good news is that F5 andOkta have partnered together to create a solution that allows users a Single Sign-On capability with Multi-Factor Authentication while allowing access to all the various web applicatoins that require different forms of authentication. The F5 Access Policy Managerprovides accessto all kinds of web applications...no matter what kind of authentication requirements they have. Likewise, Oktaprovides identity management for all kinds of users. Using F5 and Okta together, you can securely identify all your users in one place and then provide those users with secure access to all the web applications they need to do their jobs. Check out this video to learn more about this solution!APM Cookbook: Okta MFA Integration
Since the launch of the Okta and F5 Integration Guide I've seen interest in leveraging this partnership take off. One aspect I've enjoyed is watching how customers address pain points they were not able to address previously. For example, providing multi-factor authentication (MFA) for Microsoft Exchange Outlook Web Access (OWA). This particular customer standardized on Okta's MFA solution but OWA was behind Microsoft Threat Management Gateway (TMG) and could not easily integrate with Okta. For this solution F5's Access Policy Manager (APM) will replace the TMG servers and leverage Okta's on-premises RADIUS agent for MFA via Okta Verify, which supports push notification - by far my favorite feature. I've included a video below that walks through the process of configuring Okta for RADIUS based multifactor as well as configuring APM to leverage Okta's RADIUS agent. https://youtu.be/jpoVo0nuilQ?list=PLAVmgu9Rja5Cyu7KhQ3CUJFNOI5Tr-Wk2 Okta Configuration On the Okta administrator portal you'll need to create a new Okta Sign-on policy: Security -> Policies. Once you name the new policy you'll need to add a rule: The crucial part here is to select RADIUS for the And Authenticates via option. F5 Configuration The F5 APM configuration is pretty straight forward since you can use the built-in VPE macro template for RADIUS authentication but we'll need to create a RADIUS AAA object first. Once the RADIUS AAA object is created go ahead and create a new Access Profile and customize your VPE as shown below - for detailed steps please watch the attached video. Pretty easy solution and we're just scratching the surface on what is possible. Can't wait to start playing with Okta's API via iRules LX!Legacy Application SSO with BIG-IP and Okta
IT organizations have a simple goal: make it easy for workers to access all their work applications from any device. But that simple goal becomes complicated when new apps and old, legacy applications do not authenticate in the same way. Today we’ll take you through BIG-IP APM’s integration with Okta, a cloud-based identity-as-a-service provider. The primary use case for this scenario is providing the user authentication through Okta and then Okta providing BIG-IP APM a SAML assertion so that BIG-IP can perform legacy SSO using either Kerberos Constrained Delegation (KCD) or Header Authentication. BIG-IP is the Service Provider (SP) in this SAML transaction. As we log on to a BIG-IP, you’ll see that we have two policies/application examples. Let’s click on the Edit button under Access Policy for app1-saml-sp-okta. This takes us to the Visual Policy Editor (VPE) for the first application. As the chart flows, BIG-IP is consuming the SAML authentication, then storing the SSO credentials and doing a Variable Assign so we know who the user is. The next entry, app3-saml-sp-okta, looks very similar. One of the things that is different however is for Header Authentication, we’re actually using a Per Request Policy. You can view/configure this by going to Access Policy>Per Request Policy. We click Edit (under Access Policy) and here via the flow, the user enters and on every request we’re going to remove the Okta header name, which is arbitrary and doesn’t need to be that value – could be any value you choose. But we want to make sure that no one is able to pad that header into a request. So we’ll remove it and insert the variables BIG-IP receives from Okta. This way the application can consume it and we know who that user is. So what does it look like? First, we’ll log into Okta and in the portal, we see two applications – the Header Auth and Kerberos Auth. We’ll test the Header authentication first and see that we’re logged into App1 using Header authentication. Tuser@f5demo.com was the account we logged into with Okta and we see the application has been single-signed into using that credential. Now let’s hit that Kerberos auth application. Here again, we’ve been SSO’d into the application. You may notice that the user looks a bit different here as F5DEMO\tuser since this time we used Kerberos Constrained Delegation. So we’ve obtained a Kerberos ticket from the domain controller for F5DEMO as the user to use. So the username can look a little different but it’s mainly about formatting. BIG-IP is able to consume that SAML assertion from Okta and then use SSO capabilities via Header or Kerberos for legacy applications. Watch Cody Green’s excellent demo of this integration. ps
