BigIP: IP Address Restrictions for WebSEAL

Switching your front-end load-balancer to a BigIP LTM to load-balance your WebSEAL servers breaks IP Address Authentication in WebSEAL. This is because the BigIP LTM acts as a reverse proxy, so your WebSEAL servers never see the IP Address of your end-user—only your BigIP's IP Address is seen by WebSEAL. If you are utilizing IP Address Authentication, the following irule could be used as a template to get you started.

Assumptions

• This example uses two WebSEAL junctions named /customerA-jct and /customerB-jct respectively.

• The Datagroup containing the Allowable IP addresses for Customer A is called "customerA_IPs" and the datagroup containing allowable IP addresses for Customer B is called "customerB_IPs".

• In the fine example used by 24, NCIS, MI-5, The Border and similar shows with nerds in the cast who often save the day, the "host" IP Addresses used in the datagroups in this template are completely invalid by-design. If your customer comes from multiple IP addresses, you can add a 'host' entry here for each IP.

• The 'network' addresses in this example represent your company's internal IP addresses, so this could be completely different.

• Even though the classes (datagroups) are being displayed in the iRule, I believe it is a best practice to not include the classes in the actual iRule but through the GUI, the iRule Editor, or using the bigpipe classes command line utility.

• Finally, although the BigIP is now going to be handling your IP Address restrictions, this rule assumes that WebSEAL will still manage the junction destinations. In other words, once the IP has been validated, BigIP will pass the request along to the junction and WebSEAL will take care of rewriting the URL and forwarding the request up to the upstream app servers.

iRule Template

# section 1: datagroups
class customerA_IPs {
 network 10.0.0.0/24
 host 512.434.356.278
}

class customerB_IPs {
 network 10.0.0.0/24
 host 912.834.756.678
}

# section 2: set default load-balanced pool
when CLIENT_ACCEPTED {
 set myPool [LB::server pool]
}

# section 3: http request handling 
when HTTP_REQUEST {
 switch -glob [HTTP::uri] { 
 "/customerA-jct*" { 
  if { not [matchclass [IP::client_addr] equals $::customerA_IPs] } { 
  HTTP::respond 403 content "403 - Forbidden"
  }
 }
 "/customerB-jct*" { 
  if { not [matchclass [IP::client_addr] equals $::customerB_IPs] } { 
  HTTP::respond 403 content "403 - Forbidden"
  }
 }
 default { 
  pool $myPool
  
 }
 }
}

Template Explained

The classes expressed in section 1 in the iRule are there for illustrative purposes only. You should create two datagroups, (which is what they are also known as) in the BigIP Admin GUI or using the iRule Editor.

[LB::server pool] represents the pool of servers that are presently assigned to the virtual IP. Section 2 simply sets a name to that pool.

Section 3 performs a regular expression match against the junction names. It should be read as, "when an http request is received let the request through unless the URI contains the name of one of your customer specific junctions and the client IP address is not in the allowable IP list. If a junction name is matched but the IP address is not in the allowable IP list, issue an HTTP 403 status code."

If you add more junctions but these junctions do not contain IP address restrictions, you don't need to do anything to this irule. However, if you add another restricted junction, you must create a new datagroup and then you can copy and paste the 5 lines of irule code starting at the quoted junction name and ending at the second curly brace prior to the default section. Rename the URI and the class name and you're good to go.


Deployment Guide Series: IBM Tivoli Access Manager for E-business 6.0