# User based security for OPC-UA server **URL:** \ **Category:** Ignition\ **Created:** [September 12, 2020, 5:43pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621 "2020-09-12T17:43:00Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![BenKearney](https://avatars.discourse-cdn.com/v4/letter/b/b19c9b/32.png) [@BenKearney](https://forum.inductiveautomation.com/u/BenKearney)\ **Post date:** [September 12, 2020, 5:43pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/1 "2020-09-12T17:43:00Z")
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! ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 12, 2020, 5:50pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/2 "2020-09-12T17:50:16Z")
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. ---
**Author:** ![BenKearney](https://avatars.discourse-cdn.com/v4/letter/b/b19c9b/32.png) [@BenKearney](https://forum.inductiveautomation.com/u/BenKearney)\ **Post date:** [September 12, 2020, 5:54pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/3 "2020-09-12T17:54:39Z")
> 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? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 12, 2020, 5:59pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/4 "2020-09-12T17:59:22Z")
> [@BenKearney](#): > > 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? 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. > [@BenKearney](#): > > 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? 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. ---
**Author:** ![BenKearney](https://avatars.discourse-cdn.com/v4/letter/b/b19c9b/32.png) [@BenKearney](https://forum.inductiveautomation.com/u/BenKearney)\ **Post date:** [September 12, 2020, 6:06pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/5 "2020-09-12T18:06:49Z")
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? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 12, 2020, 6:09pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/6 "2020-09-12T18:09:53Z")
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? ---
**Author:** ![BenKearney](https://avatars.discourse-cdn.com/v4/letter/b/b19c9b/32.png) [@BenKearney](https://forum.inductiveautomation.com/u/BenKearney)\ **Post date:** [September 12, 2020, 6:11pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/7 "2020-09-12T18:11:28Z")
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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 12, 2020, 6:13pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/8 "2020-09-12T18:13:06Z")
I guess I need to raise the priority of my Modbus slave driver. /: ---
**Author:** ![BenKearney](https://avatars.discourse-cdn.com/v4/letter/b/b19c9b/32.png) [@BenKearney](https://forum.inductiveautomation.com/u/BenKearney)\ **Post date:** [September 12, 2020, 6:13pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/9 "2020-09-12T18:13:40Z")
First customer over here! ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 12, 2020, 6:14pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/10 "2020-09-12T18:14:49Z")
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. ---
**Author:** ![BenKearney](https://avatars.discourse-cdn.com/v4/letter/b/b19c9b/32.png) [@BenKearney](https://forum.inductiveautomation.com/u/BenKearney)\ **Post date:** [September 12, 2020, 6:19pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/11 "2020-09-12T18:19:50Z")
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? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 12, 2020, 6:32pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/12 "2020-09-12T18:32:45Z")
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? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 12, 2020, 6:39pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/13 "2020-09-12T18:39:04Z")
> [@BenKearney](#): > > Any ideas on what I could use as a fallback plan 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. ---
**Author:** ![BenKearney](https://avatars.discourse-cdn.com/v4/letter/b/b19c9b/32.png) [@BenKearney](https://forum.inductiveautomation.com/u/BenKearney)\ **Post date:** [September 12, 2020, 7:09pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/14 "2020-09-12T19:09:31Z")
> 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. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 12, 2020, 7:14pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/15 "2020-09-12T19:14:50Z")
> [@BenKearney](#): > > wait how does failover of the OPC-UA servers work? Does the connecting client have to handle that? 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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 17, 2020, 3:31pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/16 "2020-11-17T15:31:51Z")
My Modbus Server module is getting close to reality... as noted over here: > [@Connecting to SAP with 3rd party Python lib or SAP JCo jar](http://forum.inductiveautomation.com/t/connecting-to-sap-with-3rd-party-python-lib-or-sap-jco-jar/40712/7): > > I’ve mentioned it a few times around here, but it implements the server (slave) side of the Modbus protocol so that other masters can connect to Ignition. It supports simultaneous Modbus TCP, Modbus Serial RTU, and Modbus RTU over TCP connections to the configured virtual device. Within the virtual device, multiple units are supported, each with their own data format setttings (word swapping, etc) and configurable ranges of bits and registers to expose. It also supports a configurable number… ---
**Author:** ![MMaynard](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mmaynard/32/3366_2.png) [@MMaynard](https://forum.inductiveautomation.com/u/MMaynard)\ **Post date:** [November 17, 2020, 7:03pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/17 "2020-11-17T19:03:57Z")
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. ---
**Author:** ![wdougmiller](https://avatars.discourse-cdn.com/v4/letter/w/a9a28c/32.png) [@wdougmiller](https://forum.inductiveautomation.com/u/wdougmiller)\ **Post date:** [September 10, 2024, 2:53pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/18 "2024-09-10T14:53:44Z")
@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? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 10, 2024, 2:58pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/19 "2024-09-10T14:58:22Z")
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. ---
**Author:** ![wdougmiller](https://avatars.discourse-cdn.com/v4/letter/w/a9a28c/32.png) [@wdougmiller](https://forum.inductiveautomation.com/u/wdougmiller)\ **Post date:** [September 10, 2024, 3:06pm UTC](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621/20 "2024-09-10T15:06:24Z")
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? [Next page](https://forum.inductiveautomation.com/t/user-based-security-for-opc-ua-server/38621.md?page=2)