I see - that makes sense. I'd like to understand the token validation that you plan to do to ensure that the request is coming from a trusted client. A digital signature is a good way to go for that sort of thing.
In fact, the KnoxToken service that I am in the middle of doing for 0.12.0 would give you an interesting way to achieve this. You could acquire a JWT token from a KnoxToken service endpoint then provide that to the endpoint of a topology that is configured to protect it's endpoints with a bearer token validation. This will not be available until 0.12.0 however. I should be able get it committed to master in a couple days though and you could play with it from a build of master. On Sat, Jan 21, 2017 at 3:28 PM, Mohammad Islam <[email protected]> wrote: > Thanks Larry. I was looking for this type of answer. > > After investigating the code of HeaderPreAuth module, looks like we can > add the support of custom Validator. Currently it supports IPValidator and > DefaultValidator. In particular, we can allow the admin to configure a > custom validator in topology config file. If the high-level idea looks > fine, i can upload a patch for review. > > For network security, I probably gave you a wrong impression. we used > SSL but not mutual auth because our servers are dynamically launched in > arbitrary docker instances. Our operation team thought it would be a big > challenge to manage the certificates for various docker instances. > > Regards, > Mohammad > > > > On Thursday, January 19, 2017 7:31 PM, larry mccay <[email protected]> > wrote: > > > Hi Mohammad - > > I would consider looking into the following for adding a federation > provider (federation providers do not take and validate credentials like > authentication providers) in order to validate a token that represents a > previous authentication event: > > https://cwiki.apache.org/confluence/display/KNOX/2015/ > 12/18/Adding+a+Federation+Provider+to+Apache+Knox > > Then use the HeaderPreAuth provider as an example to get to the headers > and add the validation code to your impl. > > At the same time, it might make sense to consider a plugin model for the > HeaderPreAuth provider to configure optional validation helpers that you > could use. If that is the only difference then that might make a lot of > sense. > > I am a little concerned about the statement that your network isn't > secured. I assume that you will use SSL between the client and Knox. > In addition, I would suggest that you look into setting up Knox to require > client certs for mutual authentication [1]. Otherwise, anyone that > intercepts a token can impersonate that user. > > Does that make sense? > > thanks, > > --larry > > 1. http://knox.apache.org/books/knox-0-11-0/user-guide. > html#Mutual+Authentication+with+SSL > > > On Thu, Jan 19, 2017 at 10:04 PM, Mohammad Islam < > [email protected]> wrote: > > Hi,I'm looking for a custom authentication solution in Knox for our > use-case.Let me explain the use case:For us, authentication related > information are passed as following custom HTTP headers: a) X-Auth-Token > : Client gets the encoded token after making some internal service call. > Knox server needs to retrieve this token from header and invokes a method > to authenticate the token b) X-Auth-User-Email : Client provides the > actual user email address. Server needs to parse to get the effective user > id. c) X-Auth-Source : The client's name for internal purpose > > Based on Larry's suggestion, I started with pre-auth-header for mainly b) > and c). I also configured identity-assertion to parse the email address to > get the user name. > However, our network is not secured or isolated. So pre-auth is not going > to work in its form. That's why, we include Auth-token(a) in header. My > question is how to add my custom code to authenticate the Auth-Token > passed in the header by client. Is there any example? > Regards,Mohammad > > > > >
