I saw a comment on an old post saying that, at the time, there was no way to restrict access to various tags of an OPC-UA server based on which user is connecting, but that this was planned for the near future. Does anybody know if this has been implemented?
My use case is that I need to provide restricted (only some tags) and read only access to the Ignition OPC-UA server, while allowing full access to another set of user credentials.
Thanks!
Access to tags from the âExposed Tagsâ functionality will take into account the user that the OPC UA client used to open the session, but there is no access control to any of the tags from any of the devices configured in the server.
Access to tags from the âExposed Tagsâ functionality will take into account the user that the OPC UA client used to open the session
Does this mean that if I set my tag to require the role 'Operator' for read permissions and the connecting OPC-UA user doesn't have that role, they won't be able to read the tag? Or do you mean something different by 'take into account' that I might have missed?
but there is no access control to any of the tags from any of the devices configured in the server.
Does this mean that if I have a DNP3 device set up with no tags configured, all users connecting to the OPC-UA server could operate the device by browsing through the tags that Ignition found during the integrity poll?
Yes, pretty much. Any permissions you have configured on tags in Ignition when Exposed Tags is enabled will be honored by the server. You'll probably need to start paying attention to which auth profile the server is configured to use.
Correct. There is no access control for anything under the Devices folder.
I don't think we'll be adding access control until after the server is updated to support OPC UA 1.04, which is a ways off because the stack/SDK we use still implements only 1.03, so I have to implement 1.04 there first.
Ah ok! Thanks for including that extra bit of information!
I think I might be onto a bit of a XY problem here. My real problem Iâm trying to solve is that in my industry (Power) thereâs always an expectation that a SCADA system is able to be polled for data by some upstream SCADA system and usually I have 2-4 of these per project to worry about. They rarely implement OPC-UA clients (and it sounds like even if they do, itâs not necessarily a good idea to give them access to ours when theyâll get control of DNP3 protection relays).
These conversations almost always start with the expectation that Iâll provide a modbus slave interface that they can read various internal SCADA signals off since they also only implement a master. The challenge is made more complex by the requirement to have redundancy for the slave, which rules out almost every protocol converter.
What do you see as the best way to achieve this? Iâm trying out Kepserver at the moment, but havenât got it working just yet - have you had a crack at this problem before?
When you say redundancy for the slave do you mean the slave or whatever is going to provide the data to upstream needs to somehow be aware of two Ignition gateways configured for redundancy?
I mean that the upstream device needs to have access to a slave to poll and that slave needs to be able to continue to respond to requests even if the physical device it is installed on dies (e.g. it would be installed on two devices with failover). The upstream device doesnât need to know about Ignition at all if the slave is sufficiently decoupled from Ignition.
I guess I need to raise the priority of my Modbus slave driver. /:
First customer over here!
Yeah, a Modbus slave driver (or module, doesnât necessary need to have anything to do with OPC UA) would work, as long as the upstream device can be configured with both IPs (primary/backup) and understand when it should failover and when to switch back.
Iâm going to strike up a chat with Phil via direct message to see what his plans are. Any ideas on what I could use as a fallback plan if a solution thatâs fully contained within Ignition isnât viable?
Even the original idea of using OPC UA doesnât work unless the upstream master understands redundancy and has its own failover logic. Not sure it matters what the transport/protocol is. Do you have more details about that?
As noted in my PM reply, my Ethernet/IP module already emulates a logix processor to external systems. Any other SCADA that has a Logix driver can monitor whatever you push into it from Ignition. A Modbus slave implementation is planned, but probably won't be very soon. End of year, perhaps.
Do you have more details about that?
Not really, unfortunately. I hadn't thought about how it would handle multiple IP addresses and I guess I couldn't really answer since I don't know how they've written their devices. In my head I was thinking of a floating IP address, but it didn't really occur to me until just now that Ignition has no real need for that concept without slaves (wait how does failover of the OPC-UA servers work? Does the connecting client have to handle that? edit: wait I think you just answered that above. I hadn't considered that before).
I think I'm making an assumption here that supporting failover would be their responsibility to figure out if there's no off the shelf product that can handle a floating IP.
Yes. Ignition's own loopback connection doesn't have to worry about it because it's just connecting back to localhost. Third party clients would have to handle this own their own.
Ignition redundancy is not transparent. Even Vision clients and Perspective sessions have to be aware that a backup server exists and what its address is and explicitly handle failover.
My Modbus Server module is getting close to reality... as noted over here:
Could you expose the required data through a web method?
We use the WebDev module for outside systems to gather data from the Ignition system.
@Kevin.Herron Curious if there are updates to this topic? What security methods are available to provide access to external tools but limit their read/write to specific tags or tag providers?
Role-based access control is coming in 8.3.
It's possible right now to have some control over read vs read-write access for tag providers if you configure the OPC UA server to use the same authentication profile that you use to configure permissions on all your tags.
This doesn't prevent the client from seeing that the tags and providers exist or from accessing device tags, though.
The RBAC in 8.3 will make it possible to do that.
thanks for quick response!
you're referring to the tag security levels and the grants given to users that authenticate to the system?
do service security profiles play a role here?