Re: [Gluster-devel] REST API authentication: JWT - Shared Token vs Shared Secret

2016-03-04 Thread Luis Pabon 
For shared secret, create a simple 10 line python program. Here is an example: 
https://github.com/heketi/heketi/wiki/API#example

- Luis

- Original Message -
From: "Aravinda" <avish...@redhat.com>
To: "Kaushal M" <kshlms...@gmail.com>
Cc: "Luis Pabon" <lpa...@redhat.com>, "Kanagaraj Mayilsamy" 
<kmayi...@redhat.com>, "Gluster Devel" <gluster-devel@gluster.org>, "Kaushal 
Madappa" <kmada...@redhat.com>
Sent: Thursday, March 3, 2016 11:04:17 PM
Subject: Re: [Gluster-devel] REST API authentication: JWT - Shared Token vs 
Shared Secret


regards
Aravinda

On 03/03/2016 05:58 PM, Kaushal M wrote:
> On Thu, Mar 3, 2016 at 2:39 PM, Aravinda <avish...@redhat.com> wrote:
>> Thanks.
>>
>> We can use Shared secret if https requirement can be completely
>> avoided. I am not sure how to use same SSL certificates in all the
>> nodes of the Cluster.(REST API server patch set 2 was written based on
>> shared secret method based on custom HMAC signing
>> http://review.gluster.org/#/c/13214/2/in_progress/management_rest_api.md)
>>
>> Listing the steps involved in each side with both the
>> approaches. (Skipping Register steps since it is common to both)
>>
>> Shared Token:
>> -
>> Client side:
>> 1. Add saved token Authorization header and initiate a REST call.
>> 2. If UnAuthorized, call /token and get access_token again and repeat
>> the step 1
>>
>> Server side:
>> 1. Verify JWT using the Server's secret.
> You forgot the part where server generates the token. :)
Oh Yes. I missed that step :)
>
>>
>> Shared Secret:
>> --
>> Client side:
>> 1. Hash the Method + URL + Params and include in qsh claim of JWT
>> 2. Using shared secret, create JWT.
>> 3. Add previously generated JWT in Authorization header and initiate
>> REST call
>>
>> Server side:
>> 1. Recalculate the hash using same details (Method + URL + Params) and
>> verify with received qsh
>> 2. Do not trust any claims, validate against the values stored in
>> Server(role/group/capabilities)
>> 3. Verify JWT using the shared secret
>>
> Anyways, I'm still not sure which of the two approaches I like better.
> My google research on this topic (ReST api authentication) led to many
> results which followed a token approach.
> This causes me to lean slightly towards shared tokens.
Yeah, Shared token is widely used method. But https is mandatory to 
avoid URL tampering. But using SSL certs in multi node setup is 
tricky.(Using same cert files across all nodes)

Shared secret approach it is difficult to test using curl or 
Postman(https://www.getpostman.com/)

>
> Since, I can't decide, I plan to write down workflows involved for
> both and try to compare them that way.
> It would probably help arrive at a decision. I'll try to share this
> ASAP (probably this weekend).
Thanks.
>
>> regards
>> Aravinda
>>
>>
>> On 03/03/2016 11:49 AM, Luis Pabon wrote:
>>> Hi Aravinda,
>>> Very good summary.  I would like to rephrase a few parts.
>>>
>>> On the shared token approach, the disadvantage is that the server will be
>>> more complicated (not *really* complicated, just more than the shared
>>> token), because it would need a login mechanism.  Server would have to both
>>> authenticate and authorize the user.  Once this has occurred a token with an
>>> expiration date can be handed back to the caller.
>>>
>>> On the shared secret approach, I do not consider the client creating a JWT
>>> a disadvantage (unless you are doing it in C), it is pretty trivial for
>>> programs written in Python, Go, Javascript etc to create a JWT on each call.
>>>
>>> - Luis
>>>
>>> - Original Message -
>>> From: "Aravinda" <avish...@redhat.com>
>>> To: "Gluster Devel" <gluster-devel@gluster.org>
>>> Cc: "Kaushal Madappa" <kmada...@redhat.com>, "Atin Mukherjee"
>>> <amukh...@redhat.com>, "Luis Pabon" <lpa...@redhat.com>,
>>> kmayi...@redhat.com, "Prashanth Pai" <p...@redhat.com>
>>> Sent: Wednesday, March 2, 2016 1:53:00 AM
>>> Subject: REST API authentication: JWT - Shared Token vs Shared Secret
>>>
>>> Hi,
>>>
>>> For Gluster REST project we are planning to use JSON Web Token for
>>> authentication. There are two approaches to use JWT, please help us to
>>> evaluate between these two options.
>>>

Re: [Gluster-devel] REST API authentication: JWT - Shared Token vs Shared Secret

2016-03-03 Thread Aravinda 


regards
Aravinda

On 03/03/2016 05:58 PM, Kaushal M wrote:

On Thu, Mar 3, 2016 at 2:39 PM, Aravinda  wrote:

Thanks.

We can use Shared secret if https requirement can be completely
avoided. I am not sure how to use same SSL certificates in all the
nodes of the Cluster.(REST API server patch set 2 was written based on
shared secret method based on custom HMAC signing
http://review.gluster.org/#/c/13214/2/in_progress/management_rest_api.md)

Listing the steps involved in each side with both the
approaches. (Skipping Register steps since it is common to both)

Shared Token:
-
Client side:
1. Add saved token Authorization header and initiate a REST call.
2. If UnAuthorized, call /token and get access_token again and repeat
the step 1

Server side:
1. Verify JWT using the Server's secret.

You forgot the part where server generates the token. :)

Oh Yes. I missed that step :)




