It sounds like he says that the boolean condition can be on either the Deny, or the Allow with the test flipped. That’s not true, is it? That would give an explicit Deny, which would outweigh the Allow, regardless of whether HTTPS is used or not. No?
He’s suggesting two different options. The second one that Ryan mentions is the easer to write as a permission statement:
Condition: You are doing it correctly (ie using HTTPS)
In that example if someone accesses the API with the right conditions, then the remainder of the permission statement is put into play – they are allowed whatever access to whatever resources. But what if they weren’t using HTTPS? In that case, the condition would not be true, and the entire permission statement would be ignored – NOT INVERTED. I’ve run into several students who look at that situation and believe that the Allow becomes a Deny if the condition is not true, which is not the case. The effect of a permission statement that contains a condition is only applied if that condition is true and is not applied if the condition is false.
With that single statement, we are not proactively ensuring that the principal attempting the action cannot be given access from some other permission policy or statement, which to me is not a best practice. That’s why Ryan led off with the example that he did, referencing a Deny effect in combination with a condition that is checking for non-HTTPS transport. That policy would consist of a combination of permission statements, similar to the following:
Condition: You’re doing it wrong (ie Not HTTPS)
This is a better practice because it is more restrictive. We start by allowing everything with no conditions. The second statement, however, will apply the explicit deny if the accompanying condition is true. Since that condition is checking to see if they aren’t following the rules, that will deny access to anyone following the rules no matter how many other allows might be in effect, as an explicit Deny always overrides any other source of allow.