creating an OAuth login vertx.io module

[Ken Yee]

Anyone have pointers to how to write a vertx module?  I looked at the online docs here:
  http://vertx.io/manual.html#modules
and it just says "For more information on modules please see the modules manual." which I can't find because it should be linking to it :-P

From digging through the group, it looks like this hasn't been implemented.  One thread had a pointer to the scribe-java library:
  https://github.com/fernandezpablo85/scribe-java/wiki/getting-started
and node.js' Passport module could also be grafted in:
  http://passportjs.org/guide/
though it seems the logical thing to do is to use scribe-java since vertx.io is java underneath. 

If anyone knows of an OAuth login module for Vertx.io already, let me know so I'm not doing duplicate work ;-)

p.s., got the inspiration for it looking at Meteor.js' demo...their ease of use is pretty snazzy :-)

[Ken Yee]

Was reading about socket.io and my brain got stuck into appending .io to everything :-)

[Ken Yee]

Found the modules manual: http://vertx.io/mods_manual.html

[bytor99999]

So would this be for an OAuth client or an OAuth server. Or both. Or two modules one for each?

Mark

[Pid]

On 08/02/2013 16:57, bytor99999 wrote:
> So would this be for an OAuth client or an OAuth server. Or both. Or two
> modules one for each?

& which OAuth library are you going to use?


p

> Mark
>
> On Saturday, February 2, 2013 12:32:11 PM UTC-8, Ken Yee wrote:
>
> Anyone have pointers to how to write a vertx module? I looked at
> the online docs here:
> http://vertx.io/manual.html#modules
> <http://vertx.io/manual.html#modules>
> and it just says "For more information on modules please see the
> modules manual." which I can't find because it should be linking to
> it :-P
>
> From digging through the group, it looks like this hasn't been
> implemented. One thread had a pointer to the scribe-java library:
>
> https://github.com/fernandezpablo85/scribe-java/wiki/getting-started
> <https://github.com/fernandezpablo85/scribe-java/wiki/getting-started>
> and node.js' Passport module could also be grafted in:
> http://passportjs.org/guide/
> though it seems the logical thing to do is to use scribe-java since

> vertx.io <http://vertx.io> is java underneath.

>
> If anyone knows of an OAuth login module for Vertx.io already, let
> me know so I'm not doing duplicate work ;-)
>
> p.s., got the inspiration for it looking at Meteor.js' demo...their
> ease of use is pretty snazzy :-)
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to vertx+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>


--

[key:62590808]

[Ken Yee]

On Friday, February 8, 2013 11:57:26 AM UTC-5, bytor99999 wrote:

So would this be for an OAuth client or an OAuth server. Or both. Or two modules one for each

OAuth client (aka, "login to your app via OAuth to twitter/facebook/etc.").
I found in the archives that you were working on an OAuth server.
I'm actually fiddling w/ Meteor to see how they did authentication because IMHO, they did a lot of things right in making it easy to integrate w/ your app...

[bytor99999]

Good point pid. We just need to integrate Spring Social and then that won't be such a problem. (famous last words) Actually, that is where I have been the past two weeks writing web pages that use Spring Social stuff.

Ken. We actually have a need for both. Right now the sign in/sign up with Twitter/Facebook is only in our website, but our clients later that connect to our vert.x instances would need the same functionality through vert.x

But we also want to be an oauth provider too. So that people can use our site the same way. Also use it for logging in to our application from devices.

Mark

[Richard Vowles]

A lot of the Java libraries specifically use Servlets. Implementing oAuth is actually pretty simple for a client, however you need to hook into whatever is processing the web requests. As far as I can see, the default web mod doesn't support chaining, but that is I am sure my lack of understanding.

[bytor99999]

I keep going back and forth between writing our oauth2 server in vert.x or in Spring MVC using Spring Security OAuth2. The main thing that the server needs to do is be able to generate tokens. handle login/logout. And if needed certain permissions. And most of that can be stored simply in say Redis.

