[aerogear-dev] Security on AeroGear
Matthias Wessendorf
matzew at apache.org
Tue Jul 2 10:43:16 EDT 2013
On Tue, Jul 2, 2013 at 4:35 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> 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.
>
Ah...! :) Thanks for the iterations here :) But yes, I agree that we do
not want this!
So a late +1 on your original statement :)
>
> >
> > 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.
>
that's cool
>
> For transactions I doubt it, because they have specific requirements not
> present on AeroGear like: pricePoint, icons, productData.......(also
> not present into the specification)
>
yeah, agree - I was more interested in the "digital signatures" part
>
> >
> >
> > 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.
sound good. Again +1 on the overall idea, and thanks for explaining!
> As far as I know this RESTEasy module is not CDI
> dependent, so I'd say it's possible.
>
@Dependent :)
I do not know, but good luck :)
>
> >
> >
> >
> > >
> > > 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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130702/a53d9e52/attachment-0001.html
More information about the aerogear-dev
mailing list