Forum Discussion

NickChatz_28816's avatar
NickChatz_28816
Icon for Nimbostratus rankNimbostratus
Oct 02, 2017

IRules 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.

 

application delivery
iRules

7 Replies

Sort By
  • NickChatz_28816's avatar
    NickChatz_28816
    Icon for Nimbostratus rankNimbostratus
    Oct 02, 2017

    Did 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.

     

  • VernonWells's avatar
    VernonWells
    Icon for Employee rankEmployee
    Oct 09, 2017

    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 

    [IP::client_addr]
    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.

    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's avatar
      NickChatz_28816
      Icon for Nimbostratus rankNimbostratus
      Oct 09, 2017

      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's avatar
      VernonWells
      Icon for Employee rankEmployee
      Oct 09, 2017

      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.

       

  • Vernon_97235's avatar
    Vernon_97235
    Historic F5 Account
    Oct 09, 2017

    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 

    [IP::client_addr]
    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.

    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's avatar
      NickChatz_28816
      Icon for Nimbostratus rankNimbostratus
      Oct 09, 2017

      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.

       

    • Vernon_97235's avatar
      Vernon_97235
      Historic F5 Account
      Oct 09, 2017

      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.