[aerogear-dev] [AG security] Handling mutliple login flows for the same user

[Bruno Oliveira]

Hi Sebi, not really. 

PicketLink was designed with the concept of Agents so is perfectly possible to attach to a single User multiple Agents or not. We've been discussing it for unified push.

In this scenario I'd like to enable/disable push notifications to an specific group of devices. Matthias already described some use cases here https://gist.github.com/abstractj/457b5cea09a23259159e, I'd appreciate if you could describe these scenarios.

Would you like to authenticate a single device? Multiple devices? What's your idea if a user try to login into multiple devices? Forbid login? Allow? 

Before we start to code, let's describe more detailed scenarios. At first glance a short answer would be, stick with Agents, but it might not be the correct answer to you.

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile



On Monday, March 18, 2013 at 8:08 AM, Sebastien Blanc wrote:

> Hi Folks,
> I started this thread to figure out how to handle a particular situation. 
> Currently when we log in into an application using ag-security-pl (and implicitly through picketlink) and the user was already logged in, we get a "UnexpectedCredentialException".
> The Aerogear Controller Demo, for example, handle this exception by displaying an error page telling : "user already logged in, maybe you should log out".
> 
> But I was really thinking of where relies the responsibility of handling this very common use case (the same is applicable for the "register" flow) : 
> I have user Bob who has his Device A and B using Application SlackerApp :
> 
> - He logs into SlackerApp with Device A.
> - While still logged in with Device A, he logs into SlackerApp with device B (for a concrete example think of Bob using twitter on his laptop when working and his mobile when he is at the bathroom).
> 
> In this situation, the log in flow for Device B will have to handle a UnexpectedCredentialException, I see 3 situations for handling this :
> 
> - SlackerApp handle the exception : - by swallowing it and returns a successful log in status, - throwing a error page (which can be strange for Bob who wants to use his app on device B) 
> - AG security handle the exception : - by swallowing it and returns a successful log in status, -throwing a http status
> - PicketLink handle the exception : - by swallowing it and returns a successful log in status, -throwing a http status
> 
> I'm just wondering what is the best way to handle this 
> 
> Seb
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev