[
https://issues.apache.org/jira/browse/KNOX-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144534#comment-15144534
]
Sumit Gupta commented on KNOX-671:
----------------------------------
I actually implemented something like this when I put in the service definition
files. I used the overused and sometimes grand word 'policy' though. This
following snippet should work right now:
{code:xml}
<service role="FOO" name="foo" version="1.0.0">
<policies>
<policy role="webappsec"/>
<policy role="authentication"/>
<policy role="rewrite"/>
<policy role="identity-assertion"/>
<policy role="authorization"/>
</policies>
<routes>
<route path="/foo/?**">
<rewrite apply="FOO/foo/inbound" to="request.url"/>
<policies>
<policy role="webappsec"/>
<policy role="federation"/>
<policy role="identity-assertion"/>
<policy role="authorization"/>
<policy role="rewrite"/>
</policies>
</route>
</routes>
{code:xml}
We can certainly change the names to make more sense.
> 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)