On Saturday, February 9, 2013 4:42:03 PM UTC-8, Richard Vowles wrote:

A lot of the Java libraries specifically use Servlets. Implementing oAuth is actually pretty simple for a client, however you need to hook into whatever is processing the web requests. As far as I can see, the default web mod doesn't support chaining, but that is I am sure my lack of understanding.

What kind of chaining do you need. I would see just exposing a few "URI" mappings for each step.

Mark

[Pid]

On 11/02/2013 18:33, bytor99999 wrote:
> I keep going back and forth between writing our oauth2 server in vert.x
> or in Spring MVC using Spring Security OAuth2. The main thing that the
> server needs to do is be able to generate tokens. handle login/logout.
> And if needed certain permissions. And most of that can be stored simply
> in say Redis.

We could probably get the Apache Oltu OAuth project tweaked so it
doesn't depend on the Servlet API & adapt it from there.


p

> On Saturday, February 9, 2013 4:42:03 PM UTC-8, Richard Vowles wrote:
>
> A lot of the Java libraries specifically use Servlets. Implementing
> oAuth is actually pretty simple for a client, however you need to
> hook into whatever is processing the web requests. As far as I can
> see, the default web mod doesn't support chaining, but that is I am
> sure my lack of understanding.
>
>
> What kind of chaining do you need. I would see just exposing a few "URI"
> mappings for each step.
>
> Mark
>
>
>
>
>
>
>
>
>
> On Saturday, February 9, 2013 6:27:41 AM UTC+13, bytor99999 wrote:
>
> Good point pid. We just need to integrate Spring Social and then
> that won't be such a problem. (famous last words) Actually, that
> is where I have been the past two weeks writing web pages that
> use Spring Social stuff.
>
> Ken. We actually have a need for both. Right now the sign
> in/sign up with Twitter/Facebook is only in our website, but our
> clients later that connect to our vert.x instances would need
> the same functionality through vert.x
>
> But we also want to be an oauth provider too. So that people can
> use our site the same way. Also use it for logging in to our
> application from devices.
>
>

[bytor99999]

I looked at that Apache project and they are at 0.2 So while it might be good, I am afraid about using something so new.

Maybe there is a way to leverage Spring Security OAuth.

And now we are wondering about using OAuth 1 instead of 2 after reading a post by the original writer of 2 and that he left the project in July.

Or maybe we should just start from scratch. Most of the features of the communications are built into vert.x and all we really need is a token/code generator and easy connection to any of our database mods like Mongo, or Redis or Jdbc.

Thanks

Mark

[Ken Yee]

On Tuesday, February 12, 2013 11:58:43 AM UTC-5, bytor99999 wrote:

And now we are wondering about using OAuth 1 instead of 2 after reading a post by the original writer of 2 and that he left the project in July.

Unfortunately, everyong is switching to OAuth2, even w/ the warnings from that guy, so you pretty much have no choice since that'll be the new standard :-P

I'd guess you probably should write your own and use some of the other frameworks for inspiration for your OAuth server...
 

[James Cook]

Any progress on this?

[bytor99999]

Not on my end, we gave up on Oauth2 for our application.

On Sunday, December 22, 2013 5:04:26 AM UTC-8, James Cook wrote:

Any progress on this?

[Paulo Lopes]

For a while I've been trying to add a OAuth2 middlware to Yoke:

https://github.com/pmlopes/yoke/blob/master/framework-extras/src/main/java/com/jetdrone/vertx/yoke/extras/middleware/OAuth2.java

It is not complete and still lacks some persistence integration, I based the code on:

https://github.com/ammmir/node-oauth2-provider

which is a popular oauth2 module from nodejs.

If there are interested parties, I would love to get some help on finishing this :)

[Tim Fox]

Good work :)

--

[Stephan Wissel]

