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!
Secure 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.0
Kerberos 401 authentication with form fallback
Hello, we are using APM for SAML authentication. Domain joined machines should authenticate transparently with Kerberos, users without the ability to use Kerberos (non domain joined, Firefox without negotiate-settings) should receive a form to login. Kerberos works fine, but users with non domain joined machines receive a browser authentication prompt and "Authentication required to access the resources.". Does anybody has set up such a scenario? Any help is appreciated.Secure 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 partnershipEnhanced 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 partnership
SAML Cookie Persistence after browser/system restart and across service providers
I am fairly new to the F5 world and in the beginning of setting up our LTM's as SAML IdP's for a variety of services. Our first use-case is Jive, which we have working and all the attributes are pulling across just fine, authentication is fine, everything is functional as is. I'm having a hard time translating what we want the user experience to be into the next phase of the configuration. Our hope was that we could authenticate a user to the LTM, they would be provided a cookie that was set to expire in 24 hours, that cookie would provide SSO access to other services that we'll be adding, and once the 24 hours is up the user would be asked to authenticate again regardless of which service they are logging in to. I've set the Maximum Session Timeout to 86400 seconds (24 hours) and set the cookie to persistent, but when I log in with a test account I don't see a new cookie created on the user system and closing the browser loses the session. In addition, I don't have another sandbox service provider to test with currently to ensure that the cookie we are hoping will be creating would be valid for that other service as well. Am I wrong in thinking that the F5 can provide a persistent cookie that survives beyond browser or systems restarts? Can the F5 only provide SSO for that time period and across SAML partners as long as that browser session is open? I presume I'm asking some pretty elementary stuff so forgive my lack of current knowledge. Any pointers on where I can read up on that or help managing my expectations would be appreciated.
Support for POST preservation when APM Multidomain SSO is configured
Problem this snippet solves: F5 doesn't support the preservation of the initial POST request when the Virtual Server has an access profile configured for Multidomain SSO. After authentication, the user is redirected to the initial URL endpoint and issue a GET request instead of a POST request. How to use this snippet: We share a code sample to demonstrate how to support POST preservation in this typical scenario. This irule may need some additional configuration and settings to work properly. As a PoC, we configured two endpoints : sp.expertlab.net and idp.expertlab.net on the same Virtual Server and access profile. The access profile is configured for Multidomain SSO and we prompt the user for a form based authentication. We also added a dummy form prompted to the user after authentication to simplify our testing. Please note that the irule has been successfully tested with Chrome and Firefox. We are still running tests for Internet Explorer and Edge Browsers. Note : APM behave differently between v11, v12 and v13. To make POST preservation work for v11 and v12, you need to add the following variable assign settings before the Allow ending in your access policy : session.server.body = Session Variable session.server.initial_req_body session.policy.result.redirect.url = Session Variable session.server.landinguri_base64 Please note that the order of variable assignment is very important. Moreover, you need to change the name of the request body session variable in the irule too (static::body_var) Flow in v13.x POST https://sp.example.net/post_action.php 307 Temporary Redirect - Location: https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA POST https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA 302 Found - Location: /my.policy GET https://idp.example.net/my.policy 200 OK POST https://idp.example.net/my.policy 302 Found - Location: https://sp.example.net/F5Networks-SSO-Resp?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA&TOKEN=123954 GET https://sp.example.net/F5Networks-SSO-Resp?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA&TOKEN=123954 302 Found - Location: https://sp.example.net/post_action.php?ct=application%2Fx-www-form-urlencoded GET https://sp.example.net/post_action.php?ct=application%2Fx-www-form-urlencoded 200 OK - Body contains JS to force an auto-POST action POST https://sp.example.net/post_action.php ... Flow in v12.x POST https://sp.example.net/post_action.php 307 Temporary Redirect - Location: https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA POST https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA 302 Found - Location: /my.policy GET https://idp.example.net/my.policy 200 OK POST https://idp.example.net/my.policy 302 Found - Location: https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA GET https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA 302 Found - Location: https://sp.example.net/F5Networks-SSO-Resp?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA&TOKEN=123954 GET https://sp.example.net/F5Networks-SSO-Resp?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA&TOKEN=123954 302 Found - Location: https://sp.example.net/post_action.php?ct=application%2Fx-www-form-urlencoded GET https://sp.example.net/post_action.php?ct=application%2Fx-www-form-urlencoded 200 OK - Body contains JS to force an auto-POST action POST https://sp.example.net/post_action.php ... Code : ### # POST preservation feature # for Virtual Server with Multidomain SSO configured # # require : APM ### ### # Special notes # To support POST preservation in v11 and v12, # the administrator needs to configure special session variable assignment before the Allow ending in a Access policy # session.server.body = Session Variable session.server.initial_req_body # session.policy.result.redirect.url = Session Variable session.server.landinguri_base64 ### ### # Release notes # # 2017/11/23 # * Basic support for POST preservation in v13 # * Add support for v11 and v12 environments # # 2017/11/24 # * Replace static::idp_host by [PROFILE::access primary_auth_service] # * Add a static var to enable or disable the dummy form designed for testing purposes # * Avoid POSTing real body multiple times. A dummy var is used to retrieve the original POST content # # 2017/11/25 # * Remove some coding errors # * Refactoring of some parts of the irule ### when RULE_INIT { set static::md_start_uri "/F5Networks-SSO-Req?SSO_ORIG_URI=" # for v11.x and v12.x deployment # set static::body_var "session.server.body" # for v13.x deployment set static::body_var "session.server.initial_req_body" # enable or disable autogenerated testing forms set static::dummy_form 1 } when HTTP_REQUEST { if { ![ACCESS::session exists [HTTP::cookie MRHSession]] and !([HTTP::path] eq "/F5Networks-SSO-Resp") } { if { [HTTP::method] eq "POST" } { # save post data set ct [HTTP::header Content-Type] set uri [HTTP::uri] if { [URI::query $uri] != "" } { set uri $uri&ct=[URI::encode $ct]&f5-mdsso-post=1 } else { set uri $uri?ct=[URI::encode $ct]&f5-mdsso-post=1 } HTTP::respond 307 noserver Location "[PROFILE::access primary_auth_service]$static::md_start_uri[URI::encode [b64encode https://[HTTP::host]$uri]]" Connection Close return } else { HTTP::respond 302 noserver Location "[PROFILE::access primary_auth_service]$static::md_start_uri[URI::encode [b64encode https://[HTTP::host][HTTP::uri]]]" Connection Close return } } if { [ACCESS::session exists [HTTP::cookie MRHSession]] and [HTTP::query] contains "f5-mdsso-post=1" and [ACCESS::session data get $static::body_var] != "" } { set ct [URI::decode [URI::query [HTTP::uri] ct]] set dummy [getfield [expr {rand()}] "." 2] ACCESS::session data set session.server.dummy $dummy ACCESS::session data set session.server.ct $ct HTTP::respond 200 content " this page is used to hold your data while you are being authorized for your request. you will be forwarded to continue the authorization process. if this does not happen automatically, please click the continue button below. " noserver Content-Type "text/html" return } if { [ACCESS::session exists [HTTP::cookie MRHSession]] and [HTTP::method] eq "POST" and [HTTP::payload] contains "dummy" and [ACCESS::session data get session.server.dummy] eq [URI::query "/?[HTTP::payload]" dummy] } { HTTP::header replace Content-Type [ACCESS::session data get session.server.ct] HTTP::payload replace 0 [HTTP::header Content-Length] [ACCESS::session data get $static::body_var] } }
Client side Kerberos problem with Mac OSX 10.9 and Safari 7.0.2
Hi all, I've got a working client side SSO access policy in APM providing access to an internal intranet. It works perfectly with Windows clients (with the right browser config) and I can get it working on Chrome on our Macs, once the macs have been issued with an initial kerberos ticket for the user's AD account (our KDC is Windows AD 2003). Safari just throws up an APM error page when the user connects with it saying, "Invalid Session ID: Your session may have expired." Checking the APM log even in debug mode doesn't show anything obvious for that session, you just see a message saying the session has been deleted, no kerberos processing begins. On the client side, in a HTTP trace I see this: Request GET /my.policy HTTP/1.1 Host: www.victoria.ac.nz Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Connection: keep-alive Proxy-Connection: keep-alive Cookie: LastMRH_Session=77c8fbae; MRHSession=d5087e7f0252687cc231819f77c8fbae; TIN=272000; __utma=189107500.700714022.1406696059.1406696059.1406696059.1; __utmb=189107500.3.10.1406696059; __utmc=189107500; __utmz=189107500.1406696059.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Accept-Language: en-us Referer: http://www.victoria.ac.nz/ Accept-Encoding: gzip, deflate Response HTTP/1.1 401 Unauthorized Server: Apache Content-Type: text/html; charset=utf-8 X-Frame-Options: DENY Pragma: no-cache Cache-Control: no-cache, must-revalidate Accept-Ranges: bytes Connection: close Date: Wed, 30 Jul 2014 04:54:09 GMT Content-Length: 335 WWW-Authenticate: Basic realm="staff.vuw.ac.nz" WWW-Authenticate: Negotiate Set-Cookie: LastMRH_Session=77c8fbae;path=/;secure Set-Cookie: MRHSession=ef9605c9ed0bca0206113f6077c8fbae;path=/;secure Request GET /my.policy HTTP/1.1 Host: www.victoria.ac.nz Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Connection: keep-alive Authorization: Negotiate key Snipped for securityYIIHXwYGKwYBBQUCoIIHUzCCB0+gITAfBgkqhkiG9xIBAgIGBiqFcCsOAwYKKwYBBAGCNwICCqKCBygEggckYIIHIAYJKoZIhvcSAQICAQBuggcPMIIHC6ADAgEFoQMCAQ6iBwMFAAAAAACjggYGYYIGAjCCBf6gAwIBBaERGw9TVEFGRi5WVVcuQUMuTlqiJTAjoAMCAQOhHDAaGwRIVFRQGxJ3d3cudmljdG9yaWEuYWMubnqjggW7MIIFt6ADAgEXoQMCAQSiggWpBIIFpdLbJ9FpJ//Bjl+ixeKwBjDZ/1uVgsnoQr4l+kqMazjtr/AILRjfY57mL4hSHX8EWgOObQ+6NlP=******** Proxy-Connection: keep-alive Cookie: LastMRH_Session=77c8fbae; MRHSession=d5087e7f0252687cc231819f77c8fbae; TIN=272000; __utma=189107500.700714022.1406696059.1406696059.1406696059.1; __utmb=189107500.3.10.1406696059; __utmc=189107500; __utmz=189107500.1406696059.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Accept-Language: en-us Referer: http://www.victoria.ac.nz/ Accept-Encoding: gzip, deflate Response HTTP/1.0 302 Found Server: BIG-IP Connection: Close Content-Length: 0 Location: /my.logout.php3?errorcode=20 Set-Cookie: LastMRH_Session=77c8fbae;path=/;secure Set-Cookie: MRHSession=d5087e7f0252687cc231819f77c8fbae;path=/;secure So it looks like Safari is presenting its Kerb ticket, but the F5 doesn’t like it. Anyone got any clues? Thanks, Gavin
