In order to change a service definition in an existing deployment you have
to follow this special little dance to make sure the changes get picked up:
1. change service definition
2. restart the gateway so that it loads the new service definition server
side
3. touch the topology that is hosting the service so that it regenerates
the webapp that is created for each topology and deployed to
{GATEWAY_HOME}/data/deployments.
If you don't do 2 or 3, you won't see your changes.
Also, you don't want to specify a name for the authentication provider at
all - that way you get whatever authentication provider is in the topology.
In fact, you can remove the whole Policies section as you don't need to
force it to be anything other than defaults.
Your backend service will have the authenticated username asserted via a
doAs (in a secure cluster) or a user.name (in an unsecured cluster) query
param.
On Thu, Dec 20, 2018 at 9:20 AM Tomislav Novosel <[email protected]>
wrote:
> I changed line:
> <dispatch
> classname="org.apache.knox.gateway.dispatch.PassAllHeadersDispatch"/>
> in service.xml
> to:
> <dispatch classname="org.apache.knox.gateway.dispatch.DefaultDispatch"/>
>
> and name of authentication provider I changed from anonymous to
> ShiroProvider.
> Nothing happened. Access is open as it was.
>
> Tom
>
> On Thu, 20 Dec 2018 at 14:39, larry mccay <[email protected]> wrote:
>
>> If you followed the proxying article and your service definition is
>> indicating the anonymous authentication provider then that is the issue.
>> That overrides any provider configured in the topology.
>>
>>
>> On Thu, Dec 20, 2018, 8:27 AM Kevin Risden <[email protected] wrote:
>>
>>> If your service.xml has
>>>
>>> <dispatch
>>> classname="org.apache.knox.gateway.dispatch.PassAllHeadersDispatch"/>
>>>
>>> Then all the headers including the AUTHORIZATION header are passed
>>> through to the backend. This would mean that your backend is
>>> responsible for authentication.
>>>
>>> If you want Knox to do authentication, either remove the dispatch line
>>> or change it to:
>>>
>>> <dispatch classname="org.apache.knox.gateway.dispatch.DefaultDispatch"/>
>>>
>>> This will then pass through Kerberized credentials to your backend. If
>>> you are looking to do SSO with Knox then proxying isn't required.
>>>
>>> Kevin Risden
>>> On Thu, Dec 20, 2018 at 8:22 AM Tomislav Novosel <[email protected]>
>>> wrote:
>>> >
>>> > Hi Knox team,
>>> >
>>> > I'm trying to configure LDAP authentication on Knox. I followed this
>>> link to setup simple web application for testing access. It's a simple
>>> HelloWorld.
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/display/KNOX/Proxying+a+UI+using+Knox
>>> >
>>> > After setup, I've succeeded to access app through Knox gateway.
>>> >
>>> > I want to restrict access on that webapp URL with some username and
>>> password to type, so I tried to configure LDAP using this link:
>>> >
>>> >
>>> https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.2/bk_Knox_Gateway_Admin_Guide/content/setting_up_ldap_authentication.html
>>> >
>>> > After that, access was still the same, without user/pass prompt. IDK
>>> if that is even posible with Knox.
>>> > In logs I see that access is granted, response code 200.
>>> >
>>> > How can I achieve user/pass prompt when accessing webapp URL through
>>> Knox gateway?
>>> >
>>> > Thank you.
>>> > BR,
>>> > Tom
>>>
>>
