We are looking into creating a project that will allow several of our customers to log into a single Ignition project with each customer being able to view their own site data, administrate users and scheduling and receive alarm notifications. Typically our projects consist of setting up Ignition for a single customer at a single site, where security is not much of an issue as far as being able to view data, trends or alarms goes. This, however, will be much different. Each customer will have to have zero access to the data, alarms and schedules of another customer. Can anyone recommend any best practices on how to lay the foundation of such a project?
The customers have to be able to log into their own homepage and be completely unable to view the pages for other customers (security and roles?)
The customers have to be able to add or remove users specific to their company.
The customers have to be able to administrate alarm notification schedules specific to their company.
I am not asking anyone to write the application for me, but before I get into it I would like to have a better idea of what tools or ideas will best benefit me BEFORE starting to put things together, rather than finding out later and having to rebuild something.
I’m already pretty certain that the default internal User Source in Ignition would not be sufficient for this task. Would anyone recommend going with Database or Active Directory as a User Source? I think a lot of the project hinges on user administration over everything else, but any information would be helpful. Thanks in advance.
We are using Lightweight Directory Access Protocol (LDAP) for user authentication and assigning different roles for the user. You might consider using it as well to eliminate creation of user(as the accounts are handled by active directory) and for easy maintenance.
I not sure if you could separate out users enough in the AD tree to keep customers separate if they wish to administer their own users.
My thinking is that Database would be the way to go. Add one more column in the user and role tables to denote customer. You wouldn’t be able to use the User Management component, however. You would have to write your own.
I set up a project similar to this. All the customers use the exact same project, but customers are not able to see other customers’ data.
The simple stuff -
I used Database for the User Source and added an addition column to the user table called called CustomerID
All tags for a customer are stored under a folder, same name as the CustomerID
When a user logs in to the project, a script runs and gets that user’s CustomerID and stores the value in a Client Tag.
From there displaying tags, trends, alarms is pretty simple by prefacing everything with the CustomerID
The less than simple stuff -
User Management component - You’ll going to have to script this to only display users for that customer based on the CustomerID, add the CustomerID to the user database when new users are created, and filter out schedules based on the CustomerID
Alarm Notifications/Pipelines - You’ll need to make a separate alarm pipeline for each customer. I added a tag to each customer called AlarmPipeline that holds a string for which pipeline to use. Then all the tags reference the AlarmPipeline tag to know which pipeline to send the alarms too. Managing the alarm pipelines is the only manual work that has to be done, everything else is scripted.