<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 2, 2013 at 3:14 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">Answers inline.<br>
<div class="im"><br>
Matthias Wessendorf wrote:<br>
> Hi Bruno,<br>
><br>
><br>
> On Tue, Jul 2, 2013 at 11:48 AM, Bruno Oliveira <<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>>> wrote:<br>
><br>
> Good morning everyone, I'm planning to include JWS (to add digital<br>
> signatures per mobile application)/JWT (to issue a token at each<br>
> transaction or session) support on AeroGear and I was looking 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 client side and<br>
> security is not an island :). RESTEasy bearer tokens is completely tied<br>
> to JBoss<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 based<br>
> JBoss security domain", right?<br>
><br>
<br>
</div>Nope. This comes from the requirement "add security to AG" :)<br></blockquote><div><br></div><div style>I was more asking about the "completely tied to JBoss" note.</div><div style><br></div><div style>
Is that because of "...based JBoss security domain" ? </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">
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>
<div class="im"><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 (please look at<br>
> the documentation<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>
</div>Yes.<br></blockquote><div><br></div><div style>Ok</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>
> 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>
</div>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></blockquote><div><br></div><div style>sounds good </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">
<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>
<div class="im"><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 WebPayment<br>
> thing, right ?<br>
<br>
</div>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></blockquote><div><br></div><div style>:-) I was expecting we are not using the WebPayment.</div><div style><br></div><div style>Perhaps my question was stupid - let me try again.</div><div style>
If we have the JWT (e.g. on AG-JavaScript), could our bits could be used</div><div style>against a WebPayment Server ? (not sure if tehre is something).</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">
<br>
Into our project will be just JWT/JWS implementation with the RESTEasy<br>
module.<br></blockquote><div><br></div><div style>And since that is "wrapped" by AG-Security, it's not really tied to JBoss, since<br></div><div style>we could have other "adapters", e.g. for Nodej/vert.x ? <br>
</div><div style><br></div><div style><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 class="im"><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 above<br>
> comments on JWS/JWT :)<br>
<br>
</div>Feel free to ask, sorry for my bad explanation.<br></blockquote><div><br></div><div style>I guess we are getting there :) </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 class="im"><br>
><br>
><br>
> Cons: The authorization model must be implemented and adapted to our<br>
> needs<br>
><br>
><br>
> That could be done on-top of what we already have for AeroGear Security ?<br>
<br>
</div>Yup, that's the idea.<br>
<div class="im">><br>
><br>
> -Matthias<br>
><br>
><br>
> So what do you think?<br>
><br>
> ps: SAML is not an option for me now.<br>
><br>
> --<br>
> abstractj<br>
><br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
</div>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a> <mailto:<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>><br>
<div class=""><div class="h5">> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
><br>
><br>
><br>
> --<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><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>
<br>
--<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>