I would be very interested in Oauth 1.0, since that's what CouchDB is supporting. There seems to be some ready Python for Oauth 1.0:
http://stackoverflow.com/questions/12032903/google-urlfetch-service-with-couchdb-oauth
http://docs.couchdb.org/en/latest/api/server/authn.html

Yoke looks very interesting

[Paulo Lopes]

Hi there, currently at Yoke i am focusing on revising the API, making the Groovy API match the Java API and at the same time implement the same interfaces from the groovy lang module so code can be used with or without yoke.

I am planning a 1.1 release soon (after vert.x 2.1 is out with lots of goodies for Groovy developers and new extras such as simplified form authentication middleware, session management built in using shared data or redis (for now, mongo comming up soon) and better routing.

After that I still need to decide on work the JavaScript support which is falling behind compared to Java and Groovy and extra middleware. My plans for extra midleware are what you see on the extras package, where I've almost complete a simple OAuth2 implementation. Of course i am always open to pull requests ;)

To what regards OAuth1 the protocol is not the same so it needs a implementation from scratch. My time is scarce so I cannot promise that i will do it but again, a pull request is always welcome :)

[Jérôme LELEU]

Hi,

You should take a look at: https://github.com/pac4j/vertx-pac4j. It has OAuth (Facebook, Twitter, Google...), CAS, SAML, OpenID (Connect) and GAE supports.

See the demo: https://github.com/pac4j/vertx-pac4j-demo

Thanks.

Best regards,

Jérôme

[Jez P]

Hi Jerome, I'm creating an OAuth2 auth handler within the vertx 3 auth model. Once that's out of the way I'm keen to look at how we might go about integrating pac4j into the existing vertx-web authentication model (maybe via a pac4j auth provider) as I think pac4j gives a wider range of options and lots of oauth2-provider-specific support. I just didn't want to spend time how to make it fit with the auth model (especially as that model was changing while I was developing). Pac4j is also far more established than my auth handler.

[Jérôme LELEU]

Thanks for your quick reply. vertx-pac4j is still built on Vertx 2.1. It would be great to integrate it to Vertx 3. Just let me know if you need help with pac4j...

[Paulo Lopes]

Hi Jez,

I would suggest to implement the pac4j first as a auth provider:

https://github.com/vert-x3/vertx-auth

And then later add a handler on vertx-web like we already have for jwt:

https://github.com/vert-x3/vertx-web/blob/master/src/main/java/io/vertx/ext/web/handler/JWTAuthHandler.java

By following this approach it allows the usage of pac4j not just on web but anything that involves authN/authZ

Cheers,
Paulo

On Friday, June 12, 2015 at 10:14:15 AM UTC+2, Jez P wrote:

[Jez P]

Thanks Paulo,

I'm already quite a long way through the handler implementation though, happy to pause what's done so far and switch to pac4j as auth provider (which seems more consistent with the new auth model than it did with the previous one, things have changed quite a bit since March when I started working on the OAuth2 stuff), but I'm not sure that gets us some OAuth2 support quicker than continuing what I've done so far.

https://github.com/millross/vertx-web-oauth2 is where the WIP on the handler is.

Cheers,

Jez

[Jez P]

Thanks Jerome, I will probably need quite a lot of help with pac4j but like I said it certainly gives us a lot more than just an OAuth2 authentication handler for the vertx-web stack (which is what I'm building). If we decide it's, on balance, best to park the handler I've been building (it's reached a convenient point where that can be done, as I now have a working "happy path" integration test for web auth) and look more at pac4j integration then expect lots of questions :).

