I'm trying to understand what the process is for saving user roles against an AD user. I have a fully fledged database model built out and tested for a Database user source that we've been using. Its very similar to what Ignition would built for you in "Automatic mode".
The docs are pretty unclear, but I'm trying to correlate AD users with database roles. For instance, say I have an AD user with username john.doe. From what I can see in the docs, it almost looks like you would do something like
user = system.user.getUser("my_AD_US", "john.doe")
user.addRole("Administrator") # <-- a DB user role
system.user.editUser("my_AD_US", user)
However, I don't see that role listed for that user in the gateway page. But this might be the wrong approach....
I have a database table to store users that I usually use for a Database user source. Do I need to create a new record in this table for an AD user (e.g. "john.doe") to then add a record into the userrolemapping table? This seems a little off, having to store the AD user in the DB user table to add a role mapping. However, if that's what needs to happen, that is what I'll do. Its just not clear how to proceed from reading the documentation.
Don't worry, I also found it difficult to understand authentication in my first time. I will explain you how we handle authentication in our organization, it should be similar for your use case:
We have SAML configured as authentication provider. In Azure, users are included in AD groups. These groups are maintained in Azure and have nothing to do with Ignition.
When the user authenticates through SAML, we attach the Azure Groups to which the user belongs in the SAML response. Subsequently, in ignition we create some “Security Levels”, which are basicaly "roles" and, aftewards, we map them to our Azure Group through “Security Level Rules”.
When the group to which a user belongs matches the logic you define in the security level rules, then automatically this user will be part of that security level / role.
You will then be able to create logics in the application to control who can access what.
It sounds like you're describing a pure-AD solution. I'm trying to get the AD/DB user source type to work with my pre-existing roles.
So, mapping an AD user john.doe with a database role called Administrator, since my large application is set up to use roles already for many features (e.g. populating a nav menu).
The user source is irrelevant. Just go to your "Security Levels" tree, under "Roles", add your pre-existing roles. Then, go to your "Security Level Rules" page and define the logic so you can match your user source roles with ignition's security level / roles.
Vision's classic auth doesn't use identity providers. Some users need fallback even in Perspective, which currently is only available when Ignition's internal identity provider points at a user source. The OP's question may not be solvable with security levels.
I'm about to have a project that may be having a similar issue as yours, but I was going to tackle it a different way. Our customer wants to use AD for all the roles (not hybrid), but the issue is that in Vision when using classic authentication, the roles are populated by the users group membership. The group membership doesn't align with our standard roles. For instance a group may be similar to "SG-PlantX-Administrator" or "SG-PlantY-Operator", but the roles in the standard gateway are just "Administrator" or "Operator" and are generic and not per-plant. So what I was planning on doing since role mapping isn't available was to create a script that on login strips all the excess prefixes off of the user's groups and writes those to a client tag, then instead of using hasRole, I'll have to check if the required role exists in the client tag.
If anyone has any suggestions otherwise, that's how I was planning to do it. Alternatively I may write a normal tag or something with the plant group prefix and just prepend it on all my hasRole calls, but that could possibly be more difficult to adapt.
Either way, I don't know if any of that will help you or if you're wanting to stick with database roles in a hybrid mode.