Hm, this is interesting requirement. I woud look into actually to implement custom (or at least inherit from already used) authentication provider.

New resposnsibility for the auth provider would be to control state machine of currently logged in users. And prevent if user already has active session.

In general implementing this requirement you should keep in mind that sessions are killed a) when user logs out explicitly b) after timeout. Latter could be interesting to handle in cases if you just closed your browser and lost your cookie (let's say you browsed in private mode). Session I guess will still be alive for a moment. That could result in scenario when user is not able to login because session is "still dying"...

Btw, what is business value/goal behind this requirement?

I would not roll a new authentication provider. This is, in my opinion, not related to authentication. Authentication => Making sure you are who you say you are. Typically done by providing passwords or other secrets along with some user identity. Not saying authentication is irrelevant, but it's not the place. The logic I describe below must be implemented somewhere anyways, but an authentication provider is not the right place :-)

This can be handled in a few ways:

- If using MVC, you could override the OnAuthorization method in your controllers

- Or, which would work for both MVC and WebForms, you can do logic in one of the relevants events in Global.asax

- And when authenticating users (the login form, that is), you must also do some magic. ("if (username) is already online, login fails", for example)

In these places, you can keep track of who are online and when. Then implement some own logic to see if a user has timed out or is still online (i.e., you can say "this user is online since it's only been one minute since last activity"). Can be kept in memory (HTTP Cache, for example), or a database if a more rigid storage is required. If using the ASPNET MembershipProvider, you do have the "UserLastOnline"-thing somewhere, but I do not know when/how often this actually updates itself. 

You would also need to handle what happens if a user logs on on two devices at the same time. New device is closed off and kept out? "Old session" gets destroyed, and new device is logged in? Some sort of notification system between them?

Yeah, actualy to place logic somewhere in upper layer sounds more reasonable. This would not load additional responsobility for auth provider.

The business value of that feature is preventing lot of people using one paid access to some service.

Since this is not really relevant to Episerver, I believe good answers might just be found elsewhere on the internet. This should be a commonly solved problem nowadays. For example my top hit on Googleoverflow: http://stackoverflow.com/questions/15903574/when-the-same-user-id-is-trying-to-log-in-on-multiple-devices-how-do-i-kill-the might provide some inspiration :-)

Not without doing more research myself, nope.

However, implementing it using aspnet identity is probably a far better option that fiddling with the membership providers from 1992.