Interesting Challenge or lack of platform understanding?

A developer approached me with an interesting question: " In a Domino web application I need to prevent the same user account being used simultaneously in different sessions". I found that question quite interesting and tried to make sense of it (which I couldn't, so I ask here):

It sounds like a question straight out of the eighties: Users must only logon to the application once.
Domino doesn't count user sessions, so licensing can't be an issue. If the web page has been transmitted no additional resources are consumed, so load factor can't be an issue.
A "session" in HTTP is identified by a successful login and can include multiple connections (different browser windows, retrieval of html, css, js, XML, images etc.). The only differentiator would be "login from a different location", which becomes difficult for users behind a shared NAT.

So I conclude: the request is not to allow sessions from the same userid from different places. My first gutt feeling is that an DSAPI filter would be required to achive something like that. Or what would you do?

Posted by Stephan H Wissel on 02 April 2009 | Comments (6) | categories: IBM - Lotus

posted by Andrei Kouvchinnikov on Thursday 02 April 2009 AD:
I think what he wants is to not allow the same user to open the application in multiple browser windows.
The easiest solution is probably to implement such control programmatically in the application itself. Create a profile for each user and then save sesson cookie from the first session and do not allow to open pages if user comes with another session cookie. Some solution to override the cookie after the first browser window is closed without logging out must be implemented.

posted by Jan Schulz on Thursday 02 April 2009 AD:
If thats the problem: put a JS on each page of that webapp, which has a counter, which calls login after doing 5 mins of nothing. Or setup your domino in that way (I would hat it...).

Anyway: I find that a rather stupid requirement: if user want to shoot themself in the foot by leaving their workplace unattended with an open session, you can't prevent it by such things.

If it is a technical problem (user can only be on one place), then a user like me (opens almost all links in new tabs, so that they are there when I've finished with this page; Using operas "back", which does not load the page again, etc) will drive them mad.

posted by Keith Brooks on Thursday 02 April 2009 AD:
I read this as a security issue. Why would I want multiple logins to a bank application for instance?

Also think of bank tellers or insurance agents or walmart checkout people. You don't want them logging in all as the same person.

posted by Stephan H. Wissel on Thursday 02 April 2009 AD:
@ Andre: AFAIK the browser windows share the session cookie (at least the tabs do), since you won't get prompted when you open a new window and navigate to the same database you just authenticated with

@Keith: Yes, for login at different workstations. No for multiple browser windows: I work on a e.g. loan proposal, my boss calls (from outside where she has no access) and wants some other information. So I want to switch to a new window.
Same at the teller: the customer walks back to get a missing item and the teller switches to a new window to serve other customers.
Emoticon smile.gif

stw

posted by Stephan H. Wissel on Friday 03 April 2009 AD:
@Warren: you nailed it " normally OS-based". Of course in a web2.0 environment one can't take an end-2-end control for granted any more, thus such requirements. Handling the identification using a DSAPI filter would remove the burden from the application, but would make the eventual scope too wide. I wonder if you could use a servlet-filter in XPages?
Emoticon smile.gif

posted by Warren Elsmore on Friday 03 April 2009 AD:
It sounds like a fairly common security restriction here (though normally OS-based). Only 1 concurrent login per user.

Source addresses won't work behind NAT firewalls, and what if the PC is a terminal server, or using multiple browsers etc etc?

I think you'd have to do it via a session based cookie - either a custom one, or manipulating the LTPA token. Really, you're looking at identifying a single browser. You'd have to issue the cookie at login - AND - revoke the cookie at logout, which would have to be manual or timed.

I don't think it would have to be done via DSAPI (we've done similar things to create Citrix cookies on the fly from Domino logins), but it would probably be the best idea. Thinking about it more, it's the sort of thing that really ought to be available out of the box.