Login / Logout / Session support with Vert.x

[Arik Bron]

Hi,

Following successful deployment on Vert.x cluster into AWS we're moving into implementing authentication / authorization of users.

I would appreciate any recommendations on that matter from community members that successfully developed this layer based on Vert.x:

1) What packages to use,

2) What to read to better understand the ins and outs of the underlying tools,

3) Any practical hints and tweaks on making the implementation robust and fast.

Thanks!!!

[Klausen Schaefersinho]

Hi,

Vertx comes with a bunch of Auth providers out of the box. Have a look at:

http://vertx.io/docs/

You can access the user in a vertx-web handler then like

routingContext.user()
     
To logout call

routingContext.clearUser();


The default way of implementing authorization by calling :

user.isAuthorised("newsletter:edit:13", res -> { 
  if (res.succeeded()) 
  { 
    boolean hasPermission = res.result(); 
  } else { 
     // Failed to 
  } 
});

If you use the Shiro authprovider you can use somehow Apache Shiro. If you don't your user 
object has to parse the string (e.g. newsletter:edit:13) and execute the business logic.

I found it a little cumbersome to parse Strings and I didn't want to use Shiro, so I implemented my own kind 
Authorization Objects. Basically its a kind of chain of responsibility. First object checks the user for the role, 
the second checks some kind of ACL.

I can share the code with you, but it's quite specific to my solution, so most likely it won't be useful.

Cheers,

Klaus

[Jez P]

Also you can use any auth client supported by Pac4j via vertx-pac4j

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

[Arik Bron]

Thanks for responses guys,

Yet, starting from examples is very frustrating - they are incomplete, partial and not clear.

For instance:

1) I see no expiration data in the Session object,

2) I see no place to store Session data on the User object,

3) It's not clear at all what FormLoginHandler does with the data it parses - where does it put it (I assume on the RoutingContext somewhere...)

[Jez P]

What kind of session data would you want to add to the user object, and why? I'm not sure I understand your use-case on that, since to me the session is distinct from the current user. 

[Arkady Bron]

Regarding saving Session with the User: In order to support only 1 user's login (session) at any given time (no allow log in from more than 1 device) you need to manage relationship between the last log in session and the user. With such implementation session (ID) must be persisted to wherever user is persisted to (presumably DB).

Another thing - examples tell to use FormLoginHandler:

router.route("/login").handler(FormLoginHandler.create(authProvider));

I am using Jquery AJAX POSTs to send form content to Vert.x:

$.ajax({

type: "POST",

url: "https://test.com/login",

data: dataString,

success: function () {

...

FormLoginHandler fails to parse content of such a request. The only way that worked for me to process this request was to implement a custom handler that expects for "application/x-www-form-urlencoded" Content-Type.

So for me the flow: CookieHandler -> BodyHandler -> SessionHandler -> UserSessionHandler -> FormLoginHandler -> RedirectAuthHandler is not working.

Moreover, it's completely not clear how other Handler that receive AuthProvider in their constructors, work with the AuthProvider. I.e.:

UserSessionHandler.create(authProvider)

What the UserSessionHandler does with AuthProvider? How it calls it? UserSessionHandler's interface doesn't expose a method to retrieve the AuthProvider implementation and to work with it...

--
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/bLPiNHGvU14/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/1d81b23d-6a30-42c1-8625-e138160c1de5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jez P]

Thanks for the clarification: to me that means that you will need to use a custom auth provider and user if you absolutely must persist with the user, though I'm not convinced you need to go down that route. 

You could use shared data rather than DB to manage the fact that the user's already logged in and use the user id as part of the key into the shared data which would avoid you needing to make the session id part of the user (to me the two are separate, to me the user is relatively static data, the current session id is relatively transient). The reason I think this way is because when editing user information, you wouldn't expect to read back the current session id as part of that entity, so it's not really part of the user model.

[Jez P]

Regarding the rest of your stuff, I suggest sharing a simple project which demos it and maybe the vertx-web guys will have some opinions.