Web-Interface for Keystore Server

[msf]

We run several floating licenses and sometimes run into the problem that all licenses are gone and we just want to know which team mate we should ask to log out during lunch time.

I have seen a workaround here to scan the logfile but this is not a commom solution since the logfile is on dedicated sealed server.

I suggest to implment a web-interface either for the complete administration (with a usage view first) or a dedicated license-in-use webpage on the server which allows any remote user to check the license state (other tools have choosen that options).

Thanks,

[Eve]

It's not a web interface, but the current keystore manager (part of the keystore installation) allows you to connect to multiple keystores and see the current usage of each key type, including who currently has the key.

[msf]

Sure, but you need access to the server for running it - which is sometimes not possible due to separation of concerns.

[Eve]

You can install the manager separately to the service (ie. On a user machine) and the manager can then connect to the service using the same protocol that EA uses.

[zapurvis]

I do not want to hijack this thread but I agree.  We need an interface to see who exactly has the licenses and be able to drop them on the fly.  Presently there is no way to say for a particular person, how long they had the key.  If we know they had it for days, it would be nice to kick them out so others can obtain a license.

Maybe when dropped the EAP and all local changes saved upon the drop?

Zak

[Eve]

I do not want to hijack this thread but I agree.  We need an interface to see who exactly has the licenses and be able to drop them on the fly.  Presently there is no way to say for a particular person, how long they had the key.  If we know they had it for days, it would be nice to kick them out so others can obtain a license.

The keystore manager shows who has a key, and when that key expires. (Which is when they got it plus the global setting for expiry duration)

I can see that a http based interface would be nice to have so you don't have to install the manager, but all the desired functionality of that interface is available already.

[Glassboy]

I do not want to hijack this thread but I agree.  We need an interface to see who exactly has the licenses and be able to drop them on the fly.  Presently there is no way to say for a particular person, how long they had the key.  If we know they had it for days, it would be nice to kick them out so others can obtain a license.

The keystore manager shows who has a key, and when that key expires. (Which is when they got it plus the global setting for expiry duration)

I can see that a http based interface would be nice to have so you don't have to install the manager, but all the desired functionality of that interface is available already.

I agree with you that the functionality is available but in large locked down corporate environments it is often near impossible to be able to use the tool.  I've had to rely on friendly third party sysadmins who would rdp to the server and run the tool for me.  Competing tools have repository and key management functions in the client which is useful as during the initial implementation  generally all the network plumbing has been sorted out.

[skiwi]

Indeed. Corporate scenario:

• have Keystore manager Whitelisted ($$)
• have Keystore manager Installed ($)
• use keystore manager to view usage history 

[Geert Bellekens]

I do not want to hijack this thread but I agree.  We need an interface to see who exactly has the licenses and be able to drop them on the fly.  Presently there is no way to say for a particular person, how long they had the key.  If we know they had it for days, it would be nice to kick them out so others can obtain a license.

The keystore manager shows who has a key, and when that key expires. (Which is when they got it plus the global setting for expiry duration)

I can see that a http based interface would be nice to have so you don't have to install the manager, but all the desired functionality of that interface is available already.

I agree with you that the functionality is available but in large locked down corporate environments it is often near impossible to be able to use the tool.  I've had to rely on friendly third party sysadmins who would rdp to the server and run the tool for me.  Competing tools have repository and key management functions in the client which is useful as during the initial implementation  generally all the network plumbing has been sorted out.

I would rather see Sparx working on real improvements and bug fixes then building something we already have. If the corporate policy is broken maybe you should try to get that fixed rather then expecting Sparx to provide a workaround.

Geert

[Glassboy]

I would rather see Sparx working on real improvements and bug fixes then building something we already have. If the corporate policy is broken maybe you should try to get that fixed rather then expecting Sparx to provide a workaround.

The corporate policy isn't broken.  The sad fact is that most development type tools aren't built to be deployed in secure environments.  The world needs more secure environments, more than it needs a new niche feature in a niche piece of software.

And I think if you look at the type of questions that are asked regularly there is a real need for a back end component that allows a user to manage the keys and allows regular exports or synchronization of repositories. In edition to the questions here, these are features that competing products have, which speak to the demand for them.

In fact the competing product that I'm now using more allows me to check out a licence to my laptop and not have to worry about how I can have a network connection to the keystore before I run the client.  It's a lovely feature and makes my life a lot easier.

[skiwi]

In fact the competing product that I'm now using more allows me to check out a licence to my laptop and not have to worry about how I can have a network connection to the keystore before I run the client.  It's a lovely feature and makes my life a lot easier.

+1

[Uffe]

In fact the competing product that I'm now using more allows me to check out a licence to my laptop and not have to worry about how I can have a network connection to the keystore before I run the client.  It's a lovely feature and makes my life a lot easier.

You can achieve this with an EA keystore, by setting it up without auto checkin. Of course, you then need two keystores, one with auto-checkin and one without, or you defeat the purpose of having floating licenses in the first place. Which means you either have to get your users to select the right keystore in the right circumstances, or do some behind-the-scenes deployment magic.

As for checking license usage using the keystore manager, weeeell... In order to connect to the keystore using the manager, it seems you need to be a license administrator, or possibly it's enough not to be in the SSKSAnonymous group (I'm using the AD configuration option). Otherwise, you get a count of the total number of keys in the store but that's it. ("ERROR: Requested operation requires authenticated session" when connecting.)

It's not a web interface, but the current keystore manager (part of the keystore installation) allows you to connect to multiple keystores and see the current usage of each key type, including who currently has the key.

Can you confirm that that actually works when using the AD configuration option with an AD-linked group for admins, an SSKSAnonymous group for regular users, and connecting with a user who's not in the AD admin group? I'm on EA 11 here, so the above issue might have been fixed.

/Uffe

[Glassboy]

In fact the competing product that I'm now using more allows me to check out a licence to my laptop and not have to worry about how I can have a network connection to the keystore before I run the client.  It's a lovely feature and makes my life a lot easier.

You can achieve this with an EA keystore, by setting it up without auto checkin. Of course, you then need two keystores, one with auto-checkin and one without, or you defeat the purpose of having floating licenses in the first place. Which means you either have to get your users to select the right keystore in the right circumstances, or do some behind-the-scenes deployment magic.

The other product also allows me to manage the repository and the licenses from the client.  The project to deploy the tool in our secure managed environment was far simpler that the projects to deploy SparxEA have been.  There was one msi to hand over for packaging.  One set of firewall rules.  One server deployment.  No mucking around pulling a msi out of an .exe.  No checking whether the .msi needs a transform to install properly.  No writing support and hand over documents for the person with access to the server where the keystore manager is installed.

The other problem is financial.  If you have infrastructure as a service, you have the monthly cost for a server that is basically doing nothing.  The last deployment of Sparx EA I did I actually gathered together a number of products that had similar licence servers so the server costs were spread across the entire organisation and so we had the opex for DR.