Major Description
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.