FWD » Core Development » Runtime Infrastructure

A customer has requested the ability to set a maximum limit on the total number of simultaneous users on the FWD server. They have also requested a way to set the maximum number of sessions per user.

These should be settings in the directory.

I'm only implementing these limits for interactive users. Process accounts, web/REST sessions, related threads and so forth should not get these limits checked.

I plan to protect SecurityManager.authenticateLocal() and SecurityManager.authenticateSingle(). I don't think we can get an interactive session except though those methods.

Constantin: Can you see any flaw in my reasoning?

3821c revision 12981 includes the following changes:

Added support for setting a maximum number of simultaneous interactive user accounts (integer value in /security/config/maxusers, -1 means unlimited which is the default) and for setting the maximum number of simultaneous interactive user sessions per account (integer value in /security/config/maxusersessions, -1 means unlimited which is the default). When no configured there is no difference in behavior. Even when configured this does not affect process accounts or any non-interactive accounts. maxusers set to 2 means that if accounts A and B are both logged in (at least once but maybe more than once), account C will not be allowed to login until either account A or B have no live interactive sessions. maxusersessions means that each individual account may have mausersessions number of simultaneous logins. maxusersessions of 4 means that up to 4 simultaneous logins for account A will work but a 5th login for A will not work until at least one of the existing 4 logins was ended.

The following is an example of the configuration:

        <node class="integer" name="maxusersessions">
          <node-attribute name="value" value="3"/>
        </node>
        <node class="integer" name="maxusers">
          <node-attribute name="value" value="5"/>
        </node>        

The values can be specified independently or together.

Due to the way we implement virtual desktop logins, we need 2 user accounts to login properly. We use a "temporary" account to connect the server during the spawning process and then we open a new "permanent" account session. These are different accounts. This means if we set maxusers to 1, virtual desktop mode will not work. A regular Swing client and web client in embedded mode will both work with maxusers set to 1.

There is one other issue with this implementation: we do not display a useful error to the user when the session is rejected due to one of these user limits. The reason is that we currently have no architected method for returning that authentication failure to the web client login page (which is gone by the time failure occurs) or even to the Swing client since there is no FWD-based login dialog there. Until we create a solution for this, the only indication will be in the server log.