- Revenera Community
- :
- FlexNet Embedded
- :
- FlexNet Embedded Forum
- :
- Re: How do YOU hand over flexnetls to the customer?
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
How do YOU hand over flexnetls to the customer?
We consider moving from node locked licenses to a solution where licenses are checked out from a local license server.
This means a bit of new territory for us: Currently the user just has to install our application, import a license file and done. With additionally requiring a flexnet license server running on the customers network, there is probably some involvement of the customers IT department required to set up a server, open ports, configure firewall etc.
So I am looking for some other users to share how they hand over the flexnet license server?
I guess on one end of the spectrum is to just zip up the files mentioned in the flexnetls user guide and give it to the customer and let them read and follow the admin guide. On the other end is setting up the license server for them, or providing a Container or VM image to them that they just need to spin up.
(Note: The easiest way - using the Cloud Licensing Service - is unfortunately not an option for us because some customers operate our applications in offline networks)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
In general, the more control you have over the license server, the more 'secure' your licensing infrastructure can be made meaning that it would be more difficult to misuse your license enforcements with actions such as license cloning for example. If a license server is compromised it wouldn't be limited to a single license but a whole license pool which obviously bears some risk.
If you provide the license server as a complete product, you will have control over the host-id, could take additional measures such as hardening your host-id (i.e. by means of TPM or a ID dongle) and would be able to enforce actions such as synchronizing the license server's usage history for detection of anomalies. By comparison if you provide your license server as a vm-image or container, enforcing that the license server can only be run one specific hardware would be difficult as vm's or dockers naturally do not come with a uncloneable identifier that could be used as the host-id.
Customers might not accept getting a .zip-File and undergoing the cumbersome task of setting up the license server by themselves after going through different administration and setup guides. Customers might not accept installing / buying additional software / hardware to use as a license server. You might not accept providing them a vm-image / docker container that could effectively be used on any hardware as you would not be in control over the secure host-id.
In the end it will be a tradeoff between the level of security you want to achieve, the trust you have (or agreed upon) with your customers, the comfort you want to provide for them and the development effort / time you are willing to make.
We are currently facing a similar problem and investigate into the possibility to make a license server product as we cannot guarantee that our customers will be online and have a connection to a CLS all the time. However some customers might not accept additional hardware and therefore we might also need to go for the CLS ... so in the end we think that it we might need to install both solutions and have to think about how to make both as secure as possible and at the same time make flaoting licenses easy / comfortable to use for customers.
Out of curiosity - why do you want to move from node-locked licensing to floating licenses? What's your current use-case for using node-locked and what would be the use-cases that require floating licenses?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
@TrinityTonic wrote:[...]
Out of curiosity - why do you want to move from node-locked licensing to floating licenses? What's your current use-case for using node-locked and what would be the use-cases that require floating licenses?
The reason for us to evaluate a license server based option are:
- Currently we use node-locked with a smart card based dongle as secure host ID source. So its node-locked to the dongle, which allows the customer to move his entitlements from one machine to another by physically moving the dongle (we permit that). However using the smart card based dongle has some limitations: Using a remote desktop connection to the machine that uses our licenses application is not possible, because Windows deactivates the local smart card on connection.
- And the other reason is, our application regularly checks whether the dongle is still present, however sometimes when our application does some number crunching, the IO to the dongle is blocked and then the application goes into a restricted mode (and the current operation is stopped). This can be very annoying to the user.
- And finally its also a logistical thing: the dongle needs to be shipped to the customer. Sometimes they loose it, and we need to provide a replacement which means re-issuing of licenses and a whole rat tail of administration to do.
Over time we found that the level of security that the dongle provides is nice, but maybe a bit too much and we are willing to make a trade-off now.
However just getting rid of the dongle and instead using a MAC address or similar as host ID source is also not so practical because this restricts the customer of using the application on multiple machines (we want to allow that; just not on multiple machines at the same time). And it feels its too easy to clone licenses with that.
Hence we look into the license server option with floating licenses now. It allows the customer to easily move his entitlements from one machine to another. And it seems to provide a reasonable level of security through the capability requests/response so we can at least somewhat ensure that licenses are returned.