2.6. Creating an Existing Application Topology

2.6.1. What it is

The layer 3 SSL Orchestrator topology workflows build an application set that includes Interception Rules (i.e. virtual servers), SSL Settings (client and server SSL profiles), and Egress Settings (routing or load balancing). However, it may also be useful to simply integrate dynamic service chaining of decrypted traffic to services with existing LTM application virtual servers. In this case, an F5 BIG-IP LTM with configured applications can consume an SSL Orchestrator security policy, while handling their own SSL settings and traffic management. An Existing Application topology is a shortcut workflow for building just the services, service chains and a security policy. Once complete, the security policy is consumed by an LTM virtual server.

2.6.2. How to build it

The Existing Application topology is designed as a shortcut workflow to build services, service chains and a security policy.

Topology Properties	User Input
The Topology Properties page provides 5 selections
Topology name	Enter a unique name here.
Description	Optionally enter a description here.
IP Family	Select between IPv4 and IPv6.
SSL Orchestrator Topologies	Select the Existing Application topology here.

Click Save & Next to proceed.

Services List	User Input
For simplicity of this initial topology configuration, security services are defined in the Services chapter of this deployment guide. Please navigate to this chapter for complete information on configuration of services within SSL Orchestrator.

Click Save & Next to proceed.

Service Chain List	User Input
If Services have been created per the previous step, create service chains to contain the services for use by security service policies. Click the Add button.
Name	Provide a name for the service chain.
Description	Optionally provide a description.
Services	Move any available services over to the “Selected Service Chain Order” box, and re-order as required.
Click the Save button to proceed. Repeat this process for any additional service chains.

Click Save & Next to proceed.

Security Policy	User Input
The Security Policy defines the set of traffic matching rules and corresponding actions to take on matches. The built-in security policy contains one rule: All Traffic - the default catch-all rule for any traffic that does not match other rules. By default, this rule allows and intercepts (decrypts) traffic but does not preselect any service chain. To create additional rules, click the Add button.
Name	Provide a name for this rule.
Conditions	Select a condition that matches your traffic requirement.
Action	Select to either Allow or Reject traffic for this traffic condition.
SSL Proxy Action	Select to either Intercept (decrypt) or Bypass (not decrypt) TLS traffic for this condition.
Service Chain	Select a service chain to process traffic for this condition.
Click the OK button. Repeat this process for any additional rules.

Click Save & Next to proceed.

Summary	User Input
The Summary page displays all of the previously defined settings and provides re-entry to each setting to make modifications before deploying.

If all is correct, click Deploy to build this transparent forward proxy SSL Orchestrator topology.

Attaching to Virtual Server	User Input
Once complete, the Existing Application topology will have created a security policy that can be directly consumed by an LTM virtual server. Within an LTM virtual server configuration (Local Traffic -> Virtual Servers), find the Access Policy section.
Access Profile	Select the “ssloDefault_accessProfile”.
Per-Request Policy	Select the previously created Existing Application security policy.

Click Finished to update the LTM virtual server configuration.

2.6.3. How it works

SSL Orchestrator defines an existing application as a typical reverse proxy LTM virtual server, performing its own SSL handling (SSL profiles) and traffic management (assigned pool). The Existing Application SSLO topology therefore only needs to create the components that this virtual server can consume, specifically the services, service chains, and security policy. The Existing Application SSLO workflow skips SSL management, interception rules and egress settings, and ultimately produces an SSLO-type per-request policy that can be attached to an existing LTM virtual server.

• Topology Properties

  The Existing Application Topology is protocol agnostic, so only specifies an IP family selection of either IPv4 or IPv6.

  
  

• Services

  The Services List page is used to define security services that attach to SSL Orchestrator. The Guided Configuration includes a services catalog that contains common product integrations. Each icon represents a security product integration deployed as one of the five basic service types. The service catalog also provides “generic” security services if your security service is not included in the catalog. Depending on screen resolution, it may be necessary to scroll down to see additional services.

  
  

  

  Figure 26: SSL Orchestrator service catalog

  
  

  For simplicity of this initial topology configuration, security services are defined in the Services chapter. Please navigate to this chapter for complete information on configuration of the various services.

  
  

• Service Chain List

  Service Chains are ordered lists of security devices. Based on environmental requirements, different service chains may contain different re-used sets of services, and different types of traffic can be assigned to different service chains.

  
  

  

  Figure 27: SSL Orchestrator logical security policy and service chaining

  
  

• Security Policy

  Security Policies are the set of rules that govern how traffic is processed in SSL Orchestrator, and the actions a rule can take include,

  • Whether or not to allow the traffic (Allow or Reject)

  • Whether or not to decrypt the traffic (Intercept or Bypass)

  • Which service chain (if any) to pass the traffic through

  
  

  The Guided Configuration presents an intuitive rule-based, drag-and-drop user interface for the definition of security policies. Note that the default “All Traffic” rule allows and intercepts (decrypts) traffic but does not assign a service chain. To be effective, it is advisable to assign a service chain here.

  

  Figure 28: SSL Orchestrator basic security policy

  In the background, SSL Orchestrator maintains these security policies as visual per-request policies. If traffic processing is required that exceeds the capabilities of the rule-based user interface, the underlying per-request policy can be managed directly.

  
  

  Note

  Once the per-request policy is manipulated, the rules-based user interface can no longer be used.

  
  

• Summary

  The Summary page presents an expandable list of all of the workflow-configured objects. To expand the details for any given setting, click the corresponding arrow icon on the far right. To edit any given setting, click the corresponding pencil icon. Clicking the pencil icon will send the workflow back to the selected settings page.

  Upon successfully deploying the configuration, SSL Orchestrator will now display a Configure view.

  
  

  

  Figure 29: Guided Configuration landing page

  
  

  The Existing Application topology does not create Interception Rules.

• Attaching to an LTM virtual server

  The Existing Application topology will have created a security policy that can be directly consumed by an LTM virtual server. This manifests as an Access per-request policy. The Access per-session policy is static, un-editable and created by default. Both of these policies are of type “SSL Orchestrator”. This type of policy is “session-less” and does not require Access Policy Manager (APM) to be licensed and provisioned.

  
  

  • Access Profile - select the “ssloDefault_accessProfile”.

    
    

  • Per-Request Policy - select the previously-created Existing Application security policy.

  
  

  

  Figure 30: Attaching an Existing Application topology to a virtual server