[
https://issues.apache.org/jira/browse/KNOX-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144689#comment-15144689
]
Kevin Minder commented on KNOX-671:
-----------------------------------
In my line of thinking these named chains would be scoped within a single
service (or application) definition file. So they could never be reference at
a global level (or between services) without some additional
design/implementation. They are purely a syntactic short cut. Keep in mind
that there is a "default" chain definition hard coded into
ServiceDefinitionDeploymentContributor so in effect there sort of is one
"global" chain definition.
> 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
>
>
> 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)