Shared Secret:
--
Client side:
1. Hash the Method + URL + Params and include in qsh claim of JWT
2. Using shared secret, create JWT.
3. Add previously generated JWT in Authorization header and initiate
REST call

Server side:
1. Recalculate the hash using same details (Method + URL + Params) and
verify with received qsh
2. Do not trust any claims, validate against the values stored in
Server(role/group/capabilities)
3. Verify JWT using the shared secret


Anyways, I'm still not sure which of the two approaches I like better.
My google research on this topic (ReST api authentication) led to many
results which followed a token approach.
This causes me to lean slightly towards shared tokens.
Yeah, Shared token is widely used method. But https is mandatory to 
avoid URL tampering. But using SSL certs in multi node setup is 
tricky.(Using same cert files across all nodes)


Shared secret approach it is difficult to test using curl or 
Postman(https://www.getpostman.com/)




Since, I can't decide, I plan to write down workflows involved for
both and try to compare them that way.
It would probably help arrive at a decision. I'll try to share this
ASAP (probably this weekend).

Thanks.



regards
Aravinda


On 03/03/2016 11:49 AM, Luis Pabon wrote:

Hi Aravinda,
Very good summary.  I would like to rephrase a few parts.

On the shared token approach, the disadvantage is that the server will be
more complicated (not *really* complicated, just more than the shared
token), because it would need a login mechanism.  Server would have to both
authenticate and authorize the user.  Once this has occurred a token with an
expiration date can be handed back to the caller.

On the shared secret approach, I do not consider the client creating a JWT
a disadvantage (unless you are doing it in C), it is pretty trivial for
programs written in Python, Go, Javascript etc to create a JWT on each call.

- Luis

- Original Message -
From: "Aravinda" 
To: "Gluster Devel" 
Cc: "Kaushal Madappa" , "Atin Mukherjee"
, "Luis Pabon" ,
kmayi...@redhat.com, "Prashanth Pai" 
Sent: Wednesday, March 2, 2016 1:53:00 AM
Subject: REST API authentication: JWT - Shared Token vs Shared Secret

Hi,

For Gluster REST project we are planning to use JSON Web Token for
authentication. There are two approaches to use JWT, please help us to
evaluate between these two options.

http://jwt.io/

For both approach, user/app will register with Username and Secret.

Shared Token Approach:(Default as per JWT website
http://jwt.io/introduction/)

--
Server will generate JWT with pre-configured expiry once user login to
server by providing Username and Secret. Secret is encrypted and
stored in Server. Clients should include that JWT in all requests.

Advantageous:
1. Clients need not worry anything about JWT signing.
2. Single secret at server side can be used for all token verification.
3. This is a stateless authentication mechanism as the user state is
  never saved in the server memory(http://jwt.io/introduction/)
4. Secret is encrypted and stored in Server.

Disadvantageous:
1. URL Tampering can be protected only by using HTTPS.

Shared Secret Approach:
---
Secret will not be encrypted in Server side because secret is
required for JWT signing and verification. Clients will sign every
request using Secret and send that signature along with the
request. Server will sign again using the same secret to check the
signature match.

Advantageous:
1. Protection against URL Tampering without HTTPS.
2. Different expiry time management based on issued time

Disadvantageous:
1. Clients should be aware of JWT and Signing
2. Shared secrets will be stored as plain text format in server.
3. Every request should lookup for shared secret per user.


___
Gluster-devel

Re: [Gluster-devel] REST API authentication: JWT - Shared Token vs Shared Secret

2016-03-03 Thread Kaushal M 
On Thu, Mar 3, 2016 at 2:39 PM, Aravinda  wrote:
> Thanks.
>
> We can use Shared secret if https requirement can be completely
> avoided. I am not sure how to use same SSL certificates in all the
> nodes of the Cluster.(REST API server patch set 2 was written based on
> shared secret method based on custom HMAC signing
> http://review.gluster.org/#/c/13214/2/in_progress/management_rest_api.md)
>
> Listing the steps involved in each side with both the
> approaches. (Skipping Register steps since it is common to both)
>
> Shared Token:
> -
> Client side:
> 1. Add saved token Authorization header and initiate a REST call.
> 2. If UnAuthorized, call /token and get access_token again and repeat
>the step 1
>
> Server side:
> 1. Verify JWT using the Server's secret.

You forgot the part where server generates the token. :)

>
>
> Shared Secret:
> --
> Client side:
> 1. Hash the Method + URL + Params and include in qsh claim of JWT
> 2. Using shared secret, create JWT.
> 3. Add previously generated JWT in Authorization header and initiate
>REST call
>
> Server side:
> 1. Recalculate the hash using same details (Method + URL + Params) and
>verify with received qsh
> 2. Do not trust any claims, validate against the values stored in
>Server(role/group/capabilities)
> 3. Verify JWT using the shared secret
>

Anyways, I'm still not sure which of the two approaches I like better.
My google research on this topic (ReST api authentication) led to many
results which followed a token approach.
This causes me to lean slightly towards shared tokens.

Since, I can't decide, I plan to write down workflows involved for
both and try to compare them that way.
It would probably help arrive at a decision. I'll try to share this
ASAP (probably this weekend).

> regards
> Aravinda
>
>
> On 03/03/2016 11:49 AM, Luis Pabon wrote:
>>
>> Hi Aravinda,
>>Very good summary.  I would like to rephrase a few parts.
>>
>> On the shared token approach, the disadvantage is that the server will be
>> more complicated (not *really* complicated, just more than the shared
>> token), because it would need a login mechanism.  Server would have to both
>> authenticate and authorize the user.  Once this has occurred a token with an
>> expiration date can be handed back to the caller.
>>
>> On the shared secret approach, I do not consider the client creating a JWT
>> a disadvantage (unless you are doing it in C), it is pretty trivial for
>> programs written in Python, Go, Javascript etc to create a JWT on each call.
>>
>> - Luis
>>
>> - Original Message -
>> From: "Aravinda" 
>> To: "Gluster Devel" 
>> Cc: "Kaushal Madappa" , "Atin Mukherjee"
>> , "Luis Pabon" ,
>> kmayi...@redhat.com, "Prashanth Pai" 
>> Sent: Wednesday, March 2, 2016 1:53:00 AM
>> Subject: REST API authentication: JWT - Shared Token vs Shared Secret
>>
>> Hi,
>>
>> For Gluster REST project we are planning to use JSON Web Token for
>> authentication. There are two approaches to use JWT, please help us to
>> evaluate between these two options.
>>
>> http://jwt.io/
>>
>> For both approach, user/app will register with Username and Secret.
>>
>> Shared Token Approach:(Default as per JWT website
>> http://jwt.io/introduction/)
>>
>> --
>> Server will generate JWT with pre-configured expiry once user login to
>> server by providing Username and Secret. Secret is encrypted and
>> stored in Server. Clients should include that JWT in all requests.
>>
>> Advantageous:
>> 1. Clients need not worry anything about JWT signing.
>> 2. Single secret at server side can be used for all token verification.
>> 3. This is a stateless authentication mechanism as the user state is
>>  never saved in the server memory(http://jwt.io/introduction/)
>> 4. Secret is encrypted and stored in Server.
>>
>> Disadvantageous:
>> 1. URL Tampering can be protected only by using HTTPS.
>>
>> Shared Secret Approach:
>> ---
>> Secret will not be encrypted in Server side because secret is
>> required for JWT signing and verification. Clients will sign every
>> request using Secret and send that signature along with the
>> request. Server will sign again using the same secret to check the
>> signature match.
>>
>> Advantageous:
>> 1. Protection against URL Tampering without HTTPS.
>> 2. Different expiry time management based on issued time
>>
>> Disadvantageous:
>> 1. Clients should be aware of JWT and Signing
>> 2. Shared secrets will be stored as plain text format in server.
>> 3. Every request should lookup for shared secret per user.
>>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] REST API authentication: JWT - Shared Token vs Shared Secret

2016-03-03 Thread Aravinda 

Thanks.

We can use Shared secret if https requirement can be completely
avoided. I am not sure how to use same SSL certificates in all the
nodes of the Cluster.(REST API server patch set 2 was written based on
shared secret method based on custom HMAC signing
http://review.gluster.org/#/c/13214/2/in_progress/management_rest_api.md)

Listing the steps involved in each side with both the
approaches. (Skipping Register steps since it is common to both)

Shared Token:
-
Client side:
1. Add saved token Authorization header and initiate a REST call.
2. If UnAuthorized, call /token and get access_token again and repeat
   the step 1

Server side:
1. Verify JWT using the Server's secret.


Shared Secret:
--
Client side:
1. Hash the Method + URL + Params and include in qsh claim of JWT
2. Using shared secret, create JWT.
3. Add previously generated JWT in Authorization header and initiate
   REST call

Server side:
1. Recalculate the hash using same details (Method + URL + Params) and
   verify with received qsh
2. Do not trust any claims, validate against the values stored in
   Server(role/group/capabilities)
3. Verify JWT using the shared secret

regards
Aravinda

On 03/03/2016 11:49 AM, Luis Pabon wrote:

Hi Aravinda,
   Very good summary.  I would like to rephrase a few parts.

On the shared token approach, the disadvantage is that the server will be more 
complicated (not *really* complicated, just more than the shared token), 
because it would need a login mechanism.  Server would have to both 
authenticate and authorize the user.  Once this has occurred a token with an 
expiration date can be handed back to the caller.

On the shared secret approach, I do not consider the client creating a JWT a 
disadvantage (unless you are doing it in C), it is pretty trivial for programs 
written in Python, Go, Javascript etc to create a JWT on each call.

- Luis

- Original Message -
From: "Aravinda" 
To: "Gluster Devel" 
Cc: "Kaushal Madappa" , "Atin Mukherjee" , "Luis Pabon" 
, kmayi...@redhat.com, "Prashanth Pai" 
Sent: Wednesday, March 2, 2016 1:53:00 AM
Subject: REST API authentication: JWT - Shared Token vs Shared Secret

Hi,

For Gluster REST project we are planning to use JSON Web Token for
authentication. There are two approaches to use JWT, please help us to
evaluate between these two options.

http://jwt.io/

For both approach, user/app will register with Username and Secret.

Shared Token Approach:(Default as per JWT website
http://jwt.io/introduction/)
--
Server will generate JWT with pre-configured expiry once user login to
server by providing Username and Secret. Secret is encrypted and
stored in Server. Clients should include that JWT in all requests.

Advantageous:
1. Clients need not worry anything about JWT signing.
2. Single secret at server side can be used for all token verification.
3. This is a stateless authentication mechanism as the user state is
 never saved in the server memory(http://jwt.io/introduction/)
4. Secret is encrypted and stored in Server.

Disadvantageous:
1. URL Tampering can be protected only by using HTTPS.

Shared Secret Approach:
---
Secret will not be encrypted in Server side because secret is
required for JWT signing and verification. Clients will sign every
request using Secret and send that signature along with the
request. Server will sign again using the same secret to check the
signature match.

Advantageous:
1. Protection against URL Tampering without HTTPS.
2. Different expiry time management based on issued time

Disadvantageous:
1. Clients should be aware of JWT and Signing
2. Shared secrets will be stored as plain text format in server.
3. Every request should lookup for shared secret per user.



___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] REST API authentication: JWT - Shared Token vs Shared Secret

2016-03-02 Thread Luis Pabon 
Hi Aravinda,
  Very good summary.  I would like to rephrase a few parts.

On the shared token approach, the disadvantage is that the server will be more 
complicated (not *really* complicated, just more than the shared token), 
because it would need a login mechanism.  Server would have to both 
authenticate and authorize the user.  Once this has occurred a token with an 
expiration date can be handed back to the caller.

On the shared secret approach, I do not consider the client creating a JWT a 
disadvantage (unless you are doing it in C), it is pretty trivial for programs 
written in Python, Go, Javascript etc to create a JWT on each call.

- Luis

- Original Message -
From: "Aravinda" 
To: "Gluster Devel" 
Cc: "Kaushal Madappa" , "Atin Mukherjee" 
, "Luis Pabon" , kmayi...@redhat.com, 
"Prashanth Pai" 
Sent: Wednesday, March 2, 2016 1:53:00 AM
Subject: REST API authentication: JWT - Shared Token vs Shared Secret

Hi,

For Gluster REST project we are planning to use JSON Web Token for
authentication. There are two approaches to use JWT, please help us to
evaluate between these two options.

http://jwt.io/

For both approach, user/app will register with Username and Secret.

Shared Token Approach:(Default as per JWT website 
http://jwt.io/introduction/)
--
Server will generate JWT with pre-configured expiry once user login to
server by providing Username and Secret. Secret is encrypted and
stored in Server. Clients should include that JWT in all requests.

Advantageous:
1. Clients need not worry anything about JWT signing.
2. Single secret at server side can be used for all token verification.
3. This is a stateless authentication mechanism as the user state is
never saved in the server memory(http://jwt.io/introduction/)
4. Secret is encrypted and stored in Server.

Disadvantageous:
1. URL Tampering can be protected only by using HTTPS.

Shared Secret Approach:
---
Secret will not be encrypted in Server side because secret is
required for JWT signing and verification. Clients will sign every
request using Secret and send that signature along with the
request. Server will sign again using the same secret to check the
signature match.

Advantageous:
1. Protection against URL Tampering without HTTPS.
2. Different expiry time management based on issued time

Disadvantageous:
1. Clients should be aware of JWT and Signing
2. Shared secrets will be stored as plain text format in server.
3. Every request should lookup for shared secret per user.

-- 
regards
Aravinda

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] REST API authentication: JWT - Shared Token vs Shared Secret

2016-03-02 Thread Atin Mukherjee 
-Atin
Sent from one plus one
On 02-Mar-2016 12:23 pm, "Aravinda"  wrote:
>
> Hi,
>
> For Gluster REST project we are planning to use JSON Web Token for
> authentication. There are two approaches to use JWT, please help us to
> evaluate between these two options.
>
> http://jwt.io/
>
> For both approach, user/app will register with Username and Secret.
>
> Shared Token Approach:(Default as per JWT website
http://jwt.io/introduction/)
>
--
> Server will generate JWT with pre-configured expiry once user login to
> server by providing Username and Secret. Secret is encrypted and
> stored in Server. Clients should include that JWT in all requests.
>
> Advantageous:
> 1. Clients need not worry anything about JWT signing.
> 2. Single secret at server side can be used for all token verification.
> 3. This is a stateless authentication mechanism as the user state is
>never saved in the server memory(http://jwt.io/introduction/)
> 4. Secret is encrypted and stored in Server.
>
> Disadvantageous:
> 1. URL Tampering can be protected only by using HTTPS.
>
> Shared Secret Approach:
> ---
> Secret will not be encrypted in Server side because secret is
> required for JWT signing and verification. Clients will sign every
> request using Secret and send that signature along with the
> request. Server will sign again using the same secret to check the
> signature match.
>
> Advantageous:
> 1. Protection against URL Tampering without HTTPS.
> 2. Different expiry time management based on issued time
>
> Disadvantageous:
> 1. Clients should be aware of JWT and Signing
> 2. Shared secrets will be stored as plain text format in server.
> 3. Every request should lookup for shared secret per user.

Although the former looks simple (and may be easy from implementation) the
later looks more secured. Do you see any major performance bottleneck with
second one, if not my vote will be for shared secret. However at the same
point of time I'd really like to see the same technique been used by all of
our projects like Heketi, GD2 ReST etc.
>
> --
> regards
> Aravinda
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel