Understood. Thanks. On Fri, Feb 12, 2016 at 10:20 AM, Kevin Minder (JIRA) <[email protected]> wrote:
> > [ > 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) >
