Good morning everyone, I'm planning to include JWS (to add digital signatures per mobile application)/JWT (to issue a token at each transaction or session) support on AeroGear and I was looking at OAuth2 bearer token (which make use of JWT/JWS behind the scenes) implementation from RESTEasy. I was reading about how to properly include it and now we have a decision to make (we because it will affect the way the client side and security is not an island :). RESTEasy bearer tokens is completely tied to JBoss ( http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm... ) and I'm not saying it is a bad thing, but with vert.x, TorqueBox, Nodej...I'm not sure if it's a good idea.

An example of Bearer Token usage extracted from RFC (http://tools.ietf.org/html/rfc6750) HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"mF_9.B5f-4.1JqM", "token_type":"Bearer", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" } Pros: RESTEasy team already did it Cons: The configuration setup might be hard to newcomers (please look at the documentation http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm... ), we will be tied to JBoss.

So, do we have an alternative? Yes. Make use of JWT module only from RESTEasy and we still can benefit of digital signatures and tokens. An example of JWT usage extracted from RFC (http://tools.ietf.org/html/draft-jones-json-web-token-10#page-6) { "iss":"joe", "exp":1300819380, "http://example.com/is_root":true } Pros: Flexibility, we have people already doing it (https://wiki.mozilla.org/WebAPI/WebPayment). We will make use of RESTEasy module and do not reinvent the wheel. Cons: The authorization model must be implemented and adapted to our needs +1

So what do you think? ps: SAML is not an option for me now. -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi Bruno, On Tue, Jul 2, 2013 at 11:48 AM, Bruno Oliveira <bruno(a)abstractj.org <mailto:bruno@abstractj.org>> wrote: Good morning everyone, I'm planning to include JWS (to add digital signatures per mobile application)/JWT (to issue a token at each transaction or session) support on AeroGear and I was looking at OAuth2 bearer token (which make use of JWT/JWS behind the scenes) implementation from RESTEasy. I was reading about how to properly include it and now we have a decision to make (we because it will affect the way the client side and security is not an island :). RESTEasy bearer tokens is completely tied to JBoss (http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm...) and I'm not saying it is a bad thing, but with vert.x, TorqueBox, Nodej...I'm not sure if it's a good idea. That is because of (from the requirements): "A username/password based JBoss security domain", right?

An example of Bearer Token usage extracted from RFC (http://tools.ietf.org/html/rfc6750) HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"mF_9.B5f-4.1JqM", "token_type":"Bearer", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" } Pros: RESTEasy team already did it Cons: The configuration setup might be hard to newcomers (please look at the documentation http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm...), we will be tied to JBoss. So, do we have an alternative? Yes. good :-) Make use of JWT module only from RESTEasy you mean only the JWT(==JSON Web Token) - not the "bearer token" ?

and we still can benefit of digital signatures and tokens. The digital signatures would be still JWS (==JSON Web Signature) ?

An example of JWT usage extracted from RFC (http://tools.ietf.org/html/draft-jones-json-web-token-10#page-6) { "iss":"joe", "exp":1300819380, "http://example.com/is_root":true } Pros: Flexibility, we have people already doing it (https://wiki.mozilla.org/WebAPI/WebPayment). So our "client side" hook could be basically used with that WebPayment thing, right ?

We will make use of RESTEasy module and do not reinvent the wheel. +1 on reusing existing code. Not sure I fully understand (see my above comments on JWS/JWT :)

Cons: The authorization model must be implemented and adapted to our needs That could be done on-top of what we already have for AeroGear Security ?

-Matthias So what do you think? ps: SAML is not an option for me now. -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

> > On Tue, Jul 2, 2013 at 11:48 AM, Bruno Oliveira <bruno(a)abstractj.org <mailto:bruno@abstractj.org> > <mailto:bruno@abstractj.org <mailto:bruno@abstractj.org>>> wrote: > > Good morning everyone, I'm planning to include JWS (to add digital > signatures per mobile application)/JWT (to issue a token at each > transaction or session) support on AeroGear and I was looking at OAuth2 > bearer token (which make use of JWT/JWS behind the scenes) > implementation from RESTEasy. > > I was reading about how to properly include it and now we have a > decision to make (we because it will affect the way the client side and > security is not an island :). RESTEasy bearer tokens is completely tied > to JBoss > (http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm...) > and I'm not saying it is a bad thing, but with vert.x, TorqueBox, > Nodej...I'm not sure if it's a good idea. > > > > That is because of (from the requirements): "A username/password based > JBoss security domain", right? > Nope. This comes from the requirement "add security to AG" :) I was more asking about the "completely tied to JBoss" note. Is that because of "...based JBoss security domain" ?

Username/Password are cool, the goal here is to add token between client/server. This token will come with timestamp, in this way if someone eavesdropping your connection steal your username/password, the token will be required. > > An example of Bearer Token usage extracted from RFC > (http://tools.ietf.org/html/rfc6750) > > HTTP/1.1 200 OK > Content-Type: application/json;charset=UTF-8 > Cache-Control: no-store > Pragma: no-cache > > { > "access_token":"mF_9.B5f-4.1JqM", > "token_type":"Bearer", > "expires_in":3600, > "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" > } > > Pros: RESTEasy team already did it > Cons: The configuration setup might be hard to newcomers (please look at > the documentation > http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm...), > we will be tied to JBoss. > > So, do we have an alternative? Yes. > > > good :-) > > Make use of JWT module only from > RESTEasy > > > you mean only the JWT(==JSON Web Token) - not the "bearer token" ? Yes. Ok > > and we still can benefit of digital signatures and tokens. > > > > The digital signatures would be still JWS (==JSON Web Signature) ? Yup, to avoid confusion: - JSON Web signatures: can be used to sign http requests against the server (do not replace the certificate) and avoid DDoS against the server, non repudiation sounds good - JSON Web token: another security layer (OPTIONAL). If for some reason SSL was misconfigured, broken....you still have this layer of security (this token is time-based, "MACed" and irreversible). > > > An example of JWT usage extracted from RFC > (http://tools.ietf.org/html/draft-jones-json-web-token-10#page-6) > > { > "iss":"joe", > "exp":1300819380, > "http://example.com/is_root":true > } > > Pros: Flexibility, we have people already doing it > (https://wiki.mozilla.org/WebAPI/WebPayment). > > > So our "client side" hook could be basically used with that WebPayment > thing, right ? No. Sorry, I should explain that better, this is just an example. We will not make use of WebPayment API, this is a snippet from Mozilla (I was giving the credit, instead of just cut & paste. And also showing an example where JWT is used). :-) I was expecting we are not using the WebPayment. Perhaps my question was stupid - let me try again. If we have the JWT (e.g. on AG-JavaScript), could our bits could be used against a WebPayment Server ? (not sure if tehre is something).

Into our project will be just JWT/JWS implementation with the RESTEasy module. And since that is "wrapped" by AG-Security, it's not really tied to JBoss, since we could have other "adapters", e.g. for Nodej/vert.x ?

> > We will make use of > RESTEasy module and do not reinvent the wheel. > > > +1 on reusing existing code. Not sure I fully understand (see my above > comments on JWS/JWT :) Feel free to ask, sorry for my bad explanation. I guess we are getting there :) > > > Cons: The authorization model must be implemented and adapted to our > needs > > > That could be done on-top of what we already have for AeroGear Security ? Yup, that's the idea. > > > -Matthias >

On Tue, Jul 2, 2013 at 4:35 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Ahoy > > Matthias Wessendorf wrote: > > > > > > On Tue, Jul 2, 2013 at 11:48 AM, Bruno Oliveira > > <bruno(a)abstractj.org <mailto:bruno@abstractj.org> > > > <mailto:bruno@abstractj.org <mailto:bruno@abstractj.org>>> wrote: > > > > > > Good morning everyone, I'm planning to include JWS (to add > > digital > > > signatures per mobile application)/JWT (to issue a token at each > > > transaction or session) support on AeroGear and I was looking > > at OAuth2 > > > bearer token (which make use of JWT/JWS behind the scenes) > > > implementation from RESTEasy. > > > > > > I was reading about how to properly include it and now we have a > > > decision to make (we because it will affect the way the > > client side and > > > security is not an island :). RESTEasy bearer tokens is > > completely tied > > > to JBoss > > > > > (http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm...) > > > and I'm not saying it is a bad thing, but with vert.x, TorqueBox, > > > Nodej...I'm not sure if it's a good idea. > > > > > > > > > > > > That is because of (from the requirements): "A username/password > > based > > > JBoss security domain", right? > > > > > > > Nope. This comes from the requirement "add security to AG" :) > > > > > > I was more asking about the "completely tied to JBoss" note. > > > > Is that because of "...based JBoss security domain" ? > > Gotcha and yes. You must to setup security constraints on JBoss for it > http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm... > and quoting the documentation "You must though use FORM authentication" > (http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm...) > > I'm not saying this is wrong, is just the framework design. Ah...! :) Thanks for the iterations here :) But yes, I agree that we do not want this! So a late +1 on your original statement :) > > > > > Username/Password are cool, the goal here is to add token between > > client/server. > > > > This token will come with timestamp, in this way if someone > > eavesdropping your connection steal your username/password, the token > > will be required. > > > > > > > > An example of Bearer Token usage extracted from RFC > > > (http://tools.ietf.org/html/rfc6750) > > > > > > HTTP/1.1 200 OK > > > Content-Type: application/json;charset=UTF-8 > > > Cache-Control: no-store > > > Pragma: no-cache > > > > > > { > > > "access_token":"mF_9.B5f-4.1JqM", > > > "token_type":"Bearer", > > > "expires_in":3600, > > > "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" > > > } > > > > > > Pros: RESTEasy team already did it > > > Cons: The configuration setup might be hard to newcomers > > (please look at > > > the documentation > > > > > http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.htm...), > > > we will be tied to JBoss. > > > > > > So, do we have an alternative? Yes. > > > > > > > > > good :-) > > > > > > Make use of JWT module only from > > > RESTEasy > > > > > > > > > you mean only the JWT(==JSON Web Token) - not the "bearer token" ? > > > > Yes. > > > > > > Ok > > > > > > > > > > and we still can benefit of digital signatures and tokens. > > > > > > > > > > > > The digital signatures would be still JWS (==JSON Web Signature) ? > > > > Yup, to avoid confusion: > > > > - JSON Web signatures: can be used to sign http requests against the > > server (do not replace the certificate) and avoid DDoS against the > > server, non repudiation > > > > > > sounds good > > > > > > - JSON Web token: another security layer (OPTIONAL). If for some reason > > SSL was misconfigured, broken....you still have this layer of security > > (this token is time-based, "MACed" and irreversible). > > > > > > > > > > > An example of JWT usage extracted from RFC > > > (http://tools.ietf.org/html/draft-jones-json-web-token-10#page-6) > > > > > > { > > > "iss":"joe", > > > "exp":1300819380, > > > "http://example.com/is_root":true > > > } > > > > > > Pros: Flexibility, we have people already doing it > > > (https://wiki.mozilla.org/WebAPI/WebPayment). > > > > > > > > > So our "client side" hook could be basically used with that > > WebPayment > > > thing, right ? > > > > No. > > > > Sorry, I should explain that better, this is just an example. We will > > not make use of WebPayment API, this is a snippet from Mozilla (I was > > giving the credit, instead of just cut & paste. And also showing an > > example where JWT is used). > > > > > > :-) I was expecting we are not using the WebPayment. > > > > Perhaps my question was stupid - let me try again. > > If we have the JWT (e.g. on AG-JavaScript), could our bits could be used > > against a WebPayment Server ? (not sure if tehre is something). > > There are no stupid questions, it must be clear to everybody. For > authentication and digital signatures I would say, yes. that's cool > > For transactions I doubt it, because they have specific requirements not > present on AeroGear like: pricePoint, icons, productData.......(also > not present into the specification) yeah, agree - I was more interested in the "digital signatures" part > > > > > > > Into our project will be just JWT/JWS implementation with the RESTEasy > > module. > > > > > > And since that is "wrapped" by AG-Security, it's not really tied to > > JBoss, since > > we could have other "adapters", e.g. for Nodej/vert.x ? > > That's the idea. sound good. Again +1 on the overall idea, and thanks for explaining! > As far as I know this RESTEasy module is not CDI > dependent, so I'd say it's possible. @Dependent :) I do not know, but good luck :) > > > > > > > > > > > > > We will make use of > > > RESTEasy module and do not reinvent the wheel. > > > > > > > > > +1 on reusing existing code. Not sure I fully understand (see my > > above > > > comments on JWS/JWT :) > > > > Feel free to ask, sorry for my bad explanation. > > > > > > I guess we are getting there :) > > > > > > > > > > > > > Cons: The authorization model must be implemented and adapted > > to our > > > needs > > > > > > > > > That could be done on-top of what we already have for AeroGear > > Security ? > > > > Yup, that's the idea. > > > > > > > > > -Matthias > > > > > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

So the bearer token would be a HTTP Header and the JWS/JWT items would be part of the request body?

Are the tokens the same for the whole session or are they also a function of the request content? (A Hash, etc)