We’ve seen an increasing number of F5 customers who use (and love) APM asking for greater integration with their favorite Mobile Device Management systems, and now the first integration is here. We’re proud to launch this iApp to the DevCentral community, not only as a potentially useful tool in your APM bag of tricks, but also as an example of the ease with which you can use iApps and iRules to add virtually any type of functionality you can dream up to Access Policy Manager!
In the past, some of you have taken data from your MDM systems and imported it into data groups on your BIG-IP. This solution does still work, but you lose much of the real-time status of which modern MDM systems like MobileIron rely upon to keep their managed devices continually assessed for compliance to enterprise security policy. To truly ensure that we’re not admitting devices to the network that don’t comply (or, even worse, devices that aren’t even under our MDM’s management), we need our checks to be done as near real-time as possible.
Luckily, this is BIG-IP – the land of possibilities. And we have iRules and sideband connections!
Figure 1 – MobileIron integration in a nutshell (or a sideband, really).
MobileIron has an Application Programming Interface (API) that allows us to query for information about a connecting device and learn what the MobileIron VSP knows about it. Edge Client has the ability to inform APM of the connecting device’s MAC address – so we’ll connect the dots through a sideband connection and make the data from MobileIron’s API available for your access policy. First, a list of requirements:
- You’ll need to be running MobileIron VSP 5.5 or later, or be using the MobileIron Cloud VSP service. Earlier versions of VSP don’t support the API calls we’ll be doing.
- If you’re running a firewall between your BIG-IP and your MobileIron VSP or MobileIron Cloud instance, you should ensure that the BIG-IP can communicate to the VSP on port 443 through the firewall.
- Because we’re going to connect outward from the BIG-IP to a host, we’re going to use DNS to resolve the hostname every so often so we don’t have to reconfigure anything should you move your VSP. Because of this, the BIG-IP will need to be able to communicate to a resolver that knows the VSP’s hostname.
- It should go without saying, but you need to be licensed for APM at your BIG-IP.
- You need to create a user at your MobileIron VSP that has API rights. Consult your MobileIron documentation regarding how to accomplish this.
- Your BIG-IP needs a route defined to follow to reach the MobileIron VSP. Make sure your BIG-IP’s routing table has an entry that allows for this.
Got it? Firewall rules ready? Resolver identified? Versions verified? Great! Let’s get started.
Step 1: Use the iApp
Figure 2 – The MobileIron/APM iApp template (hosted Cloud mode)
Start by downloading the latest version of the iApp from here:
Once you have the iApp template installed, create a new application and select the template from the list. You will see a screen like the one in Figure 2. The iApp will assist you in creating both the sideband iRule we will use to send and receive information from MobileIron, and a “helper” virtual server that will be used to apply SSL encryption to the API queries we’ll be making from that iRule.
First, you’ll need to define what type of MobileIron infrastructure you’ll be using. There are two types: Standalone and Hosted. If you’re using the MobileIron Cloud VSP, select Hosted, otherwise your configuration will be using the Standalone type. If you select Hosted, you will choose your VSP hostname from the dropdown list; in Standalone mode, you’ll enter the hostname manually. If you selected Hosted, you will need to enter your MobileIron Cloud “Enterprise Name”. Your Enterprise Name is found in your MobileIron cloud container under Settings -> Preferences -> Enterprise Preferences. You must enter it exactly as it appears.
Next, you’ll need to enter the username and password for the API account you created to support this sideband connectivity. This will complete the setup related to MobileIron VSP.
We now need to collect information to allow us to configure the sideband helper. By default, the iApp will attempt to automatically assign an IP address for the sideband helper VS. It will choose a random IP address in the 192.168/16 range, but it won’t assign anything that it finds to be in use or visible on the network on any VLAN. In addition, it will remove this Virtual Server from all VLANs by default so that it cannot be used outside of the BIG-IP itself – this is okay because we’re only using it to handle self-initiated sideband connections OUTBOUND, so we don’t really want it to accept any inbound connections. If you’re uncomfortable letting the iApp pick an address, that’s no problem – just select “No” and configure your own.
As previously mentioned, we need a DNS resolver in order to query for the MobileIron VSP’s hostname. In a scenario where the VSP is internally hosted, you may want to configure an internal resolver in order to get an internal network address – that’s why this is a configurable option. Enter a single IP in the field provided (we’re not going to query for it very often, so a single server should be sufficient).
Finally, by default the BIG-IP will use a SNAT Automap address to initiate connections out to VSP (for those not aware, this will be one of the Self IP addresses on the interface that the BIG-IP follows to route the traffic to the destination). If for some reason you want to manually assign this address, you can select “No” and enter your own.
Once you’ve entered everything, all of the necessary components will be automatically created as shown in Figure 3. This includes the helper virtual (e.g., “customer1_mobileiron_cloud_sideband_80”), the actual APM event iRule (“mobileiron_apm_support”), and all supporting profiles. Now you’re ready to enable your existing APM virtual servers to understand how to talk to MobileIron.
Step 2: Enable MobileIron for your APM Virtual Server
This is the easiest step to perform. For any APM virtual server that you want to be able to make outbound calls to MobileIron, you’ll need to enable the iRule we created via the iApp on it. To find it, look for the iRules created in the folder named the same as the name you gave the application, and select the one ending in “apm_support” (Figure 4). This will enable you to use certain iRule Agent Events in your access policy.
Don’t worry too much about applying the iRule before you’ve had a chance to work on your access policy! Because it contains nothing but ACCESS_POLICY_AGENT_EVENTs, it won’t be activated unless you tell it to do so in your access policy. Which brings us to…
Step 3: Construct/Modify an Access Policy to Use MobileIron
Now that you’ve attached the iRule, we need to create some access policy hooks to take advantage of our new API access. This is done by creating iRule Agent Events in your VPE. At the moment, there are four main actions you can perform (more will be added in future releases):
| iRule Event | What It Does |
| mi_device_collect |
Wake up the MobileIron engine on the connecting device and prompt it to execute an inventory. Wake up success can be checked by examining the variables inside the “session.mobileiron.wakeup.*” tree. |
| mi_send_message |
Send a PNS message via the MobileIron infrastructure using the content set in the APM custom session variable "session.mobileiron.message.content". Message success can be checked by variables stored inside the “session.mobileiron.message.*” tree. |
| mi_device_details |
Retrieve all known device-level info previously collected by MobileIron VSP. This is the main information-gathering routine and will likely be the only one you need to call to check compliance status. The details will be stored inside “session.mobileiron.device.*” |
| mi_device_inventory |
Collect information about all apps loaded on the connecting device. This will return a full list of all applications on the device inside “session.mobileiron.inventory.*” WARNING: The retrieved application inventory can be quite sizable and should NOT be pulled unless policy evaluation at APM absolutely requires it for a VPE decision. |
These events will execute the sideband API call, and, if successful, will return an entire tree full of session variables for you to use in later VPE policy. Figure 5 demonstrates how to call the MobileIron check and verify the response:
Figure 5 – Calling the MobileIron connector from your access policy and verifying the return
In this example, we have a macro that executes the “mi_device_details” event in the iRule. This takes the “session.client.mac_address” value that Edge Client provides and queries MobileIron VSP for the information related to the device that’s registered with that MAC address. If the device is found, MobileIron will send back a list of all the device-level information that it has.
In Figure 5, you’ll also see an example of how we use the variables that return to us from MobileIron. We can easily check device compliance status by creating an “Empty” VPE action and using advanced TCL to see if the “session.mobileiron.device.compliance” score is equal to zero – that means the device is compliant. Any device fitting that description will then follow the “Compliant” macro branch. But that is, by no means, the only thing we can do.
Figure 6 – Data imported into APM directly from MobileIron appears as a session variable tree
What sort of data is available to us? Well, pretty much anything that MobileIron has collected. Here’s a small sampling:
- session.mobileiron.device.compliance: The device’s current compliance level (a fully compliant device will show zero (0))
- session.mobileiron.device.battery_life: The device’s last known battery level
- session.mobileiron.device.principal: The username of the user to whom the device is registered within MobileIron
- session.mobileiron.device.details.passcodepresent: A flag to indicate whether the user has set a passcode on the device
Cellular data type? Yes! Carrier? Yes! Remaining storage space? Yes! GPS Location? YES! And many more! You can see a few more in Figure 6, and the full list (and the values they can represent to you) are available to you directly from MobileIron.
That’s the end of Part 1.
In Part 2, we’ll look at some individual use cases and the policy you can construct with your new MobileIron VSP connector. Just to whet your appetite:
- Blocking attempts to log into the VPN if the username doesn’t match the user who initially registered the device with MobileIron.
- Warning users whose “home” carriers are different than the carrier we currently see them on that they may be subject to roaming charges while connected via VPN.
