Skip to main content
Nintex Community Menu Bar
 

Configuring SSL-offloading with F5 Load Balancers and K2

KB001679

PRODUCT
K2 Five
K2 blackpearl
BASED ON
K2 blackpearl 4.6.9

 

Summary

When an environment is setup to use F5 Load balancers with reverse proxies and SSL Off-Loaders to separate users into different zones other than where K2 is configured, the following issue may occur:

When users attempt to connect from an external zone outside of the K2 zone for claims sign in or Windows Authentication, an HTTP 404 error may occur, or errors like "Multiple Authentication Requests Detected" may appear.

 

To solve this issue, the F5 reverse proxy must be setup correctly for the following K2 sites and services:

  • K2 Designer site
  • K2 Runtime site
  • K2 View Flow site
  • K2 Workspace site
  • Identity STS Services
  • SharePoint 2010 sites
  • SharePoint 2013 sites
     
Ensure that the Identity STS Site is rewritten correctly within each site listed above. Not rewriting correctly results in the 404 errors and the sites are not reachable for users in the external zone.

 

 

F5 Load Balancer Setup for K2

The information in this KB article is based on tests performed on F5 version 11.4.1 and a software load balancer. This article provides guidance on setting up F5 load balancers - setup steps may differ depending on the version of F5 you have.

To ensure external users are able to access the K2 sites, the following must be setup on the F5 Load balancer.

For all sites detailed in the Summary section, a rewrite profile must be created on the F5 Load Balancer. Within each of the Profiles, the URI Rules must be setup correctly in order for communication between the external (HTTPS) and internal (HTTP) sites as shown in the example below. Note that 404 errors occur if the rewrite profiles are not correct.

Image

Use the following settings for each rewrite profile:
K2 Designer Site:

  • Check the Rewrite Headers and Insert X-Forwarded-Host Header check boxes in the Request Settings section.
  • Check the Rewrite Headers and Rewrite Content checkboxes in the Response Settings section.

K2 Runtime Site:

  • Check all the checkboxes within the Request Settings section.
  • Check the Rewrite Headers and Rewrite Content checkboxes in the Response Settings section.

K2 Workspace Site:

  • Check all the checkboxes within the Request settings section.
  • Check the Rewrite Headers and Rewrite Content checkboxes in the Response Settings section.

SharePoint 2010 Site:

  • Check all the checkboxes within the Request Settings section.
  • Check the Rewrite Headers and Rewrite Content checkboxes in the Response Settings section.

SharePoint 2013 Site:

  • Check the Insert X-Forwarded-For Header, Insert X-Forwarded-Proto Header, Insert X-Forwarded-Host Header checkboxes in the Request Settings section.
  • Check the Rewrite Headers and Rewrite Content checkboxes in the Request Settings section.
Rewrite profile setting options may vary depending on the browser being used.

SSL Offloading Setup issue

When setting up SSL offloading with a HTTP to HTTPS redirect,  an error like "Multiple authentication attempts detected" can appear:

Image

To fix this error, add the following iRule to the F5 Load Balancer:

when HTTP_RESPONSE {
   if {  HTTP::is_redirect] } {
      HTTP::header replace "Location" pstring map { http: https: wreply=http% wreply=https% } HTTP::header "Location"] ]
   }
}

 

Limitations

There are two known limitations to be aware of, both have the same two workaround options.


Limitation 1: If an F5 Load Balancer is setup within a distributed environment, F5 and URL rewriting does not work if the SmartForms site (Runtime and Designer) are on a separate machine from the Identity STS site. This is due to NTLM reaching its hop limit to authenticate against the server.

Image

 

Limitation 2: When trying to register the K2 App in a distributed environment, F5 rewrites the URL, the site opens and a timeout occurs when trying to retrieve the autodiscover results as shown:

Image

Workarounds for Limitation 1 & 2:

  • Setup and configure Kerberos within the environment to allow for the extra hop that is introduced by F5.
  • Maintain the K2 Designer and Runtime sites on the same server as the Identity STS site.
     

An example of the correct configuration and authentication

The following steps describe the expected authentication process when the configuration settings are applied correctly.

      1. A user within the external zone attempts to access the K2 Designer site.
      2. The URL is rewritten by the F5 Load balancer and sent to K2, for example: http://int.k2/designer
      3. The K2 Designer then determines that the user has not been authenticated and will redirect to the STS Service for sign in, for example http://int.k2/identity/sts/windows
        1. The request may look as follows: http://int.k2/Idenity/sts/Windows/wsfed?we=signin1.0&wrealm=http:%3a%2f%2intk2%2fDesigner%2f&wctx=rm%3d1%26id%3d%26ru%3d252fDesigner%252f&wct2014-11-06T10%3a14%3a00Z&wreply=http%3a%2f%2fint.k2%2fDesigner%2f
        2. The K2 Designer site then sends an HTTP 302 response indicating to the browser to make a request to the Identity Service.
      4. The reverse proxy rewrites the HTTP 302 response and the client browser knows the HTTP 302 location, for example: https://ext.k2/identity/sts/windows and makes a new request to that location with the same wsfed query string parameters, for example: https://ext.k2/Idenity/sts/Windows/wsfed?we=signin1.0&wrealm=http:%3a%2f%2intk2%2fDesigner%2f&wctx=rm%3d1%26id%3d%26ru%3d252fDesigner%252f&wct2014-11-06T10%3a14%3a00Z&wreply=http%3a%2f%2fint.k2%2fDesigner%2f
      5. The browser sends the request and the reverse proxy rewrites the URL that was requested at step 4. The rewritten URL will be identical to the URL in step 3.a
      6. The Identity Service authenticates the user and attaches the FedAuth cookie (for Claims Based Authentication) to the header of the response.
      7. The HTTP 302 response indicates to the browser to redirect back to the K2 Designer site, for example: http://int.k2/designer
      8. The response is sent and rewritten by the reverse proxy and the 302 location is https://ext.k2/designer
      9. The browser receives the response and prepares a new request to https://ext.k2/designer
      10. The user is authenticated

K2 ViewFlow F5 Configuration

There is a known issue where K2 ViewFlow for legacy processes do not render when used over an F5 reverse proxy environment.

K2 removed support for Silverlight from the K2 ViewFlow component at the release of K2 Five and K2 Cloud. The component is now rewritten using HTML5 technologies. Because of this change, you need to implement extra F5 reverse proxy rules to convert K2 URL values.

Steps to set up the rule

  1. To be able to convert these URL values, you need to allow a Stream Profile on the appropriate virtual server. Select a stream profile from the drop-down list.
    This allows F5 to process iRule's integrating with HTML Streams.
  2. Create the new iRule which does the rewriting on the needed K2 ViewFlow URLs
    These URLs need rewriting (substitute your server values in the URLs shown here):
    • Internal:
      http:{YourK2Web}:{YourK2WebPort}/ViewFlow/
      http:{YourK2Web}:{YourK2WebPort}/ViewFlow/WSViewFlow.asmx
    • External:
      https:{YourK2SSLWeb}:{YourK2SSLWebPort}/ViewFlow/
      https:{YourK2SSLWeb}:{YourK2SSLWebPort}/ViewFlow/WSViewFlow.asmx
  3. Link the new iRule to the virtual server's Resources option:

 

Be the first to reply!

Reply