Set UserAccessLevel Attribute

[kyleosha]

Hello,

The product I am working requires that security be enforced depending on what user is logged into our UA server. This all comes down to the write-ability of different points based on specific values held within our custom derived Session type. Currently we are using the beforeSetAttributeValue method to block writes for users with insufficient access; however, we would now like to use the userAccessLevel attribute to handle this security. In the past we have used the afterGetAttributeValue method in out node manager to modify an item's value depending on the session, but due to the userAccessLevel attribute being dynamically acquired (not stored) there is no way to change its value from within our manager directly.

The variables we are using derive from the OpcUa::BaseVariableType (being OpcUa::AnalogItemType, OpcUa::TwoStateDiscreteType, etc.). I know that if we derive our own type from the base type we can implement out own, session specific, version of userAccessLevel(Session* pSession) to dynamically determine the userAccessLevel. The only major problem here is that our other datatypes are already inheriting from that base type. This fix would require quite the workaround for just one attribute.

As you can see there are several solutions here. I'm curious if you folks have any solutions available that don't require us to re-derive 4-5 different datatypes just for the sake of one changed base method.

Thanks,

Kyle

[kyleosha]

I'm easily able to set the value of this attribute using the afterGetAttributeValue method in our node manger. The issue I have with this is that it doesn't block writes on points that are explicitly read only for the user; the userAccessLevel is still dynamically checked in the datatype's method userAccessLevel(Session*) (in this case to be the same as the accessLevel). To circumvent this issue I need to additionally block the write in beforeSetAttributeValue by checking the access of the user. This requires the calculation of user writes twice when all that should be required is one calculation for the user. Is re-deriving the datatypes we are using the only 1-time-check workaround available? If not, I guess that two checks is the only way we can implement this without modifying the provided datatypes.

[Support Team]

Hi,

There is no automatic rejection of the value access if you return different user access level in read. If you return session specific values for the UserAccessLevel in your code you must also check session specific access to the value.

With the next release of the C++ SDK there is a way to set a rights mask for nodes (like visible, read, write, call, history) for owner, group, others or for group1, group2, others. In addition, a session can be assigned to a list of groups based on the user. All of the access checks and also the values of the UserXxx Attributes will then be provided automatically by the SDK if this information is provided.

Best Regards,
Unified Automation Support Team

[kyleosha]

Fantastic! Thanks for the response. We will continue to use the methods on the manager side rather than the datatype specific methods for the time being. I look forward to experimenting with the group security feature you've mentioned (this will likely prove VERY useful to us).