[
https://issues.apache.org/jira/browse/KNOX-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated KNOX-1051:
-------------------------------
Fix Version/s: (was: 1.2.0)
> Provide Validation in Addition to the Authentication/Federation Provider
> -------------------------------------------------------------------------
>
> Key: KNOX-1051
> URL: https://issues.apache.org/jira/browse/KNOX-1051
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Larry McCay
> Priority: Major
> Labels: security
>
> I have come across a number of deployment scenarios where it would be good to
> extend the capabilities of the authentication or federation provider with
> additional validation of the client doing the request.
> Validation is currently an aspect of the PreAuth SSO Provider and is pretty
> powerful. This may be refactored to be available across other providers as
> well.
> An example usecase could be:
> * An application is leveraging KnoxSSO for authentication and as a result has
> an application SSO cookie with a JWT token issued by the KnoxSSO instance in
> their Knox deployment.
> * The same application needs to make REST calls to a Knox gateway in another
> Hadoop cluster
> * In order to federate the original authentication event, the backend of the
> application can exchange the KnoxSSO cookie token for a Hadoop cluster token
> using the KnoxToken service and the SSOCookieProvider
> * We can lock down who the users are based on their groups and even the ip
> address of where to expect the calls to come from
> * We cannot however provide real authentication of the calling entity
> By adding a validation provider capability to any topology, regardless of
> provider selected, we can write a simple validator that ensures that a client
> cert has been provided - when used along with ClientCertWanted feature in
> KNOX-1050.
> Another approach may be to allow for multiple authentication providers and we
> could add an X509 Cert Provider to chain together along with the
> SSOCookieProvider. However, I don't think this will work as they will both
> try and set the effective user. Requiring the order of them to determine
> which one wins seems like it would be error prone. Therefore, I think
> additional validators on top of authentication/federation is the right
> approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
