[jira] [Comment Edited] (KNOX-671) Custom filter chains in config driven service definitions

["Sumit Gupta (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KNOX-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144534#comment-15144534 ] 

Sumit Gupta edited comment on KNOX-671 at 2/12/16 12:37 PM:
------------------------------------------------------------

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}

We can certainly change the names to make more sense. 


was (Author: sumit.gupta):
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)