You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@knox.apache.org by Mohammad Islam <mi...@yahoo.com> on 2017/01/20 03:04:40 UTC
Knox custom authentication
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
Re: Knox custom authentication
Posted by Mohammad Islam <mi...@yahoo.com.INVALID>.
Thanks Larry for weekend and quick reply!
We will get the token/claim from our custom secured token service provider that is used by other internal services. And it will be validate by the similar logic as well.
I'm going with the custom validator option for the time being.
Regards,Mohammad
On Saturday, January 21, 2017 1:41 PM, larry mccay <la...@gmail.com> wrote:
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 <mi...@yahoo.com> 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 <lm...@apache.org> 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 <mi...@yahoo.com.invalid> 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
Re: Knox custom authentication
Posted by Mohammad Islam <mi...@yahoo.com>.
Thanks Larry for weekend and quick reply!
We will get the token/claim from our custom secured token service provider that is used by other internal services. And it will be validate by the similar logic as well.
I'm going with the custom validator option for the time being.
Regards,Mohammad
On Saturday, January 21, 2017 1:41 PM, larry mccay <la...@gmail.com> wrote:
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 <mi...@yahoo.com> 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 <lm...@apache.org> 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 <mi...@yahoo.com.invalid> 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
Re: Knox custom authentication
Posted by larry mccay <la...@gmail.com>.
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 <mi...@yahoo.com> 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 <lm...@apache.org>
> 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 <
> mislam77@yahoo.com.invalid> 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
>
>
>
>
>
Re: Knox custom authentication
Posted by larry mccay <la...@gmail.com>.
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 <mi...@yahoo.com> 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 <lm...@apache.org>
> 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 <
> mislam77@yahoo.com.invalid> 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
>
>
>
>
>
Re: Knox custom authentication
Posted by Mohammad Islam <mi...@yahoo.com.INVALID>.
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 <lm...@apache.org> 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 <mi...@yahoo.com.invalid> 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
Re: Knox custom authentication
Posted by Mohammad Islam <mi...@yahoo.com>.
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 <lm...@apache.org> 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 <mi...@yahoo.com.invalid> 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
Re: Knox custom authentication
Posted by larry mccay <lm...@apache.org>.
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 <mislam77@yahoo.com.invalid
> 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
>
Re: Knox custom authentication
Posted by larry mccay <lm...@apache.org>.
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 <mislam77@yahoo.com.invalid
> 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
>