Session user management - was Re: [flow] session creation

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Hi:

There is another important request for flow. Some people ask for security
reasons (example banking software) to allow people only login from one
computer at once.

There are 2 scenarios:

1- You are logged in computer A, in order to log in computer B you need to
go to computer A and do a logout.

2-You are logged in computer A, if you log in computer B your session in
computer A automatically end.

In order to do this we need access to some global store of open sessions
to check if there is already a session for the given user.

I understand no everybody needs this but this will be soon or later a
request for many of us.

I know we already discused it sometime ago and there was no answer to
this. The only answer was a custom authentication subsystem.

Best Regards,

Antonio Gallardo

Re: Session user management - was Re: [flow] session creation

[Marc Portier <mp...@outerthought.org>]

Antonio Gallardo wrote:
> Hi:
> 
> There is another important request for flow. Some people ask for security
> reasons (example banking software) to allow people only login from one
> computer at once.
> 
> There are 2 scenarios:
> 
> 1- You are logged in computer A, in order to log in computer B you need to
> go to computer A and do a logout.
> 

The nature of the web gives you IMHO little to assume about the 
discipline of any user to be actively logging out (or on a 
technical level: the stability of his browser/OS for that 
matter)... so you'll be hitting session time-out wait periods 
with the first approach?

> 2-You are logged in computer A, if you log in computer B your session in
> computer A automatically end.
> 

Hm, I have to think about 'automatically end', the fact is that 
the client's browser on computer A will still have his session id 
and it will be used in the event of the next click...
The question is what would you want to have going on in that event?

> In order to do this we need access to some global store of open sessions
> to check if there is already a session for the given user.
> 
> I understand no everybody needs this but this will be soon or later a
> request for many of us.
> 

My associating mind might be way off topic here, but I couldn't 
help thinking the following:

there is a number of use cases I started thinking about while 
thinking wild about the generalized flow concept...


the whole idea of generalized flow almost boils down to snapping 
the essence of current flow from the POV of the sitemap:

AFAICS the sitemap sees 2 types of URI's (with respect to flow)

1/ URI's that identify a 'use-case' or 'set-of-interaction-steps' 
or maybe the word is even just: a 'flow' to be _started_ ...

consequence of this starting is that a URI of the second set is 
made available:

2/ URI's that identify one of those dynamically created, 
stateful, server side objects which are able to follow up or 
_continue_ the flow (next steps in the use case)

(the sitemap also has typically different matchers for these two 
kinds, and the subsequent split semantics between @function vs 
@continue on the map:call seem to assert my proposition)



now, when considering access control to URI's I'ld like to make 
the folowing observations:

1/ the world without continuations has left us to believe that 
the control of user -> role -> access -> uri can be mapped in a 
set of static ACL's
(well I might be off scale here, I just haven't ever seen 
anything else applied in my experience)

2/ however the second set of URI's (the dynamic ones) disclose 
the need for an access control that is oriented to 
use-case-instances rather then to use-case-types...


the compelling use cases I saw where the folowing
-1- classic-session-tied: the instance is only accessible from 
requests with the same session-id as the request that 
instantiated the instance

-2- classic-user-tied: the instance is accessible from requests 
with the same user-login (as stored in the session) --> this 
would allow for the same user to continue his interaction on 
computer B even if he started it on computer A (and yes, also 
pick up his interaction from the same computer in the event of a 
crash of his system)

-3- basic-plus-superuser-role: then the instance also becomes 
accessible for any user with super-power role...

above is the use case of help-desk-assisted form fill in (which I 
mentioned before): user X fills in form, needs help, calls to the 
helpdesk of the company providing the service, the helpdesk clerk 
steps in to continue the use case, user X just presses refresh on 
the 'echo and confirm page', thx for the help and agrees by 
submitting the final step


-4- basic-plus-enduser-control: the instance is accessible to the 
user that created it (strategy 2) and the use case itself allows 
him to add allow other users in

this last one would enable something like a chatroom

(which brings us to having locks an synchronizations in the show, 
but that is another lingering wild thought)


-5- yours-here: there must be more, but can't think of any at the 
moment


I do understand that all of this could be totally driven by 
storing the controling meta-data for these effects in the 
back-end itself
(IMHO deciding to do so however pushes these concerns up into the 
business tier, where they don't necessarily belong?)



> I know we already discused it sometime ago and there was no answer to
> this. The only answer was a custom authentication subsystem.
> 

missed that, any pointers to this discussion?

I'ld have to conclude also at this time that managing the access 
control to the 'instance' is indeed under the realm of the use 
case itself,

however, I do believe that there is a high likelyhood of having 
ONE strategy for all use cases in a given application and even 
that there are only a limited set of strategies 
conceivable/useful when considering the set of 'all' applications
(I'm aware of the contradiction between 'limited' and 'all' but I 
guess you know what I'm trying to see)

so while under control of the instance, I would find it logical 
that some delegation pattern would be used.


> Best Regards,
> 
> Antonio Gallardo
> 
> 
> 

Please understand that what is above are to be considered as wild 
thoughts (see Sylvain: not domesticated thoughts)
-- hoping they were not so wild that they couldn't be folowed 
(just ask to clarify on specific spots)
-- there is no other goal then to feed discussion first and 
hopefully ever domesticate these thoughts :-)
-- the long due future of which strategy's will be used and 
maintained will depend on which itches are felt by who IMHO
-- the decission of where/how to solidify the concern in the flow 
is probably subject to that long way future, however the stress 
on design is that the outcome is to be available a lot earlier...

up to us to manage the incremental iterations (and refactorings) 
towards the final goal

(I am nowhere near making a first draft, but hopefuly the 
interaction with other ideas will get us there)

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org