HTTP API: Admin password needed

Maybe I’m a bit off the track, but here’s a thing we were pondering about.

We would like to create a plug-in which, among other things, adds a new channel to the Iguana instance. We already found out that it can be done using the HTTP API.

But: Which user should we use to call the API? To add a channel, he probably needs Iguana admin rights. Here are my ideas how it could be solved:

• The customer must provide an admin password when installing a plug-in. But they would wonder: I’m already calling this plug-in installer as system admin, why do I need even more credentials? And where do I have the admin password that I chose two years ago and never needed since?
• When deploying Iguana, we add a special plug-in installer user with a password known only to us. But: The customer might have deleted this user or changed his password. What then? Also, since the HTTP query passes the credentials in clear text, this might be a security risk that the password might be snooped.
• When installing a plug-in, we could stop Iguana, add manually to IguanaConfiguration.xml a throw-away admin user only for the plug-in, start Iguana, call the HTTP API with this throw-away user to add the channel, then (optionally) stop Iguana again, remove the user, start it again. But: A lot of starting and stopping involved here.

Are there any other possibilities I have missed? Of course other than manipulating the Fossil database directly.

Somehow, I can’t help but feel this is not the way we were supposed to be working…

Kind regards,

Robin

Seems reasonable that to modify an Iguana installation that a login is needed?

Another approach would be to have the user login like the channel manager with their username and password and see if they have the permissions to do the changes.

Yes, of course! I’m not suggesting you open the HTTP API to everybody.
It’s just that I’m wondering how to include the login data in a plug-in installer.

One idea is to follow the second path: The password would be saved in the plug-in in encrypted form. If the login fails (because the user has been deleted or his password changed), I can prompt the user for Iguana login data (or fall back to the third path: stop the service and re-add the plug-in installer user).

Ah okay – that should work.

I’m afraid I don’t understand your proposal that the user logs in like the channel manager… Can you give me a hint?

Have you tried using the channel manager? The latest version requires you to login to it to use it. It takes the user name and password and just calls a HTTP API of Iguana to validate if the login was correct.

So the same approach can be used for your updater – it is reasonable to expect the person running the installer to have the Admin user name and password – otherwise they shouldn’t be running a program which can modify the Iguana installation.

To re-phrase.

Only a person who knows the Administrator password should be able to run this installer. So it should ask for it.

If a customer forgets their Administrator password (this does happen) then this is separate problem which I think probably deserves another procedure.

I’m sorry, but it looks like we see things a bit differently. We don’t want the customer to have the admin password, because he should not be able to see or manipulate the Lua code. After all, it’s a regulated medical product, and I guess the FDA would not like this.

Of course, given that the customer has admin rights on his machine, he could always reset the admin password, but we would not make it too easy, either.

On the other hand, it would be nice if he could install a plug-in without the help of a service technician. Hence my question.

Ah okay so in this context the customer doesn’t have real access to Iguana. So just don’t give them the admin password for Iguana. If they tamper with Iguana then it’s just the same if they tampered with any other part of your software.

So it should be easy to lock it down. You could even use the global monitor as a starting point to monitor these Iguana instances and make sure your customers do not tamper with those machines. The global monitor actually gives you a starting point for being able to administer and upgrade those machines remotely … although depending on issues with PHI, what your customers will tolerate etc. this may not be something you can do in your business… technically quite possible though.