[
https://issues.apache.org/jira/browse/KNOX-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Minder updated KNOX-671:
------------------------------
Description:
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?
was:
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?
> 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)
