Forum Discussion
NickChatz_28816
Nimbostratus
NimbostratusIRules for read-only help
The filtering will be done at load balancer level which will dispatch messages coming from the 2-3 different IPs according to their sender’s access rights. When receiving a message, the Load balancer will open the packet, check its IP address -- the first 1000 bits, to identify the sender of the message. If the message is sent by a Valid/Other approved IP with full access to the system, it will be assigned “user profile 1” and the message will be transmitted to the servers/application without applying any other limitations than the pre-existing access rights. If the message is sent by one of the 2-3 three IPs with read-only access , the message will be assigned “user profile 2”, which restricts operations such as entering, amending and deleting data. This is the concept. Not experienced at all with IRules so i am appreciating all the help i can get.
NickChatz_28816Did some research and maybe this can also be achieved via packet inspection (XML). So the idea is to basically inspect the packet and if for example a certain IP wants to access a specific url with read/write access to block the (write) part.
VernonWellsEmployee
This 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
and is available in nearly all events. A data group is usually the best way to map IP addresses to some sort of policy choice.[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.
- NickChatz_28816
Hi 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.
- VernonWells
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.
This 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
and is available in nearly all events. A data group is usually the best way to map IP addresses to some sort of policy choice.[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.
- NickChatz_28816
Hi 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.
