F5 SSLO Unified Configuration API Quick Introduction

Introduction

Prior to the introduction of BIG-IQ 8.0, you had to use the BIG-IQ graphical user interface (GUI) to configure F5 SSL Orchestrator (SSLO) Topologies and their dependencies.

Starting with BIG-IQ 8.0, a new REST unified, supported and documented REST API endpoint was created to simplify SSLO configuration workflows.  

The aim is to simplify the configuration of F5 SSLO using standardized API calls. You are now able to store the configuration in your versioning tool (Git, SVN, etc.), and easily integrate the configuration of F5 SSLO in your automation and pipeline tools. 

 

For more information about F5 SSLO, please refer to this introductory video. An overview of F5 SSL Orchestrator is provided in K1174564.

As a reminder the BIG-IQ API reference documentation can be found here. Documentation for the Access Simplified Workflow can be found here.

 

The figure below shows a possible use for the SSLO Unified API.

 

A few shortcuts are taken in the figure above as it is meant to illustrate the advantage of the simplified workflow.

 

Example Configuration

For the configuration the administrator needs to:

-Create a JSON blurb or payload that will be sent to the BIG-IQ API

-Authenticate to the BIG-IQ API

-Send the payload to the BIG-IQ

-Ensure that the workflow completes successfully

 

The following aims to provide a step-by-step configuration of SSLO leveraging the API. In practice, the steps may be automated and may be included in the pipeline used to deploy the application leveraging the enterprise tooling and processes in place.

 

1.- Authenticate to the API

API interactions with the BIG-IQ API requires the use of a token. The initial REST call should look like the following:

REST Endpoint : /mgmt/shared/authn/login

HTTP Method: POST

Headers:

-content-type: application/json

Content:

{
 "username": "",
 "password": "",
 "loginProviderName": ""
}

Example:

POST https://10.0.0.1/mgmt/shared/authn/login HTTP/1.1
Headers:
content-type: application/json
Content:
{
 "username": "username",
 "password": "complicatedPassword!",
 "loginProviderName": "RadiusServer"
}

The call above will authenticate the user “bob” to the API. The result of a successful authentication is the response from the BIG-IQ API with a token.

 

2.- Push the configuration to BIG-IQ

The headers and HTTP request should look like the following:

URI: mgmt/cm/sslo/api/topology

HTTP Method: POST

Headers:

-content-type: application/json

-X-F5-Auth-Token: [token obtained from the authentication process above]

 

To send the configuration to the BIG-IQ you will need to send the following payload - the blurb is cut up in smaller pieces for readability. The JSON blurb is divided in multiple parts - the full concatenated text is available in the file in attachment.

 

Start by defining an new topology with the following characteristics:

• Name: "sslo_NewTopology"
• Listening on the "/Common/VLAN_TRAP" VLAN
• The topology is of type "topology_l3_outbound"
• The SSL settings defined below named: "ssloT_NewSsl_Dec"
• The policy is called: "ssloP_NewPolicy_Dec"

The JSON payload starts with the following:

