Solved Seat license security (1 Viewer)

[Pat Hartman]

My initial preference was per named user but that is too hard to manage without a "phone home" ability so I am going with a fixed number of concurrent users. So, the first x people to log in get in. Everyone else gets a license not available error. If they need more concurrent users, they can buy more licenses. This can be easily managed with code in the application. I am not embedding the seat count in the license token. I am keeping the seat licenses separate so the client can add new ones at any time. But I am associating each seat with a token that is verified each time someone logs in. There will be an admin function that allows the admin to free up a license in case someone doesn't log out normally. I already have security code so I can modify that to include the seat license check each time a form is opened.

So a person logs in. The app finds the first license record with an empty login and updates the record with the new user.
If no empty license records exist, the user cannot log in.
The admin can remove the login id from a specific record to allow another user to log in. This opens up a security gap though because it doesn't force the original user to log out because, they might not even be logged in if the record is left locked due to a power outage or other invalid app closure. That leads us to the license check when each new form is opened.
When they buy a new seat license, a new record is added to the license table.
When the annual renewal happens, all license records are deleted and new ones are added.

 

[Solo712]

I really don't get it it, Pat. Is there a reason why you want to track the licenses individually, in preference to, say, issuing a single license to your client with a max number of concurrent users ? I have not seen anything in your posts that would indicate a need for such a system. There may be, if e.g. the front ends to the app are different but then of course you could not have the admin bumping the licenses in a like-for-like fashion. So where is license token "A" different from a token "B" such that you require that they be tracked individually? See what I am saying?
As for the "security gap" that you mentioned, again it does not justify issuing tokens and tracking them. You don't even have to have a manual refresh of the license count by an admin. If a number of permitted users is exhausted, and a new one wants to use the app, run a routine refreshing the logged-in user table, pinging them individually (via a WMI function). If a workstation in the table is unreachable, it decreases a license count because you may safely assume the user has logged out, even if for whatever reason he or she did not.

Best,
Jiri

 

[Pat Hartman]

My partner originally wanted to control the app features for each seat. I talked him out of that but hadn't gone all the way. He's reluctant to make them pay ahead of time for additional licenses. So if the additional licenses are separate, I can issue them for very short terms that will expire if they don't pay the invoice. That means I need to keep the seat licenses separate from the app license. I would have no way of making one expire but not the others if I don't keep a separate license per seat. If I can talk him into requiring up front payment for additional seats, then the simpler method of count is of course preferred.

 

[The_Doc_Man]

Jiri's response reminds me of a problem we had on another system where users were very loose about closing down their sessions. We had a license for a product called "SmartStar" (no longer in business) that was the CLUI and GUI for a back-end database. The O/S had a built-in method for tracking license usage for any product we registered as needing a per-user license. Since Windows NT was modeled after that O/S, I was surprised that when I went looking, there wasn't an "automatic" Windows system to track license consumption.

On this old system of mine, when a user would leave a session logged in for a while, particularly if they played a batch-style trick to keep a session open despite having a domain-imposed idle-session timeout, that license was dead to us. However, there were ways for me to tell that they didn't have an active session within the DB. So I started trimming sessions that were idle by a complex set of O/S calls, and the project manager agreed to it - because I was tracking license usage and this method cut license usage by 50%. It meant he didn't have to pay $32K extra per year for the next 100+ licenses. Doesn't do anyone any good in the Windows/Access environment except to note that the problem isn't unique. User - anywhere you see it - is still a four-letter word, to be spoken with vehemence equal to any OTHER strong four-letter words you might know.

 

[arnelgp]

My partner originally wanted to control the app features for each seat. I talked him out of that but hadn't gone all the way. He's reluctant to make them pay ahead of time for additional licenses.

MS Access/VBA being licensed? Talk about love of money!

 

[Pat Hartman]

We don't sell to the general public. We sell to large corporations. Don't make fun of it. They pay well