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)