Hi Adam -

Let me articulate the expected pattern for such a deployment - so that we
are both on the same page...

* Users authenticate to Knox via whatever configured
authentication/federation provider mechanism
* Knox authenticates to the proxied services via kerberos (in secure
clusters) as Knox and asserts the identity via doAs
* The proxied service needs to ensure that only "trusted" proxies issue
requests on behalf of end users via doAs
* Trust is generally determined via kerberos authentication but could be
done in other ways as well but would likely require work on the Knox side
to provide something else - like mutual authentication via SSL, etc.

Current support for authenticating users with kerberos via the hadoop auth
module assumes the above trusted proxy pattern as well.

There may be some way to provide a passthrough of the kerberos header but
this may not be as straightforward as other HTTP headers. SPNEGO
authentication is expected between Knox and the proxied service therefore
passing the end user's ticket may cause difficulties in establishing the
connection to the service.

Generally speaking, I would encourage you to adopt the above described
pattern rather than introduce some new pattern in a secure environment.

HTH,

--larry




On Wed, Feb 17, 2016 at 7:03 AM, Adam Davidson <
[email protected]> wrote:

> Hi,
>
> we are using Knox on a Kerberized cluster to secure access a RESTful Java
> application. We know the user making the request is authenticated against
> Kerberos in Knox, but is the resulting ticket then passed on with the
> request? We believe there is a security issue in our app where we do not
> authenticate the 'doAs' user supplied by Knox. From inside the cluster, a
> malicious actor may in theory supply any value for this parameter in their
> request and be granted the same access as that user.
>
> So, is the Kerberos ticket passed on that our service could then
> authenticate? Or do we just assume that the Kerberos authentication is a
> one-time job that happens in the Knox gateway?
>
> Best Regards,
> Adam
>
> *We're hiring!*
>  Please check out our current positions *here*
> <https://www.bigdatapartnership.com/careers/>*.*
> ------------------------------
>
> *NOTICE AND DISCLAIMER*
>
> This email (including attachments) is confidential. If you are not the
> intended recipient, notify the sender immediately, delete this email from
> your system and do not disclose or use for any purpose.
>
> Business Address: Eagle House, 163 City Road, London, EC1V 1NR. United
> Kingdom
> Registered Office: Finsgate, 5-7 Cranwood Street, London, EC1V 9EE. United
> Kingdom
> Big Data Partnership Limited is a company registered in England & Wales
> with Company No 7904824
>

Reply via email to