Ahoy
Matthias Wessendorf wrote:
> >
> > On Tue, Jul 2, 2013 at 11:48 AM, Bruno Oliveira
> <bruno@abstractj.org <mailto:bruno@abstractj.org>
> > <mailto:bruno@abstractj.org <mailto:bruno@abstractj.org>>> wrote:Gotcha and yes. You must to setup security constraints on JBoss for it
> >
> > 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" ?
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.
There are no stupid questions, it must be clear to everybody. For
>
> 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).
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)
That's the idea.
>
>
> 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 ?
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
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev