This may require an iRule. It would certainly need to use the VPE "iRule Event" agent because this event fires before the policy concludes and you have a chance to end it with an "allow" or "deny".
The iRule Event Agent Raises the iRule ACCESS_POLICY_AGENT_EVENT event for use with custom iRules. The iRule would look up the username in an iRule "Table" using the "table" commands. If the user exists, the iRule sets a session variable to "0", if the username is not in the table, a new table record is created and variable is set to "1". Only challenge here is the record cleanup. When a user session ends for any reason, you will have to remove the record. This means that you have to remove the record when the ACCESS_SESSION_CLOSED event fires for any reason, this includes user logout as well as session timeout.
ACCESS_SESSION_CLOSED - This event is triggered when a user session is removed due to a user logging out explicitly. timeout or if terminated explicitly by admin.
I would recommend that you store the session id in the table record indexed (keyed) by the username. This way, if a username is found, you verify that a session is valid before denying the logon.
When a username is found, the iRule event sets a session variable to "0". In the VPE, after the iRule Event, you can check the variable and if it is "0" you deny.
You may want to consider raising the iRule event after the Authentication. This ensures that not anyone can snoop in to find out whether or not a particular user is logged in. In other words, you run irule event after user "john" is authenticated, only user "john" can find out if a session already exists.
There are examples here on DC that cover most of what I mentioned here. If you have problems finding them POST back here and we can include examples.
HTH.
Nimbostratus