AccessControl Policy Dynamic

[cleisommais]

Hi, I need to retrieve some IPs(white list) and its mask from App custom attr, and I'd like to use the AccessControl policy to handle the access for those IPs/mask. However, looks like I can't do it dynamic, only if I use the JavaScript. Let me details below what I mean.

When I validate the Appkey f6s46g5a4g6a46g46a I will retrieve the white list from "verifyapikey.{policy_name}.developer.white-list" like "192.30.252.63:22;123.123.208.12:32" {ip:mask;ip:mask}. As you can see, I can retrieve one or many ips and its mask. But, when you look at the AccessControl below, I need add the source address and its mask hard code. I don't have any control how many IPs I can get from the white list. Is there any kind to add the tag <SourceAddress> dynamic?

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="16">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

My idea is add a JavaScript policy to retrieve the white list and inject the source address tags to a new variable, and inside of the AccessControl get those values from the new variable. Is there a best way to do that?

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "ALLOW">      
	  {sourceAddress}
    </MatchRule>
  </IPRules>
</AccessControl>

[strebel · Accepted solution]

You're right in that you can use variables in the AccessControl Policy:

<SourceAddress mask="{cidr.mask}">{cidr.ip}</SourceAddress>

The challenge is that you would have the requirement to use multiple CIDR blocks and that the templating language does not have a for-block construct that would allow you to repeat the "SourceAddress" element.

There's two options you could try both require you to split the custom attribute in your app and build an ip/mask list.

Option A
Perform a CIDR mask calculation in js similar to this answer: https://www.googlecloudcommunity.com/gc/Apigee/IP-whitelisting-using-a-list-at-run-time/m-p/43923/hi.... As this is a critical security component make sure you include sufficient unit test coverage to validate the correctness and prevent regression.

Option B
You define a maximum number of Source Address CIDRs your AccessControl supports and create a policy that includes a list of SourceAddress objects:

<SourceAddress mask="{cidr1.mask}">{cidr1.ip}</SourceAddress>
<SourceAddress mask="{cidr2.mask}">{cidr2.ip}</SourceAddress>
<SourceAddress mask="{cidr3.mask}">{cidr3.ip}</SourceAddress>
<SourceAddress mask="{cidr4.mask}">{cidr4.ip}</SourceAddress>
<SourceAddress mask="{cidr5.mask}">{cidr5.ip}</SourceAddress>

Where you backfill the unused CIDR blocks with a trusted IP e.g. 127.0.0.1/32. 

[cleisommais]

Hi thanks for the fast reply. For sure the first approach is better, the second one is a little ugly in my point of view. Thanks man.