NimbostratusThis sounds non-trivial, so you may wish to consider engaging F5 Professional Services.
Having said that, a bit more information may be helpful. On what type of messages are you operating? What do you mean by "restricts operations"? It is simple for the BIG-IP to extract the IP address of a client, and to bind the client IP to a specific decision. The first is achieved generically via
[IP::client_addr]Let's say that you want to choose a destination pool for load-balancing based on client IP:
when CLIENT_ACCEPTED {
set lb_pool [class lookup [IP::client_addr] dg-lb-decision]
if { $lb_pool ne "" } {
pool $lb_pool
}
}
The datagroup (called "dg-lb-decision") would use IP addresses (and/or netblocks) as the key, and the name of a pool as the value. If the client IP is a key, or in one of the netblocks, the associated pool will be used. Otherwise, the default pool assigned to the Virtual Server is used.
I understand this may not be your exact use-case, but extracting the client IP and the use of a data-group would be similar.
NimbostratusHi Vernon , thanks for the reply. Well the thing is like that:
XML inspection of SOAP messages. Consider 5 users and all of them have READ/WRITE access/role. i Want the 3 of them to continue have access but limiting their access/permissions in only read.
It appears from that example that you wish to change the EndUserRole element in the SOAP message. To do that efficiently, your best bet is to use the Stream Profile. There are numerous example on DevCentral that should assist you in using a Stream Profile. The iRule I provided above is still relevant. In that case, the data group would map IPs and netblocks to a permission value.