It certainly feels right to have a web auth handler for dealing with the redirect-based-authentication (which is what I've done) but I've been very painfully aware that OAuth2 is rather more than that.

[Tim Fox]

Does pac4j have a non blocking API?

[Jérôme LELEU]

Hi Tim,

vertx-pac4j is fully async but pac4j has still internal blocking calls. In fact, an authentication (with OAuth, CAS, SAML...) will generally generate one blocking HTTP call. Not that much considering a full web session of a user.

We already had a full discussion on that (https://groups.google.com/forum/#!topic/vertx/afffQr-Nv70), but I guess you finally didn't consider using pac4j for the Vertx 3 authentication module (https://github.com/vert-x3/vertx-auth), did you?

Thanks.

Best regards,

Jérôme

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/oWnoECiQpho/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Fox]

Hi Jerome,

On 13/06/15 11:43, Jérôme LELEU wrote:
> Hi Tim,
>
> vertx-pac4j is fully async but pac4j has still internal blocking calls. In
> fact, an authentication (with OAuth, CAS, SAML...) will generally generate
> one blocking HTTP call. Not that much considering a full web session of a
> user.

The issue here is not really how long this takes for a single user, it's
more about overall system scalability.

As you know Vert.x is a non blocking system and we do this for
scalability. As soon as we introduce something that blocks in the chain
then we have a potential scalability bottleneck.

If HTTP requests are executed using a blocking API, and let's say we
have 200 threads in a thread pool, and each request takes 500ms then
that means we can never have more than 400 requests per second (even
thought the actual provider e.g. google or facebook can support a much
higher throughput than that).

(Plus there's the added pain of managing another thread pool in the system)

400 requests per second may seem like a lot but I know some of our
customers are considering public facing apps which potentially might
have 10s of millions of users so 400 requests / second doesn't seem such
a lot then...

So we always aim to have non blocking solutions unless it's really not
possible (e.g. with JDBC which is inherently blocking). With OAuth there
doesn't seem anything inherently blocking about it.

[Tim Fox]

Just to clarify - I'm not saying no to an implementation that uses
Pac4j, but I would (eventually) like to see a non blocking impl, as I
think that would be preferable.

[Jez P]

Hi Jerome,

I don't know if Tim considered a general vertx-auth based on pac4j approach, but he did ask me to consider using pac4j as the basis for OAuth2 web authentication for vertx-web. The existing approach to use of pac4j didn't look like it fitted too cleanly with the (then apex) vertx-web auth interfaces so it felt like quite a sizeable chunk of work to get it implemented just for OAuth2 web authentication in the first instance. I'm still not convinced that I was wrong in that, and given that I've had very limited time to work on the OAuth2 auth handler, it's a difficult call to know whether I'd have been better off trying to just create a pac4j based auth provider or not. It's fair to say I underestimated (not being familiar with OAuth2 when I started) the work required for the OAuth2 handler approach (which is not complete), what's difficult to know is whether I'd be closer  to completion had I tried to integrate pac4j into the vert.x auth model (which has also evolved while I've been working)!

In other words, I don't know if I made the right decision, I made the one that seemed best to me at the time, but that's a very different statement :)

Jez

[Jez P]

On this point Tim, I've got a WIP entirely non-blocking approach to the web authentication part (via the various redirects), my question (and one I genuinely don't know the answer to) is whether a vertx-auth-pac4j project might be more valuable in the short term. When I started down the handler approach, it didn't feel like trying to use a busmod-style approach was the right way to go.

However, Paulo raises the very valid point of a pac4j auth provider offering far more than OAuth2. What I'm not sure of is, starting from where I am now with the handler approach, which approach gets us to a working OAuth2 authentication mechanism quickest, even if it's a limited one in the entirely non-blocking case. Maybe I should devote some time to just having a go at a pac4j authprovider during some free time this week and see if I can get a handle on whether I think I can advance that approach more quickly. There's clearly room for both approaches, it's more a question of what we focus on first. 

[Jérôme LELEU]

Hi,

I appreciate the efforts spent on integrating pac4 for OAuth support and I understand (even if I only partially agree) Tim's concerns. It seems a good way to start with pac4j before maybe going further. Making pac4j non blocking is something fairly complicated and we chose to work first on supporting more protocols and authentication mechanisms: REST support (with LDAP, DB, JWT authentication...) is coming in the future pac4j v1.8.

