Installation
The HUMAN Security Apigee Edge Enforcer installation process has three steps:
- Uploading the HUMAN Enforcer Shared Flow Bundles from zip files.
- Configuring the HUMAN Enforcer by adding the desired configuration in the
JS-ConfigureAndInitialize.xml
file inside thepreflow-enforce
Shared Flow Bundle. - Invoking the HUMAN Shared Flows by defining and invoking FlowCallout policies within your custom API Proxy or Shared Flow.
Upload the HUMAN Enforcer Shared Flow Bundles
- The HUMAN Enforcer consists of three shared flow bundles. The HUMAN team will provide you with these Shared Flow Bundles as zip files.
- preflow-enforce.zip
- postflow-enforce.zip
- postclientflow-enforce.zip
- Click on the left menu in the Apigee main page screen > Proxy development > Shared Flows.
- Click on Upload Bundle.
- Upload the three provided zip files one at a time.
Configure the HUMAN Enforcer
The HUMAN Enforcer must be configured with a minimum of an application ID, authentication token, and cookie secret. The configuration can be found in the preflow-enforce
Shared Flow Bundle, inside the JS-ConfigureAndInitialize.xml
policy.
All configurations (other than custom functions) should be added as properties to this policy.
Integrate the HUMAN Enforcer
The HUMAN Enforcer Shared Flow Bundles uploaded in the previous section can now be invoked via the FlowCallout policy in any API Proxy or even in another Shared Flow. Follow the steps below to integrate the HUMAN enforcer using FlowCallout policies.
- Select the the API Proxy or Shared Flow you would like to add the HUMAN enforcer to and click on the Develop tab.
- Click on the plus sign (+) next to the Policies folder to add a new policy. Select Flow Callout as the policy type. Name the policy
FC-PreflowEnforce
, select thepreflow-enforce
shared flow from the drop down, and click Create.
- Repeat the previous step for the
postflow-enforce
andpostclientflow-enforce
shared flows. The policies should be namedFC-PostflowEnforce
andFC-PostclientflowEnforce
. - Verify that the XML files for the three new Flow Callout policies created in Steps 2-3 look like this:
FC-PreflowEnforce.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<FlowCallout async="false" continueOnError="false" enabled="true" name="FC-PreflowEnforce">
<DisplayName>FC-PreflowEnforce</DisplayName>
<FaultRules/>
<Properties/>
<SharedFlowBundle>preflow-enforce</SharedFlowBundle>
</FlowCallout>
FC-PostflowEnforce.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<FlowCallout async="false" continueOnError="false" enabled="true" name="FC-PostflowEnforce">
<DisplayName>FC-PostflowEnforce</DisplayName>
<FaultRules/>
<Properties/>
<SharedFlowBundle>postflow-enforce</SharedFlowBundle>
</FlowCallout>
FC-PostclientflowEnforce.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<FlowCallout async="false" continueOnError="false" enabled="true" name="FC-PostclientflowEnforce">
<DisplayName>FC-PostclientflowEnforce</DisplayName>
<FaultRules/>
<Properties/>
<SharedFlowBundle>postclientflow-enforce</SharedFlowBundle>
</FlowCallout>
- Click on the Proxy endpoints folder. Click on the plus (+) sign next to the Request PreFlow section to add a policy step. Select the existing
FC-PreflowEnforce
policy and click Add.
- Repeat the previous step for the
FC-PostflowEnforce
andFC-PostclientflowEnforce
policies. These should be added to the Response PostFlow and Response PostClientFlow sections, respectively.
Notice
These FlowCallout policies should be the very first step in each of their sections. All other policies should come as steps after these policies are invoked.
Example Proxy Endpoint XML File
<ProxyEndpoint name="default">
<PreFlow name="PreFlow">
<Request>
<Step>
<Name>FC-PreflowEnforce</Name>
</Step>
<!-- Additional PreFlow Request steps... -->
</Request>
</PreFlow>
<PostFlow name="PostFlow">
<Response>
<Step>
<Name>FC-PostflowEnforce</Name>
</Step>
<!-- Additional PostFlow Response steps... -->
</Response>
</PostFlow>
<PostClientFlow>
<Request />
<Response>
<Step>
<Name>FC-PostclientflowEnforce</Name>
</Step>
<!-- Additional PostClientFlow Response steps... -->
</Response>
</PostClientFlow>
<HTTPProxyConnection>
<BasePath>/TEMP_PATH</BasePath>
</HTTPProxyConnection>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
</ProxyEndpoint>
A Note About Shared Flows
If you are adding these FlowCallout steps to a custom Shared Flow rather than an API Proxy directly, make sure that the Shared Flows are invoked in the proper sections (Request PreFlow, Response PostFlow, and Response PostClientFlow, as well.
Flow Hooks
As with any Shared Flow Bundle, it is possible to trigger the preflow-enforce
and postflow-enforce
bundles as flow hooks in your desired environment. Rather than create and invoke the FC-PreflowEnforce
and FC-PostflowEnforce
policies as described above, you can simply select the two Shared Flow Bundles as Pre-proxy and Post-proxy hooks, respectively.
However, since there is no flow hook for the PostClientFlow, the postclientflow-enforce
Shared Flow Bundle must still be triggered on all applicable API Proxies via a FlowCallout policy (FC-PostclientflowEnforce
) as described above.
Handling 4xx and 5xx Target Endpoint Responses
By default, 4xx and 5xx responses from the target endpoint trigger Fault Rules. It's important to ensure that the PostflowEnforce Flow Callout policy is still invoked in these cases. Failing to do so may affect the detection effectiveness and Credential Intelligence capabilities.
If you have any Fault Rules in your flow, the HUMAN PostflowEnforce Flow Callout policy must be called in all relevant Fault Rules. After every FaultRules section in your flow, add the HUMAN PostflowEnforce Flow Callout policy as a DefaultFaultRule:
<FaultRules>
<FaultRule name="your_fault_rule">
<Step>
...
</Step>
</FaultRule>
</FaultRules>
<DefaultFaultRule name="human-enforcer-default-fault">
<Step>
<Name>FC-PostflowEnforce</Name>
</Step>
<AlwaysEnforce>true</AlwaysEnforce>
</DefaultFaultRule>
Alternatively, these 4xx and 5xx codes may be added as success codes to the TargetEndpoint configuration to avoid triggering the Fault Rules entirely.
<TargetEndpoint name="default">
<HTTPTargetConnection>
<URL>EXAMPLE_URL</URL>
<Properties>
<Property name="success.codes">1xx,2xx,3xx,4xx,5xx</Property>
</Properties>
</HTTPTargetConnection>
</TargetEndpoint>
Updated 12 days ago