[
https://issues.apache.org/jira/browse/KNOX-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Minder updated KNOX-671:
------------------------------
Attachment: KNOX-671_001.patch
The patch KNOX-671_001.patch implements the "by reference" mechanism discussed
here.
It ended up looking like this in order to maintain backward compatibility with
what was already there.:
{code:xml}
<service role="TEST-SERVICE-ROLE" name="test-route-ref" version="1.2.3">
<!-- This is the default policy set for this service.
<!-- It is used for any route of this service that does define or reference
one by name. -->
<!-- It is the default by virtue of the fact that it is unnamed. -->
<policies>
<policy role="authentication"/>
</policies>
<!-- A named policy set that must be referenced by name. -->
<policies name="custom">
<policy role="authentication"/>
<policy role="test-provider-role"/>
</policies>
<routes>
<!-- Uses the default policy set above. -->
<route path="/test-default-path/?**"/>
<!-- Uses the policy set named custom above. -->
<route path="/test-custom-path/?**">
<policies name="custom"/>
</route>
<!-- Create a unique per route policy set. -->
<route path="/test-custom-path/?**">
<policies>
<policy role="authentication"/>
<policy role="authorization"/>
<policy role="test-provider-role"/>
</policies>
</route>
</routes>
</service>
{code}
Perhaps as important as the new feature the patch adds a bunch of test coverage.
This can be found in DeploymentFactoryFuncTest with meethods like
testDeploymentOfServiceDefsWithRoutePolicyBindingNamedReference.
In doing this work I've run into some assumptions built into the service
definition contributor that may cause problems with how I intend to use it.
Two things in particular:
1. It adds certain filters (e.g. X-Forwarded and Rewrite) explicitly instead of
using contributors.
2. There are explicit checks that prevent contributors from firing unless there
is config present in the topology.
I didn't mess with either of these in this patch but I think they will both
need refinement.
> Custom filter chains in config driven 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
>
> Attachments: KNOX-671_001.patch
>
>
> 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)
