APM Cookbook: Single Sign On (SSO) using Kerberos
To get the APM Cookbook series moving along, I’ve decided to help out by documenting the common APM solutions I help customers and partners with on a regular basis. Kerberos SSO is nothing new, but seems to stump people who have never used Kerberos before. Getting Kerberos SSO to work with APM is straight forward once you have the Active Directory components configured. Overview I have a pre-configured web service (IIS 7.5/Sharepoint 2010) that is configured for Windows Authentication, which will send a “Negotiate” in the header of the “401 Request for Authorization”. Make sure the web service is configured to send the correct header before starting the APM configuration by accessing the website directly and viewing the headers using browser tools. In my example, I used the Sharepoint 2010/2013 iApp to build the LTM configuration. I’m using a single pool member, sp1.f5.demo (10.10.30.2) listening on HTTP and the Virtual Server listening on HTTPS performing SSL offload. Step 1 - Create a delegation account on your domain 1.1 Open Active Directory Users and Computers administrative tool and create a new user account. User logon name: host/apm-kcd.f5.demo User logon name (pre-Windows 2000): apm-kcd Set the password and not expire 1.2 Alter the account and set the servicePrincipcalName. Run setspn from the command line: setspn –A host/apm-kcd.f5.demo apm-kcd A delegation tab will now be available for this user. Step 2 - Configure the SPN 2.1 Open Active Directory Users and Computers administrative tool and select the user account created in the previous step. Edit the Properties for this user Select the Delegation tab Select: Trust this user for delegation to specified services only Select: Use any authentication protocol Select Add, to add services. Select Users or Computers… Enter the host name, in my example I will be adding HTTP service for sp1.f5.demo (SP1). Select Check Names and OK Select the http Service Type and OK 2.2 Make sure there are no duplicate SPNs and run setspn –x from the command line. Step 3 - Check Forward and Reverse DNS DNS is critical and a missing PTR is common error I find when troubleshooting Kerberos SSO problems. From the BIG-IP command line test forward and reverse records exist for the web service using dig: # dig sp1.f5.demo ;; QUESTION SECTION: ;sp1.f5.demo. IN A ;; ANSWER SECTION: sp1.f5.demo. 1200 IN A 10.10.30.2 # dig -x 10.10.30.2 ;; QUESTION SECTION: ;2.30.10.10.in-addr.arpa. IN PTR ;; ANSWER SECTION: 2.30.10.10.in-addr.arpa. 1200 IN PTR sp1.f5.demo. Step 4 - Create the APM Configuration In this example I will use a Logon Page to capture the user credentials that will be authenticated against Active Directory and mapped to the SSO variables for the Kerberos SSO. 4.1 Configure AAA Server for Authentication Access Policy >> AAA Servers >> Active Directory >> “Create” Supply the following: Name: f5.demo_ad_aaa Domain Name: f5.demo Domain Controller: (Optional – BIG-IP will use DNS to discover if left blank) Admin Name and Password Select “Finished" to save. 4.2 Configure Kerberos SSO Access Policy >> SSO Configurations >> Kerberos >> “Create” Supply the following: Name: f5.demo_kerberos_sso Username Source: session.sso.token.last.username User Realm Source: session.ad.last.actualdomain Kerberos Realm: F5.DEMO Account Name: apm-kcd (from Step 1) Account Password & Confirm Account Password (from Step1) Select “Finished” to save. 4.3 Create an Access Profile and Policy We can now bring it all together using the Visual Policy Editor (VPE). Access Policy >> Access Profiles >> Access Profile List >> “Create” Supply the following: Name: intranet.f5.demo_sso_ap SSO Configuration: f5.demo_kerberos_sso Languages: English (en) Use the default settings for all other settings. Select “Finished” to save. 4.4 Edit the Access Policy in the VPE Access Policy >> Access Profiles >> Access Profile List >> “Edit” (intranet.f5.demo_sso_ap) On the fallback branch after the Start object, add a Logon Page object. Leave the defaults and “Save”. On the fallback branch after the Logon Page object, add an AD Auth object. Select the Server Select “Save” when your done. On the Successful branch after the AD Auth object, add a SSO Credential Mapping object. Leave the defaults and “Save”. On the fallback branch after the SSO Credential Mapping, change Deny ending to Allow. The finished policy should look similar to this: Don't forget to “Apply Access Policy”. Step 5 – Attach the APM Policy to the Virtual Server and Test 5.1 Edit the Virtual Server Local Traffic >> Virtual Servers >> Virtual Server List >> intranet.f5.demo_vs Scroll down to the Access Policy section and select the Access Profile. Select “Update” to save. 5.2 Test Open a browser, access the Virtual Server URL (https://intranet.f5.demo in my example), authenticate and verify the client is automatically logged on (SSO) to the web service. To verify Kerberos SSO has worked correctly, check /var/log/apm on APM by turning on debug. You should see log events similar to the ones below when the BIG-IP has fetched a Kerberos Ticket. info websso.1[9041]: 014d0011:6: 33186a8c: Websso Kerberos authentication for user 'test.user' using config '/Common/f5.demo_kerberos_sso' debug websso.1[9041]: 014d0018:7: sid:33186a8c ctx:0x917e4a0 server address = ::ffff:10.10.30.2 debug websso.1[9041]: 014d0021:7: sid:33186a8c ctx:0x917e4a0 SPN = HTTP/sp1.f5.demo@F5.DEMO debug websso.1[9041]: 014d0023:7: S4U ======> ctx: 33186a8c, sid: 0x917e4a0, user: test.user@F5.DEMO, SPN: HTTP/sp1.f5.demo@F5.DEMO debug websso.1[9041]: 014d0001:7: Getting UCC:test.user@F5.DEMO@F5.DEMO, lifetime:36000 debug websso.1[9041]: 014d0001:7: fetched new TGT, total active TGTs:1 debug websso.1[9041]: 014d0001:7: TGT: client=apm-kcd@F5.DEMO server=krbtgt/F5.DEMO@F5.DEMO expiration=Tue Apr 29 08:33:42 2014 flags=40600000 debug websso.1[9041]: 014d0001:7: TGT expires:1398724422 CC count:0 debug websso.1[9041]: 014d0001:7: Initialized UCC:test.user@F5.DEMO@F5.DEMO, lifetime:36000 kcc:0x92601e8 debug websso.1[9041]: 014d0001:7: UCCmap.size = 1, UCClist.size = 1 debug websso.1[9041]: 014d0001:7: S4U ======> - NO cached S4U2Proxy ticket for user: test.user@F5.DEMO server: HTTP/sp1.f5.demo@F5.DEMO - trying to fetch debug websso.1[9041]: 014d0001:7: S4U ======> - NO cached S4U2Self ticket for user: test.user@F5.DEMO - trying to fetch debug websso.1[9041]: 014d0001:7: S4U ======> - fetched S4U2Self ticket for user: test.user@F5.DEMO debug websso.1[9041]: 014d0001:7: S4U ======> trying to fetch S4U2Proxy ticket for user: test.user@F5.DEMO server: HTTP/sp1.f5.demo@F5.DEMO debug websso.1[9041]: 014d0001:7: S4U ======> fetched S4U2Proxy ticket for user: test.user@F5.DEMO server: HTTP/sp1.f5.demo@F5.DEMO debug websso.1[9041]: 014d0001:7: S4U ======> OK! Conclusion Like I said in the beginning, once you know how Kerberos SSO works with APM, it’s a piece of cake!Shared Authentication Domains on BIG-IP APM
How to share an APM session across multiple access profiles. A common question for someone new to BIG-IP Access Policy Manager (APM) is how do I configure BIG-IP APM so the user only logs in once. By default, BIG-IP APM requires authentication for each access profile. This can easily be changed by sending the domain cookie variable is the access profile’s SSO authentication domain menu. Let’s walk through how to configure App1 and App2 to only require authentication once. We’ll start with App1’s Access Profile. Once you click through to App1’s settings, in the Top menu, select SSO/Auth Domains. For the Domain Cookie, we’ll set the value to f5demo.com since App1 and App2 use this domain and it is a FQDN. Of course, click Update. Next, we’ll select App2’s Access Profile. Like App1, we select SSO/Auth Domains and set the Domain Cookie value to f5demo.com. To make sure it works, we’ll launch App1 in our browser. We’re prompted for authentication and enter our credentials and luckily, we have a successful login. And then we’ll try to login to App2. And when we click it, we’re not prompted again for authentication information and gain access without prompts. Granted this was a single login request for two simple applications but it can be scaled for hundreds of applications. If you‘d like to see a working demo of this, check it out here. ps
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.0Post of the Week: Two-Factor Auth and SSO with BIG-IP
In this Lightboard Post of the Week, I answer a question about 2FA and SSO with AD/RSA on BIG-IP by creating a SSO Credential Mapping policy agent in the Visual Policy Editor, that takes the username and password from the logon page, and maps them to variables to be used for SSO services. Special thanks to senthil147for the question and a new 2018 MVP, MrPlastic (Lee Sutcliffe, which I flubbed) for the great answer. Posted Question on DevCentral: 2FA Authentication with SSO on APM psVDI Gateway Federation with BIG-IP
Today let’s look at how F5 BIGIP APM can consolidate, secure and federate all the core VDI gateways technology. For instance, if an organization decides move from one VDI technology to another or if you’re consolidating VDI technologies, BIG-IP can help. On the BIG-IP we’ve set up three VDI environments. Microsoft RDS/RDP with a broker authentication server, VMware Horizon and Citrix XenApp. With only a corporate account, a user can authenticate to all of them as needed and access all available desktop content. In this example, we connect to the BIG-IP APM. This is the default view. And here we’ve put some advanced security fields like OTP or multifactor authentication for instance. So here we’d use our username and password and for additional security we'll choose a secondary grid. By default, a grid is not generally available from any of the VDI vendors. When we select grid, BIG-IP APM will present a grid for a PIN entry. This is provided through a partnership with Gemalto. BIG-IP is connecting to Gemalto servers to present the grid to the user. We then enter our confidential PIN. Upon auth, we’re presented with our BIG-IP APM Webtop and BIG-IP did the necessary single sign on for all the VDI technologies and environments assigned to us. With a single, multifactor authentication we’re able to gain access to our federated BIG-IP Webtop and select the specific VDI resource we need. From an administrative view, here is the full Visual Policy Editor (VPE) for the overall solution. This also shows where the OTP/Grid is if you follow the Host FQDN path. And here are the specific inspections and criteria for the VDI scenario. You can see a path for each VDI vendor along with specific inspections and actions depending on the situation. Special thanks to F5 Sr. Security SE Matthieu Dierick for the explanation and you can watch the demo video. psLegacy 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. psLightboard Lessons: SSO to Legacy Web Applications
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. In this Lightboard Lesson, I draw out how VMware and F5 helps remove these complexities and enable productive, any-device app access. By enabling secure SSO to Kerberos constrained delegation (KCD) and header-based authentication apps, VMware Workspace ONE and F5 BIG-IP APM help workers securely access all the apps they need—mobile, cloud and legacy—on any device anywhere. ps Related: Single Sign-On (SSO) to Legacy Apps Using BIG-IP & VMware Workspace ONE Simple & Secure Access to Legacy Enterprise Applications (pdf) Lightboard Lessons PlaylistIn 5 Minutes or Less Video - BIG-IP APM & Citrix XenApp
Watch how F5 customers can now simply use BIG-IP Access Policy Manager or BIG-IP Edge Gateway to consolidate access control in a central location, keeping infrastructure administration concerns to a minimum. With BIG-IP solutions, customers enjoy the flexibility and scalability needed to extend Citrix applications to both local and remote users without changing local XenApp deployments or requiring STA to provide secure remote access to applications. Highlights of deploying Citrix and F5 technologies together include: Reduced Management Time and OpEx – By simplifying and centralizing local and remote access authentication, BIG-IP solutions eliminate the need for customers to add separate Citrix STA infrastructure or make changes to existing Web Interface servers, resulting in an environment that is less expensive to deploy and requires less time to manage. Simplified Configuration and Deployment – With BIG-IP solutions, administrators can support users of Citrix applications with fewer devices, configure deployments to support flexible access models, and easily scale the environment. This fully integrated functionality makes it quick and easy for customers to set up and deploy local and remote access capabilities for Citrix applications, keeping users productive. Centralized and Comprehensive Access Control – Unlike the separate Citrix products required to adequately support applications for remote users, BIG-IP solutions provide centralized application access control and use a single access policy to support all types of users securely, so IT teams can be confident that application access is aligned with the organizations’ specific business priorities and security policies. &amplt;/p&ampgt; &amplt;p&ampgt;ps&amplt;/p&ampgt; &amplt;p&ampgt;Resources:&amplt;/p&ampgt; &amplt;ul&ampgt; &amplt;li&ampgt;&amplt;a href="http://www.f5.com/news-press-events/press/2010/20101214.html" _fcksavedurl="http://www.f5.com/news-press-events/press/2010/20101214.html"&ampgt;F5 Simplifies and Centralizes Access Management for Citrix Applications&amplt;/a&ampgt; &amplt;/li&ampgt; &amplt;li&ampgt;&amplt;a href="downloads.f5.com" _fcksavedurl="downloads.f5.com"&ampgt;BIG-IP v10.2.1 Download (Log in required)&amplt;/a&ampgt; &amplt;/li&ampgt; &amplt;li&ampgt;&amplt;a href="http://www.f5.com/products/big-ip/access-policy-manager.html" _fcksavedurl="http://www.f5.com/products/big-ip/access-policy-manager.html"&ampgt;BIG-IP Access Policy Manager&amplt;/a&ampgt; &amplt;/li&ampgt; &amplt;li&ampgt;&amplt;a href="http://www.f5.com/products/big-ip/edge-gateway.html" _fcksavedurl="http://www.f5.com/products/big-ip/edge-gateway.html"&ampgt;BIG-IP Edge Gateway&amplt;/a&ampgt; &amplt;/li&ampgt; &amplt;li&ampgt;&amplt;a href="https://www.youtube.com/user/f5networksinc" _fcksavedurl="https://www.youtube.com/user/f5networksinc"&ampgt;F5 YouTube Channel&amplt;/a&ampgt; &amplt;/li&ampgt; &amplt;/ul&ampgt; &amplt;table border="0" cellspacing="0" cellpadding="2" width="325"&ampgt;&amplt;tbody&ampgt; &amplt;tr&ampgt; &amplt;td valign="top" width="200"&ampgt;Connect with Peter: &amplt;/td&ampgt; &amplt;td valign="top" width="123"&ampgt;Connect with F5: &amplt;/td&ampgt; &amplt;/tr&ampgt; &amplt;tr&ampgt; &amplt;td valign="top" width="200"&ampgt;&amplt;a href="http://www.linkedin.com/pub/peter-silva/0/412/77a" _fcksavedurl="http://www.linkedin.com/pub/peter-silva/0/412/77a"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_linkedin[1]" border="0" alt="o_linkedin[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_linkedin.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_linkedin.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="https://devcentral.f5.com/s/weblogs/psilva/Rss.aspx" _fcksavedurl="https://devcentral.f5.com/s/weblogs/psilva/Rss.aspx"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_rss[1]" border="0" alt="o_rss[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_rss.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_rss.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="http://www.facebook.com/f5networksinc" _fcksavedurl="http://www.facebook.com/f5networksinc"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_facebook[1]" border="0" alt="o_facebook[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="http://twitter.com/psilvas" _fcksavedurl="http://twitter.com/psilvas"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_twitter[1]" border="0" alt="o_twitter[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;/td&ampgt; &amplt;td valign="top" width="123"&ampgt; &amplt;a href="http://www.facebook.com/f5networksinc" _fcksavedurl="http://www.facebook.com/f5networksinc"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_facebook[1]" border="0" alt="o_facebook[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="http://twitter.com/f5networks" _fcksavedurl="http://twitter.com/f5networks"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_twitter[1]" border="0" alt="o_twitter[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="http://www.slideshare.net/f5dotcom/" _fcksavedurl="http://www.slideshare.net/f5dotcom/"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_slideshare[1]" border="0" alt="o_slideshare[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_slideshare.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_slideshare.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="https://www.youtube.com/f5networksinc" _fcksavedurl="https://www.youtube.com/f5networksinc"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_youtube[1]" border="0" alt="o_youtube[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_youtube.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_youtube.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt;&amplt;/td&ampgt; &amplt;/tr&ampgt; &amplt;/tbody&ampgt;&amplt;/table&ampgt; &amplt;p&ampgt;Technorati Tags: &amplt;a href="http://technorati.com/tags/F5" _fcksavedurl="http://technorati.com/tags/F5"&ampgt;F5&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/in+5+minutes" _fcksavedurl="http://technorati.com/tags/in+5+minutes"&ampgt;In 5 Minutes&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/integration" _fcksavedurl="http://technorati.com/tags/integration"&ampgt;integration&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/bigip" _fcksavedurl="http://technorati.com/tags/bigip"&ampgt;big-ip&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/Pete+Silva" _fcksavedurl="http://technorati.com/tags/Pete+Silva"&ampgt;Pete Silva&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/security" _fcksavedurl="http://technorati.com/tags/security"&ampgt;security&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tag/business" _fcksavedurl="http://technorati.com/tag/business"&ampgt;business&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tag/education" _fcksavedurl="http://technorati.com/tag/education"&ampgt;education&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tag/technology" _fcksavedurl="http://technorati.com/tag/technology"&ampgt;technology&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/application+delivery" _fcksavedurl="http://technorati.com/tags/application+delivery"&ampgt;application delivery&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/citrix" _fcksavedurl="http://technorati.com/tags/citrix"&ampgt;citrix&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/cloud" _fcksavedurl="http://technorati.com/tags/cloud"&ampgt;cloud&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/context-aware" _fcksavedurl="http://technorati.com/tags/context-aware"&ampgt;context-aware&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/xenapp" _fcksavedurl="http://technorati.com/tags/xenapp"&ampgt;xenapp&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/automation" _fcksavedurl="http://technorati.com/tags/automation"&ampgt;automation&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/web" _fcksavedurl="http://technorati.com/tags/web"&ampgt;web&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/video" _fcksavedurl="http://technorati.com/tags/video"&ampgt;video&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/blog" _fcksavedurl="http://technorati.com/tags/blog"&ampgt;blog&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/F5+APM" _fcksavedurl="http://technorati.com/tags/F5+APM"&ampgt;APM&amplt;/a&ampgt;&amplt;/p&ampgt;&amplt;/body&ampgt;&amplt;/html&ampgt; ps Resources: F5 Simplifies and Centralizes Access Management for Citrix Applications BIG-IP v10.2.1 Download (Log in required) BIG-IP Access Policy Manager BIG-IP Edge Gateway F5 YouTube Channel
