Menu
▾
▴
resteasy-developers
|
From: Bruno O. <br...@ab...> - 2013-07-02 09:22:00
|
Good morning everyone. I've been working to include security on AeroGear and make use of RESTEasy, to be more specific I would like to include JWT/JWS support, the API is pretty straightforward and I think is a good fit for mobile. Before move forward on AeroGear I'd like to suggest (implement if you guys agree) the inclusion two new attributes: - iat: claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing an IntDate value - exp: claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the exp claim requires that the current date/time MUST be before the expiration date/time listed in the exp claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing an IntDate value. This is important, because I wouldn't like to trust on SSL/TLS only. If for some reason this layer is broken (wrong configuration, lack of understanding from some developers) , would be nice to have an additional layer of security (it won't solve all the problems, but might help). What do you guys think? Makes sense? -- abstractj |
|
From: Bruno O. <br...@ab...> - 2013-07-02 09:12:58
|
Just correcting myself into the previous e-mail. I was talking about JWS and iat is not necessary. iat and exp was already implemented into JsonWebToken class, sorry. Bruno Oliveira wrote: > Good morning everyone. > > I've been working to include security on AeroGear and make use of > RESTEasy, to be more specific I would like to include JWT/JWS support, > the API is pretty straightforward and I think is a good fit for mobile. > > Before move forward on AeroGear I'd like to suggest (implement if you > guys agree) the inclusion two new attributes: > > - iat: claim identifies the time at which the JWT was issued. This claim > can be used to determine the age of the JWT. Its value MUST be a number > containing an IntDate value > > - exp: claim identifies the expiration time on or after which the JWT > MUST NOT be accepted for processing. The processing of the exp claim > requires that the current date/time MUST be before the expiration > date/time listed in the exp claim. Implementers MAY provide for some > small leeway, usually no more than a few minutes, to account for clock > skew. Its value MUST be a number containing an IntDate value. > > This is important, because I wouldn't like to trust on SSL/TLS only. If > for some reason this layer is broken (wrong configuration, lack of > understanding from some developers) , would be nice to have an > additional layer of security (it won't solve all the problems, but might > help). > > What do you guys think? Makes sense? > -- abstractj |
|
From: Bill B. <bb...@re...> - 2013-07-02 13:23:10
|
You want timestamp and exp in the JWS? IMO, this is not needed, its up to the entity embedded/encoded in the JWS to provide this information. On 7/2/2013 5:07 AM, Bruno Oliveira wrote: > Just correcting myself into the previous e-mail. I was talking about JWS > and iat is not necessary. > > iat and exp was already implemented into JsonWebToken class, sorry. > > Bruno Oliveira wrote: >> Good morning everyone. >> >> I've been working to include security on AeroGear and make use of >> RESTEasy, to be more specific I would like to include JWT/JWS support, >> the API is pretty straightforward and I think is a good fit for mobile. >> >> Before move forward on AeroGear I'd like to suggest (implement if you >> guys agree) the inclusion two new attributes: >> >> - iat: claim identifies the time at which the JWT was issued. This claim >> can be used to determine the age of the JWT. Its value MUST be a number >> containing an IntDate value >> >> - exp: claim identifies the expiration time on or after which the JWT >> MUST NOT be accepted for processing. The processing of the exp claim >> requires that the current date/time MUST be before the expiration >> date/time listed in the exp claim. Implementers MAY provide for some >> small leeway, usually no more than a few minutes, to account for clock >> skew. Its value MUST be a number containing an IntDate value. >> >> This is important, because I wouldn't like to trust on SSL/TLS only. If >> for some reason this layer is broken (wrong configuration, lack of >> understanding from some developers) , would be nice to have an >> additional layer of security (it won't solve all the problems, but might >> help). >> >> What do you guys think? Makes sense? >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Bruno O. <br...@ab...> - 2013-07-02 14:57:59
|
Hi Bill only the "exp" attribute from http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11 I'm not sure if makes some sense, but I would like to make use of your lib on the client side (Android - extracting bits or the whole jose-jwt module) and into the server side. Each application would have its own signature, for non repudiation against the server and prevent replay attacks. Makes some sense? If not it's ok, I can dig more into the API. Bill Burke wrote: > You want timestamp and exp in the JWS? IMO, this is not needed, its up > to the entity embedded/encoded in the JWS to provide this information. -- abstractj |
|
From: Bill B. <bb...@re...> - 2013-07-04 14:10:51
|
Why reinvent two-way SSL? Just use two-way SSL. On 7/2/2013 10:57 AM, Bruno Oliveira wrote: > Hi Bill only the "exp" attribute from > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11 > > I'm not sure if makes some sense, but I would like to make use of your > lib on the client side (Android - extracting bits or the whole jose-jwt > module) and into the server side. > > Each application would have its own signature, for non repudiation > against the server and prevent replay attacks. > > Makes some sense? If not it's ok, I can dig more into the API. > > > Bill Burke wrote: >> You want timestamp and exp in the JWS? IMO, this is not needed, its up >> to the entity embedded/encoded in the JWS to provide this information. > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Bruno O. <br...@ab...> - 2013-07-10 17:36:21
|
It's ok, the argument is for scenarios where SSL is not configured and this layer just doesn't exist. Two-way SSL is a great solution if we believe that most of our devs knows how to properly configure it. Either way it's fine. Bill Burke wrote: > Why reinvent two-way SSL? Just use two-way SSL. > > On 7/2/2013 10:57 AM, Bruno Oliveira wrote: >> Hi Bill only the "exp" attribute from >> http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11 >> >> I'm not sure if makes some sense, but I would like to make use of your >> lib on the client side (Android - extracting bits or the whole jose-jwt >> module) and into the server side. >> >> Each application would have its own signature, for non repudiation >> against the server and prevent replay attacks. >> >> Makes some sense? If not it's ok, I can dig more into the API. >> >> >> Bill Burke wrote: >>> You want timestamp and exp in the JWS? IMO, this is not needed, its up >>> to the entity embedded/encoded in the JWS to provide this information. >> > -- abstractj |
|
From: Bill B. <bb...@re...> - 2013-07-10 17:27:52
|
You still have to create and share keys and know how to use JWT. Might as well do SSL. On 7/10/2013 1:04 PM, Bruno Oliveira wrote: > It's ok, the argument is for scenarios where SSL is not configured and > this layer just doesn't exist. > > Two-way SSL is a great solution if we believe that most of our devs > knows how to properly configure it. > > Either way it's fine. > > Bill Burke wrote: >> Why reinvent two-way SSL? Just use two-way SSL. >> >> On 7/2/2013 10:57 AM, Bruno Oliveira wrote: >>> Hi Bill only the "exp" attribute from >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11 >>> >>> I'm not sure if makes some sense, but I would like to make use of your >>> lib on the client side (Android - extracting bits or the whole jose-jwt >>> module) and into the server side. >>> >>> Each application would have its own signature, for non repudiation >>> against the server and prevent replay attacks. >>> >>> Makes some sense? If not it's ok, I can dig more into the API. >>> >>> >>> Bill Burke wrote: >>>> You want timestamp and exp in the JWS? IMO, this is not needed, its up >>>> to the entity embedded/encoded in the JWS to provide this information. >>> >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
Thanks for helping keep SourceForge clean.
X