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