...

The downside of this approach is that it adds an additional hop to the request which can slow things down in some cases. It is also extremely critical to make sure "two-way-ssl" is enabled and trust is properly established between on-prem and cloud Knox instances by provisioning certificates, since Header Based Pre Auth authentication by itself is not secure, perimeter security around cloud Knox instance is a must, e.g. VPC, ip whitelisting for of the on-prem Knox instance/s ip address.

Setup

The following diagram describes the federated request flow.

...

	  <service>
          <role>WEBHDFS</role>
          <url>https://my.cloudurl.com:8443/gateway/aws/webhdfs</url>
		  <dispatch>
             <classname>org.apache.knox.gateway.dispatch.HeaderPreAuthFederationDispatch</classname>
             <use-two-way-ssl>true</use-two-way-ssl>
          </dispatch>
      </service> 

Following property specifies custom header name to be added to outgoing federated request (gateway.custom.federation.header.name property in gateway-site.xml ) which will be checked by the cloud HeaderPreAuth authentication providercan be used to set a custom header name. Default value of this property is "SM_USER". 

This property value needs to be same as preauth.custom.header property used by Cloud topology HeaderPreAuth authentication provider.

e.g.

    <property>
        <name>gateway.custom.federation.header.name</name>
        <value>aws_header</value>
        <description>Custom header name to be used for federated requests.</description>
    </property>

...

     <provider>          
         <role>federation</role> 
         <name>HeaderPreAuth</name>          
         <enabled>true</enabled>         
         <param>
              <name>preauth.custom.header</name>
              <value>aws_header</value>
           </param>          
     </provider>

That's all there is, now you your topology based federation should be all setupready.