I took training from F5 on the APM (Access Policy Manager) product earlier this year. One of the things that really impressed me after finishing the training was how flexible the APM is in terms of the solutions that you can build with it.

The policy editor is what makes the APM is so powerful in my view. With it, you essentially build a flow-chart that combines various:

• authentication mechanisms (form based, NTLM, client certs, Kerberos, etc)
• auth backends (LDAP, Kerberos, SSL CA’s, OTP, AD, etc)
• resources (sites, applications, VPN tunnels, etc)
• access mechanisms (client based VPN, web based VPN, portals, etc).

It can also embed some simple logic - for example, if the user is coming from Windows, then give them access to the native RDP application, otherwise use a Java based RDP reverse proxy.  With the policy editor, the APM isn’t so much a VPN endpoint, or reverse proxy, as it is a foundation that you can use to build a custom remote access / VPN / reverse proxy / etc. It’s pretty cool.

This also makes it a little more complex to get started with if you’re not familiar with it, and expect to be able to fire it up and have a VPN endpoint. There are wizards build in that make that kind of usage pretty painless. But it’s a blank slate out of the box.

I wanted to document some of the different use cases I can see for F5 APM. I think there’s definitely a wide variety of roles that the APM can play in many organizations.

Full tunnel VPN

The connection can be initiated either through a web browser, or the BIG-IP Edge Client installed on the device (it’s supported on pretty much anything, including Mac, iOS, Linux, and Android).

Once the user connects, it also can control what access the user has via ACL’s and lock down the client to prevent split tunneling. For this use case, I just have the access profile applied on a VIP that hosts the VPN service itself (no pool is configured).

Here’s what the Mac client looks like, and what it looks like when you connect via the web:

Webtop Based Reverse Proxy / VPN

APM has a concept called a webtop, which is a web based portal that contains links to the different resources that APM is providing access to. The resources in my screenshot below are for a web based reverse proxy, Java based RDP access, and a full VPN tunnel.

Here’s what the policy looks like for the webtop example:

In this policy, I’m getting the user’s credentials via a web form and then authenticating them with RADIUS. Depending on what operating system they are running, I present them with different resources, and I also enable single-sign-on for internal web applications that use HTTP Basic auth.

Reverse Proxy

The APM can also work as a reverse proxy, allowing users to get to multiple internal web applications through a single externally facing LB VIP.  The APM can use any of its auth mechanisms to authenticate the user and then reverse proxy them to internal web applications.  It takes care of modifying links and embedded URL’s to make them work through the reverse proxy.

This option still uses an APM specific VIP that has no pool assigned to it.  It relies on a “portal” resource within the APM to reverse proxy the traffic.  It is relatively similar to the last couple use cases that I listed below, but goes about it in a different way, by using the reverse proxy functionality instead of adding APM onto an existing LB VIP.

Single Sign On, Auth Transformation

In this use case, I’m authenticating the user on the front end with a web form, and presenting those credentials to the web application via HTTP basic auth. There are a wide range of auth mechanisms that can be used on the front end / back end - forms, HTTP basic, NTLM, Kerberos, SAML, and client SSL certificates. This can let you use new auth mechanisms with legacy applications without having to modify the application itself.

Here, the access profile is applied to the normal LB VIP that front-ends the application. The pool configured for the VIP just sends traffic to the actual servers hosting the application. In this situation, we don’t really use the “resource” concept on the APM.

In the specific example I posted the screenshot of, the APM doesn’t actually authenticate the user. It just accepts the users credentials via a web form and sends them to the application via HTTP. If the auth fails, it will fail at the application. Of course, you could authenticate the user on the APM itself, to give you more flexibility in how the failure is handled.

Adding Auth Capabilities to Existing Site

If you have an existing website that you want to bolt authentication on to, you can do that with the APM too. I’m not using resources on the APM in this case either. I just have the access profile applied to the LB VIP for the application. I accept the users credentials via a web form, authenticate them, and assuming they authenticated correctly, pass their traffic on to the servers hosting the application.

Obviously, in this kind of use case, you would have to prevent the user from directly accessing the server(s) sitting behind the load balancer. (Since the authentication only occurs on the APM, a user could access the web server directly without authentication, if they can reach it.)

My goal in this post wasn’t to give a detailed rundown on everything that APM can do, but just to demonstrate the range of solutions that can be built with APM.  I think its a pretty useful tool.  We’ve used it in a very limited use case (auth transformation to support mobile devices) at the client site I’m working at, but it has a significantly wider range of capabilities than we have made use of so far.