Kevin Minder created KNOX-671:
---------------------------------

             Summary: Custom filter chains in config driver service definitions
                 Key: KNOX-671
                 URL: https://issues.apache.org/jira/browse/KNOX-671
             Project: Apache Knox
          Issue Type: New Feature
          Components: Server
    Affects Versions: 0.6.0
            Reporter: Kevin Minder
             Fix For: Future


As discussed in KNOX-670 it would ideal if config based service definitions 
could define custom filter chains by exception for routes that have special 
requirements.  Example use cases for this are:
1. A REST API may have a status or version resource that does not require 
authentication or authorization but still potentially rewrite.
2. As the application work progresses the login routes for the application may 
want to avoid authentication and authorization while the remainder of the 
application is protected.

As described in KNOX-670 the configuration to accomplish might look as follows:
{code:xml}
<service role="MYROLE" name="myimpl" version="1.2.3">
    <chains>
        <chain name="alt-secure">
            <provider role="xforwarded"/>
            <provider role="authentication" name="custom-authn/>
            <provider role="rewrite"/>
        </chain>
    <chains>
    <routes>
        <route path="/special/**" chain="alt-secure"/>
        <route path="/**"/>
    </routes>
</service>
{code}
One thing that strikes me to consider is how deployment should behave in this 
example.  If the custom-authn authentication provider isn't configured in the 
topology file should deployment fail?  Part of me wants to say yes for 
usability.  On the other hand one of the real use cases I'm thinking of using 
this for is solving the issue with WebHdfs and Kerberos.  This issue is that DN 
routes really should not be issuing challenges and should be relying on the 
authentication done by the NameNode routes.  Therefore the NameNode routes and 
the DataNode routes need different authentication mechanisms.  So ideally there 
would be a special WebHdfsDataNode authentication provider implementation that 
would never need to be configured so it would never need to be seen in a 
topology file.

Perhaps something needs to be added to a ProviderDeploymentContributor to 
indicate if it requires configuration thereby allowing the DeploymentFactory to 
make an informed decision?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to