<div dir="ltr">Hi Bruno,<div><br></div><div><br><div class="gmail_extra">On Tue, Jul 2, 2013 at 11:48 AM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br>
<div class="gmail_quote"><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">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></blockquote><div><br></div><div><br></div><div style>That is because of (from the requirements): "A username/password based JBoss security domain", right?</div>
<div><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">
<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. </blockquote><div><br></div><div style>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">
Make use of JWT module only from<br>
RESTEasy </blockquote><div><br></div><div style>you mean only the JWT(==JSON Web Token) - not the "bearer token" ? </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">
and we still can benefit of digital signatures and tokens.<br></blockquote><div><br></div><div><br></div><div style>The digital signatures would be still JWS (==JSON Web Signature) ? </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>
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>). </blockquote><div><br></div><div style>So our "client side" hook could be basically used with that WebPayment thing, right ?</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">We will make use of<br>
RESTEasy module and do not reinvent the wheel.<br></blockquote><div><br></div><div style>+1 on reusing existing code. Not sure I fully understand (see my above comments on JWS/JWT :)</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>
Cons: The authorization model must be implemented and adapted to our needs<br></blockquote><div><br></div><div style>That could be done on-top of what we already have for AeroGear Security ? </div><div style><br></div><div style>
<br></div><div style>-Matthias</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>
So what do you think?<br>
<br>
ps: SAML is not an option for me now.<br>
<span class=""><font color="#888888"><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>
</font></span></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></div>