And yes, pac4j is and aims to be so much more: pac4j is an authentication / authorization engine. At first, it was just an insight, but I realize it might be my best idea. Java frameworks keep on reinventing the wheel when it comes to security, not always in the best way, not always in a consistent way. I'm now convinced the Java community needs a central security library on which we should gather our efforts and bridges for frameworks to benefit from this core engine. I see it every day: I noticed there are the vertx-auth-jdbc and vertx-auth-jwt modules in vertx-auth while I'm working on JWT and JDBC support in pac4j...

Thanks.

Best regards,

Jérôme

[Tim Fox]

On 14/06/15 08:50, Jérôme LELEU wrote:

Hi,

I appreciate the efforts spent on integrating pac4 for OAuth support and I understand (even if I only partially agree) Tim's concerns. It seems a good way to start with pac4j before maybe going further. Making pac4j non blocking is something fairly complicated and we chose to work first on supporting more protocols and authentication mechanisms: REST support (with LDAP, DB, JWT authentication...) is coming in the future pac4j v1.8.

And yes, pac4j is and aims to be so much more: pac4j is an authentication / authorization engine. At first, it was just an insight, but I realize it might be my best idea. Java frameworks keep on reinventing the wheel when it comes to security, not always in the best way, not always in a consistent way. I'm now convinced the Java community needs a central security library on which we should gather our efforts and bridges for frameworks to benefit from this core engine.

That sounds good, but please, please make it non blocking :)

It makes me want to cry when I see new libraries being written with exclusively blocking APIs when there's no real reason why they must be blocking.

Reactive and async is getting more popular by the day and if the library is blocking it might be ruled out from use in a reactive system or only considered as second choice.

If you provide a non blocking implementation it's easy to wrap that with a synchronous API for those users who prefer a synchronous approach - so you can appeal to both groups of users. But if you make it blocking at the core you can't magically make it non blocking by wrapping with an async API

You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

[Jérôme LELEU]

Hi,

In fact, pac4j relies itself on many internal libraries which use blocking calls.

I will finish version 1.8 with REST support and we'll work on becoming non blocking in the next version 1.9: https://github.com/pac4j/pac4j/issues/180. I let know you...

Thanks.

Best regards,

Jérôme

[Tim Fox]

Awesome!

btw.. i'm guessing the internal blocking libs are http libraries, if so then you could consider refactoring those to use the Vert.x non blocking http client :)

[Jérôme LELEU]

Yes, I will certainly need to hack in the librairies to use a non blocking HTTP client, but I think the pac4j API may need to change to use callbacks or return Future to handle async calls. Maybe I'll create a 2.0 instead of a 1.9 version if the breaking changes are too big!

Then, I'll claim for my "Reactive" flag ;-)

[Jez P]

Hi Jerome,

I've looked into this a bit and I have a quick question:-

the vertx-pac4j module uses these constants which are deprecated

/** @deprecated */
@Deprecated
String REQUESTED_URL = "pac4jRequestedUrl";
/** @deprecated */
@Deprecated
String USER_PROFILE = "pac4jUserProfile";

What's the rationale behind deprecating them? I don't have any problem with making the relevant equivalents configurable if the only reason for deprecation is to avoid hardcoded keys (but I will provide defaults) but if there are other reasons I could do with understanding them.

Thanks

[Jérôme LELEU]

Hi,

As we had more and more pac4j implementations, we realized we kept reusing the same constants everywhere in the code. So now, general constants are available in pac4j-core: https://github.com/pac4j/pac4j/blob/master/pac4j-core/src/main/java/org/pac4j/core/context/Pac4jConstants.java.

So we marked them deprecated just to remember we should switch from local constants to common ones.

Best regards,

Jérôme

[Jez P]

Perfect - thanks, I missed the new module :)