{
  "template": {
    "TOPOLOGY": {
      "name": "sslo_NewTopology ",
      "ingressNetwork": {
        "vlans": [
          {
            "name": "/Common/VLAN_TAP"
          }
        ]
      },
      "type": "topology_l3_outbound",
      "sslSetting": "ssloT_NewSsl_Dec",
      "securityPolicy": "ssloP_NewPolicy_Dec"
    },

 

The SSL settings used above are defined in the following JSON that creates a new profile with default values:

    "SSL_SETTINGS": {
      "name": "ssloT_NewSsl_Dec"
    },

 

The security policy is configured as follows:

• name: ssloP_NewPolicy_Dec
• function: introduces a pinning policy doing a policy lookup - matching requests are bypassed (no ssl decryp) with the associated service chain "ssloSC_NewServiceChain_Dec" that is defined further down below.

    "SECURITY_POLICY": {
      "name": "ssloP_NewPolicy_Dec",
      "rules": [
        {
          "mode": "edit",
          "name": "Pinners_Rule",
          "action": "allow",
          "operation": "AND",
          "conditions": [
            {
              "type": "SNI Category Lookup",
              "options": {
                "category": [
                  "Pinners"
                ]
              }
            },
            {
              "type": "SSL Check",
              "options": {
                "ssl": true
              }
            }
          ],
          "actionOptions": {
            "ssl": "bypass",
            "serviceChain": "ssloSC_NewServiceChain_Dec"
          }
        },
        {
          "mode": "edit",
          "name": "All Traffic",
          "action": "allow",
          "isDefault": true,
          "operation": "AND",
          "actionOptions": {
            "ssl": "intercept"
          }
        }
      ]
    },

The service chain configuration is defined below to forward the traffic to the "ssloS_ICAP_Dec" service. this is done with the following JSON:

    "SERVICE_CHAIN": {
      "ssloSC_NewServiceChain_Declarative": {
        "name": "ssloSC_NewServiceChain_Dec",
        "orderedServiceList": [
          {
            "name":"ssloS_ICAP_Dec"
          }
        ]
      }
    },

The "ssloS_ICAP_Dec" service is defined with the JSON below with IP 3.3.3.3 on port 1344

    "SERVICE": {
      "ssloS_ICAP_Declarative": {
        "name": "ssloS_ICAP_Dec",
        "customService": {
          "name": "ssloS_ICAP_Dec",
          "serviceType": "icap",
          "loadBalancing": {
            "devices": [
              {
                "ip": "3.3.3.3",
                "port": "1344"
              }
            ]
          }
        }
      }
    }
  },

The configuration will be deployed to the target defined below:

  "targetList": [
    {
      "type": "DEVICE",
      "name": "my.bigip.internal"
    }
  ]
}

After the HTTP POST, the BIG-IQ will respond with a transaction id. A sample of what looks like is given below:

{
[…]
"id":"edc17b06-8d97-47e1-9a78-3d47d2db70a6",
"status":"STARTED",
[…]
}

 

You can check on the status of the deployment task by submitting a request as follows:

-HTTP GET Method

-Authenticated with the use of the custom authentication header X-F5-Auth-Token

-Sent to the BIG-IQ to URI GET mgmt/cm/sslo/tasks/api/{{status_id}} HTTP/1.1

-With Content-Type header set to: Application/JSON

 

Once the status of the task changes to FINISHED. The configuration is successfully completed. You can now check the F5 SSLO interface to make sure the new topology has been created. The BIG-IQ interface will show the new topology as depicted in the example below:

The new topology has been deployed to the BIG-IP automatically. You can connect to the BIG-IP to verify, the interface should like the one depicted below:

 

Congratulations, you now have successfully deployed a fully functional topology that your users can start using.

 

Note that, you can also use the BIG-IQ REST API to delete the items that were just created. This is done by sending HTTP DELETE to the different API endpoints for the topology, service, security profile etc.

 

For example, for the example above, you would be sending HTTP DELETE requests to the following URI’s:

-      For the topology: /mgmt/cm/sslo/api/topology/sslo_NewTopology_Dec

-      For the service chain: /mgmt/cm/sslo/api/service-chain/ssloSC_NewServiceChain_Dec

-      For the ICAP service: /mgmt/cm/sslo/api/ssl/ssloT_NewSsl_Dec

 

All the requests listed above need to be sent to the BIG-IQ system to its management IP address with the following 2 headers:

-      content-type: application/json

-      X-F5-Auth-Token: [value of the authentication token obtained during authentication]

 

Conclusion

BIG-IQ makes it easier to manage SSLO Topologies thanks to its REST API. You can now make supported, standardized API calls to the BIG-IQ to create and modify topologies and deploy the changes directly to BIG-IP.