[aerogear-dev] Security on AeroGear

[Bruno Oliveira]

Ahoy

Matthias Wessendorf wrote:
>      >
>      > On Tue, Jul 2, 2013 at 11:48 AM, Bruno Oliveira
>     <bruno at abstractj.org <mailto:bruno at abstractj.org>
>      > <mailto:bruno at abstractj.org <mailto:bruno at 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" ?

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.html#d4e1657 
and quoting the documentation "You must though use FORM authentication" 
(http://docs.jboss.org/resteasy/docs/3.0.1.Final/userguide/html/oauth2.html#d4e1654)

I'm not saying this is wrong, is just the framework design.

>
>     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).

There are no stupid questions, it must be clear to everybody. For 
authentication and digital signatures I would say, yes.

For transactions I doubt it, because they have specific requirements not 
present on AeroGear like:  pricePoint, icons, productData.......(also 
not present into the specification)

>
>
>     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. As far as I know this RESTEasy module is not CDI 
dependent, so I'd say it's possible.

>
>
>
>      >
>      >     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