I’ve got a couple of feature requests / design questions.
We’ve been using the internally provided authentication but am getting requests for AD integration for a couple of different reasons. I do not want to be an IT administrator adding and removing users from groups myself. I also have a hard time working with IT to create groups for application specific roles so the hybrid model would work best for me. While I could use full AD but then I have to change a bunch of code to make Ignition aware of the AD groups and then manage that and I’d like to avoid that if possible and contain it in the Authentication config.
One problem I have with the hybrid is that it seems to require me to explicitly add every user account and map roles. I would love to be able to specify the group as a user and map Ignition roles to that. Then any user of that group also gets those roles.
I would also like to be able to remove roles from individual groups or users if they are inheriting those through this mechanism.
The next problem I have is LDAP sends passwords in clear text to the AD server. I strongly dislike that and would like to know if there is a LDAPv2 (SSL) or LDAPv3 (TLS) option here or perhaps for the future. I manage the Ignition server and don’t want the ability to capture user passwords because of something like this let alone a third party like a managed server provider after it leaves the machine (through VPN).
Also Single Sign-on for Windows clients would be nice too.
I can appreciate your idea for how the hybrid profile might work differently, but I’ve started to notice that everyone wants something different. I think you’re going to have to use it as is. Adding your own auth system using the module sdk isn’t too bad if you want to get your hands dirty.
I’ll look into the LDAPv3 stuff though, that seems important.
SSO requires some native hooks that are tricky to add for the client.
+1
Add me to this request. I would much rather IT handle the users and put them into groups. I’ll handle the group security and access in Ignition. Having an integrator or engineer manage users in a large installation is not a good option.
I think the full security model creates pain points in that assuming I can get our IT department to create and manage groups that I want. I will not have control over the naming convention they will impose which will lead to I will then have to rewrite anything in my code from the current roles to the new conventions. In practice changing the code isn’t too much work but would be nice to use the ignition names currently in use. The clear text issue is what is stopping me from going forward at the moment but I think we could partially workaround the snooping concerns with ssl tunnels if required.
Being able to “rename” these groups in Ignition config via a hybrid like role mapping would make it easier to migrate and maintain in the long term.