[ https://issues.apache.org/jira/browse/KNOX-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144657#comment-15144657 ]
Larry McCay commented on KNOX-671: ---------------------------------- While I like the referencing of named chains, I think that I am missing how they are leveraged from a global level. The example for MYROLE defines a named chain and references it inside the routes in the same service definition. Are there any thoughts on having named chains that could be used across service definitions? > 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)