On Tue, Jul 2, 2013 at 3:14 PM, Bruno Oliveira <bruno@abstractj.org> wrote:
Answers inline.

Matthias Wessendorf wrote:
> Hi Bruno,
>
>
> On Tue, Jul 2, 2013 at 11:48 AM, Bruno Oliveira <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.html#d4e1446)
>     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.html#d4e1446),
>     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
>
>
>     So what do you think?
>
>     ps: SAML is not an option for me now.
>
>     --
>     abstractj
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

--
abstractj

_______________________________________________
aerogear-dev mailing list
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