OPC Security specification is defined by OPC Foundation to protect sensitive information from unauthorized access.
The main goal of this entry is to introduce the basic security concepts as well as describing how the security is implemented on both OPC Server and OPC Client levels to ensure secure communication.
1. What means «Authentication»?
It’s the process of controlling the eligibility of a user to access an object.
2. What means «Authorization»?
It’s the process of determining what types of activities are permitted to a given user.
3. What is the relationship between «Authentication» and «Authorization»?
We introduce the authorization in the context of authentication. In fact, once the user is authenticated, he may be authorized to different types of access or activities.
4. What is the goal of the OPC Security specification?
This specification focuses on the client identification that consists in the exchange of trusted credentials to be used by the OPC Server for access authorization decisions. It does not address which objects to be secured. It leaves this matter to the OPC Server implementers.
5. What are the possible OPC Server security levels?
There are three security levels that can be implemented by an OPC Server:
- Disabled Security: No security is applied in this case. Launch and Access permissions to the OPC Server are given to everyone (for client to server communication), and Access permissions for clients are set to everyone (for server to client communication).
No control of the access to any vendor specific secured object is applied by the OPC Server.
In this case, an OPC Client without any security implementation can connect to the OPC Server.
- DCOM Security: Only NT DCOM security is applied in this case. Launch and Access permissions to the OPC Server are limited to selected clients, as are the Access permissions for client applications.
No access control of any vendor specific secured object is applied by the OPC Server.
In this case, an OPC Client without any security implementation can connect to the OPC Server.
- OPC Security: In this case, the OPC Server provides a control of the access to vendor specific security objects that are exposed by the OPC Server. An OPC Server may implement OPC Security in addition to DCOM Security, or implement OPC Security alone.
In this case, and according to the security model implemented by the OPC Server:
- For the NT credential security model, an OPC Client without any security implementation can connect to the OPC Server.
- For the private credential security model, an OPC Client without any security implementation can connect to the OPC Server but will receive access denied when trying to access to any secured objects.
6. What are the possible security modes that can be implemented by an OPC Server?
The principal security mode that should be implemented by an OPC Server is the NT security (handled by IOPCSecurityNT interface) mode where the security is based on the access authorization of the NT Access Token associated with the client application. This approach allows security to be transparent to client applications and ensure the portability of the client applications (There is no special action in the OPC Server side).
However there are some situations where this mode cannot be used such as:
- The machine hosting the OPC Server does not support an NT operating system such Windows CE and UNIX
- The machine hosting the OPC Client does not support the NT Access Token
- The machines hosting the OPC Server and the OPC Client are outside the context of an NT Domain.
To address such situations, the OPC Server can implement the private credential security mode (handled by the IOPCSecurityPrivate interface).
If you have questions not shown in the list above, please do not hesitate to send them to my email: hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
mardi 20 février 2007
jeudi 8 février 2007
OPC Miscellaneous
After I briefly overviewed the most known OPC specifications, I would like to give you an idea about important OPC miscellaneous that will be frequently used in the coming blogs.
What are the OPC Servers types?
There are two types of OPC Servers: in-process and out-process servers.
In-process servers are written in form of a Dynamic Link Library (DLL) loaded in the OPC Client’s process space.
Thus, each OPC Client application manages its own Server instance.
Whereas, out-process servers are standalone applications. Therefore, an out-process server is written in form of an executable. It can be launched by any OPC Client locally or remotely. In multiple OPC connections, all OPC Clients connect to the same instance of the OPC Server’s application. This allows OPC Server application to share data between all its OPC Clients.
In-process servers are better than out-process servers in term of speed and performance.
How OPC components communicate locally and remotely?
OPC components can communicate on the same machine through LPC (Local Procedure Call).
They can also communicate on distributed computers using RPC (Remote Procedure Call).
How can the OPC Server be launched?
An OPC Server can be launched as an executable or run on background as Windows service.
Like any service, the OPC Server’s service can be managed (start, stop, pause) from the Service Control Manager (SCM).
What do you mean by DCOMCNFG?
Microsoft offers a Windows built-in tool called DCOMCNFG used to define DCOM settings for COM applications.
You can launch it by typing dcomcnfg on Start | Run.
DCOMCNFG window is mainly composed of the following tabs:
- Default Properties: to enable/disable DCOM and set the default communication properties for DCOM (authentication level and impersonation level). The authentication level specifies if the authentication of the caller is requested. If it is the case, you have to set the permission to honor (authentication only at the connection step, at every call, etc).
The impersonation level specifies whether the applications can determine who is calling them; and in which manner the identity of the caller is used.
- Default COM Security: to set permissions for the users that can access COM applications and those who can launch them.
- Default Protocols: to order by priority the network protocol to be used by DCOM. "Connection-oriented TCP/IP" is the default setting.
Using DCOMCNFG, you can either set a general configuration to be applied to all COM applications installed on the local machine or define custom configuration for a specific application.
In Windows XP, DCOMCNFG window layout differs a little bit from Windows 2000.
You need just to:
- Double-click "Components services"
- Expand Computers node. You will get the "My Computer" node.
- From the contextual menu, click "Properties" to get a window for general configuration
If you want to define specific settings, double-click on "My Computer" node and expand the "DCOM config" entry. Then, you select the application you are interested in and click on the contextual menu "Properties".
What is an AppID?
DCOMCNFG lists only applications that have an AppID. It is a GUID that uniquely identifies the application executable.
AppIDs are stored in the Registry under the HKEY_CLASSES_ROOT\AppID key.
Each application’s AppID entry groups all settings for distributed COM objects hosted by the application executable. We can enumerate these settings: AccessPermission, AuthenticationLevel and LaunchPermission.
What is a CLSID? ProgID?
A CLSID is a 128 bit number that uniquely identify a software component. There are 218 possible unique values. This large number makes the probability to find two equal CLSIDs very small.
CLSIDs are generated by the Microsoft’ useful tool called GUIDGEN.exe (based on the COM call CoCreateGuid).
Back to OPC standard, every OPC Server should have its own CLSID.
So that any OPC Client can identify the OPC Server to which it wants to connect.
But, this identifier is quite difficult to manipulate and remember for more than one OPC Server. To make things easier, an OPC Server is rather identified by a human readable name of string type called ProgID. Generally, the ProgID format is as follows:...
What are callbacks?
In asynchronous communication, the OPC Client does not receive the final results when receiving the request result (success/failure). The request is processed in two steps: call and callback. For example: Read request
- Firstly, the OPC Server returns a preliminary error codes and no values (call).
- Secondly, the OPC Server sends a callback to the OPC Client with the requested values in case of success.
Giving this scenario, the OPC Server and OPC Client roles are reversed. In fact, the OPC Server behaves as a COM client and the OPC Client as a COM object.
This is very important to understand because we should take it in our account when configuring DCOM. Any bad DCOM configuration may cause a problem of not receiving data changes at the OPC Client side.
What is OPCENUM?
OPCENUM is the OPC Server Browser. It is a COM object (Server) that offers interfaces for browsing local and remote OPC Servers. OPC Foundation published until now versions 1.1 and 1.2.
OPCENUM can run as an executable or a Windows Service.
Before using it, you should register it.
Apply this command line "opcenum.exe /RegServer" to register OPCENUM as an executable.
Or, this command line "opcenum.exe /Service" to register OPCENUM as a service.
What is Registry?
The Windows Registry is a database that stores all your system information and settings.
This includes all hardware, installations, operating system, users, etc. It also contains all registered OPC Servers (server type: local or in-process, full path, implemented categories and vendor information).
For example, any change made through DCOMCNFG is saved to the Registry.
Thus, the Registry reflects the current configuration of your system.
How can we update the Registry content?
We can update the Registry content in different ways:
- Applying a *.reg file, you will be prompted to confirm changes
- Programmatically: by using the Windows 32-Bit Registry API: it contains functions starting with RegXXX
- From the Registry window: type regedit (Start | Run) and manipulate Registry entries graphically
How can we modify the Registry access privileges?
Assume you are logged with an Administrator account.
You can define the permissions for the Registry by using the tool Regedt32.
To run it, click Start | Run and type Regedt32.
Windows XP integrated this utility into Regedit.exe.
Can we access the Registry of a remote machine? How?
It is possible if you have the privileges to access the remote Registry.
Launch the Registry Editor through:
Run => regedit => File => Connect Network Registry…
If you need additional definition or clarification, please do not hesitate to contact me at hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
What are the OPC Servers types?
There are two types of OPC Servers: in-process and out-process servers.
In-process servers are written in form of a Dynamic Link Library (DLL) loaded in the OPC Client’s process space.
Thus, each OPC Client application manages its own Server instance.
Whereas, out-process servers are standalone applications. Therefore, an out-process server is written in form of an executable. It can be launched by any OPC Client locally or remotely. In multiple OPC connections, all OPC Clients connect to the same instance of the OPC Server’s application. This allows OPC Server application to share data between all its OPC Clients.
In-process servers are better than out-process servers in term of speed and performance.
How OPC components communicate locally and remotely?
OPC components can communicate on the same machine through LPC (Local Procedure Call).
They can also communicate on distributed computers using RPC (Remote Procedure Call).
How can the OPC Server be launched?
An OPC Server can be launched as an executable or run on background as Windows service.
Like any service, the OPC Server’s service can be managed (start, stop, pause) from the Service Control Manager (SCM).
What do you mean by DCOMCNFG?
Microsoft offers a Windows built-in tool called DCOMCNFG used to define DCOM settings for COM applications.
You can launch it by typing dcomcnfg on Start | Run.
DCOMCNFG window is mainly composed of the following tabs:
- Default Properties: to enable/disable DCOM and set the default communication properties for DCOM (authentication level and impersonation level). The authentication level specifies if the authentication of the caller is requested. If it is the case, you have to set the permission to honor (authentication only at the connection step, at every call, etc).
The impersonation level specifies whether the applications can determine who is calling them; and in which manner the identity of the caller is used.
- Default COM Security: to set permissions for the users that can access COM applications and those who can launch them.
- Default Protocols: to order by priority the network protocol to be used by DCOM. "Connection-oriented TCP/IP" is the default setting.
Using DCOMCNFG, you can either set a general configuration to be applied to all COM applications installed on the local machine or define custom configuration for a specific application.
In Windows XP, DCOMCNFG window layout differs a little bit from Windows 2000.
You need just to:
- Double-click "Components services"
- Expand Computers node. You will get the "My Computer" node.
- From the contextual menu, click "Properties" to get a window for general configuration
If you want to define specific settings, double-click on "My Computer" node and expand the "DCOM config" entry. Then, you select the application you are interested in and click on the contextual menu "Properties".
What is an AppID?
DCOMCNFG lists only applications that have an AppID. It is a GUID that uniquely identifies the application executable.
AppIDs are stored in the Registry under the HKEY_CLASSES_ROOT\AppID key.
Each application’s AppID entry groups all settings for distributed COM objects hosted by the application executable. We can enumerate these settings: AccessPermission, AuthenticationLevel and LaunchPermission.
What is a CLSID? ProgID?
A CLSID is a 128 bit number that uniquely identify a software component. There are 218 possible unique values. This large number makes the probability to find two equal CLSIDs very small.
CLSIDs are generated by the Microsoft’ useful tool called GUIDGEN.exe (based on the COM call CoCreateGuid).
Back to OPC standard, every OPC Server should have its own CLSID.
So that any OPC Client can identify the OPC Server to which it wants to connect.
But, this identifier is quite difficult to manipulate and remember for more than one OPC Server. To make things easier, an OPC Server is rather identified by a human readable name of string type called ProgID. Generally, the ProgID format is as follows:
What are callbacks?
In asynchronous communication, the OPC Client does not receive the final results when receiving the request result (success/failure). The request is processed in two steps: call and callback. For example: Read request
- Firstly, the OPC Server returns a preliminary error codes and no values (call).
- Secondly, the OPC Server sends a callback to the OPC Client with the requested values in case of success.
Giving this scenario, the OPC Server and OPC Client roles are reversed. In fact, the OPC Server behaves as a COM client and the OPC Client as a COM object.
This is very important to understand because we should take it in our account when configuring DCOM. Any bad DCOM configuration may cause a problem of not receiving data changes at the OPC Client side.
What is OPCENUM?
OPCENUM is the OPC Server Browser. It is a COM object (Server) that offers interfaces for browsing local and remote OPC Servers. OPC Foundation published until now versions 1.1 and 1.2.
OPCENUM can run as an executable or a Windows Service.
Before using it, you should register it.
Apply this command line "opcenum.exe /RegServer" to register OPCENUM as an executable.
Or, this command line "opcenum.exe /Service" to register OPCENUM as a service.
What is Registry?
The Windows Registry is a database that stores all your system information and settings.
This includes all hardware, installations, operating system, users, etc. It also contains all registered OPC Servers (server type: local or in-process, full path, implemented categories and vendor information).
For example, any change made through DCOMCNFG is saved to the Registry.
Thus, the Registry reflects the current configuration of your system.
How can we update the Registry content?
We can update the Registry content in different ways:
- Applying a *.reg file, you will be prompted to confirm changes
- Programmatically: by using the Windows 32-Bit Registry API: it contains functions starting with RegXXX
- From the Registry window: type regedit (Start | Run) and manipulate Registry entries graphically
How can we modify the Registry access privileges?
Assume you are logged with an Administrator account.
You can define the permissions for the Registry by using the tool Regedt32.
To run it, click Start | Run and type Regedt32.
Windows XP integrated this utility into Regedit.exe.
Can we access the Registry of a remote machine? How?
It is possible if you have the privileges to access the remote Registry.
Launch the Registry Editor through:
Run => regedit => File => Connect Network Registry…
If you need additional definition or clarification, please do not hesitate to contact me at hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
mardi 6 février 2007
OPC Data eXchange Specification: Enabling horizontally data exchange between OPC based systems
OPC DX is acronym of OPC Data eXchange.
By March 2003, OPC Foundation released the new specification OPC Data eXchange version 1.0.
Unlike OPC DA, HDA and AE standard that were defined to manage a specific sector in the automation world: OPC DA for real time data that represents the current state of connected devices, OPC HAD for historical data stored in archiving systems and OPC AE for alarms and events generated in the industry,
OPC DX does not target a new domain in the industry. It rather constitutes a complimentary standard for the following reasons:
- OPC DX specification is not coming with a new type of data to manage. It is designed for communication with OPC DA servers. Consequently, it manages real time data.
- OPC DX ensures horizontal communication between OPC servers. Whereas other standards specify vertical data transfer from/to OPC Server/OPC Client.
This standard is based on the OPC DA specification with a thin layer acting as an OPC DA Client for specific goals. Imagine you are in a factory where you have a set of equipments that need to exchange their I/O data. Let us focus on two specific equipments belonging to this set. With an OPC architecture, an OPC DA server (DA1) is installed to supervise sensor 1. A second OPC Server (DA2) is installed to supervise sensor 2. If the pressure of sensor 1 exceeds x, then the temperature of sensor 2 should be multiplied by 1.5. Instead of developing a specific gateway to collect the current pressure of sensor 1 and updates the temperature of sensor 2 through DA2 at the appropriate moment,
An OPC DX server can be installed on sensor 2 to collect directly last pressure value from DA1 and updates the temperature of sensor 2 in the most efficient way.
That’s why an OPC DX server is the combination of an OPC DA Server and OPC Client layer.
Giving this architecture, we can distinguish:
- An OPC source server from which data is collect
- An OPC target server that collect the data for its own processing. The target server must be OPC DX.
To allow this horizontal data exchange between OPC servers, following are the general configuration steps to respect:
- DX configuration by using an OPC DX client to define: source servers and DX connections. OPC DX permits data transfer through a logical container of data exchange called DX connection. It defines the source item, the target item and other parameters.
- After that, data transfer is controlled from any OPC DA client connecting to the DX server
Above is just a brief presentation of OPC DX standard. I guess you have a lot of questions that may include the following:
1- How much data transfers it is allowed?
This means how many DX connections can be configured in the OPC DX server. The OPC DX specification defines a DX Server status flag called MaxDxConnections. This flag determines the maximum number of supported DXConnections by the DX server.
2- How OPC DX standardize the data transfer between OPC servers?
OPC DX specification defines a new OPC interface called IOPCConfiguration to manage DX connections and source servers (add, remove, query and update).
DXConnections and source servers’ management is performed by any OPC DX Client.
This step is called DX configuration.
3- Where the DX configuration is stored?
The current DX Server configuration is stored in the server DX DataBase. The DX DataBase can be saved in any media such as XML file.
4- What is the DX DataBase?
In addition to collected DA tags, the OPC DX Server maintains a reserved subtree named “DX” under the root of its address space for DX items. This subtree is called DX DataBase. It contains 3 braches at the top level:
- ServerStatus: provides information about the DX Server status such as DXConnectionCount, MaxDXConnections and SourceServersTypes (the supported DA versions for source servers).
- DXConnectionRoot: contains all configured DX connections
- SourceServers: contains all configured source servers
5- What is the role of the DA Client communicating with the DX Server?
The DA Client can monitor and control the DX Server through runtime attributes of DXConnections such as:
- DXConnectionState
- WriteValue, WriteQuality, WriteTimestamp
- WriteErrorID, WriteErrorDiagnostic
- Etc.
A DXConnection is represented as a read-only OPC DA item.
6- When the data transfer is started?
Once the DX configuration step is performed successfully, the DX Server opens a DXConnection under the following conditions:
- the attribute “SourceServerConnected” of the requested source server is TRUE
- At least one DXConnection among the configured ones whose source server is this server and its SourceItemConnected attribute is TRUE
Under the conditions above, the data exchange is automatically started even though there is no OPC DA/DX client connected to the DX server.
7- What are the types of data transfer defined by OPC DX?
The OPC DX specification does not have any restrictions on this matter. In fact, this can be a simple copy of data, any mathematic operation (sin, cos, arithmetic, etc). OPC DX unifies the way to collect data from source servers; and it is up to the target server to perform any processing on the received data values.
8- What are the OPC DA versions supported by OPC DX?
The supported versions are DA2, DA3 and XML-DA.
Although benefits of OPC DX standard since it enables data exchange between heterogeneous systems from various vendors, this standard was not very welcomed by industrials. Unfortunately, this standard is dying!!
If you have questions not shown in the list above, please do not hesitate to send them to my email: hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
By March 2003, OPC Foundation released the new specification OPC Data eXchange version 1.0.
Unlike OPC DA, HDA and AE standard that were defined to manage a specific sector in the automation world: OPC DA for real time data that represents the current state of connected devices, OPC HAD for historical data stored in archiving systems and OPC AE for alarms and events generated in the industry,
OPC DX does not target a new domain in the industry. It rather constitutes a complimentary standard for the following reasons:
- OPC DX specification is not coming with a new type of data to manage. It is designed for communication with OPC DA servers. Consequently, it manages real time data.
- OPC DX ensures horizontal communication between OPC servers. Whereas other standards specify vertical data transfer from/to OPC Server/OPC Client.
This standard is based on the OPC DA specification with a thin layer acting as an OPC DA Client for specific goals. Imagine you are in a factory where you have a set of equipments that need to exchange their I/O data. Let us focus on two specific equipments belonging to this set. With an OPC architecture, an OPC DA server (DA1) is installed to supervise sensor 1. A second OPC Server (DA2) is installed to supervise sensor 2. If the pressure of sensor 1 exceeds x, then the temperature of sensor 2 should be multiplied by 1.5. Instead of developing a specific gateway to collect the current pressure of sensor 1 and updates the temperature of sensor 2 through DA2 at the appropriate moment,
An OPC DX server can be installed on sensor 2 to collect directly last pressure value from DA1 and updates the temperature of sensor 2 in the most efficient way.
That’s why an OPC DX server is the combination of an OPC DA Server and OPC Client layer.
Giving this architecture, we can distinguish:
- An OPC source server from which data is collect
- An OPC target server that collect the data for its own processing. The target server must be OPC DX.
To allow this horizontal data exchange between OPC servers, following are the general configuration steps to respect:
- DX configuration by using an OPC DX client to define: source servers and DX connections. OPC DX permits data transfer through a logical container of data exchange called DX connection. It defines the source item, the target item and other parameters.
- After that, data transfer is controlled from any OPC DA client connecting to the DX server
Above is just a brief presentation of OPC DX standard. I guess you have a lot of questions that may include the following:
1- How much data transfers it is allowed?
This means how many DX connections can be configured in the OPC DX server. The OPC DX specification defines a DX Server status flag called MaxDxConnections. This flag determines the maximum number of supported DXConnections by the DX server.
2- How OPC DX standardize the data transfer between OPC servers?
OPC DX specification defines a new OPC interface called IOPCConfiguration to manage DX connections and source servers (add, remove, query and update).
DXConnections and source servers’ management is performed by any OPC DX Client.
This step is called DX configuration.
3- Where the DX configuration is stored?
The current DX Server configuration is stored in the server DX DataBase. The DX DataBase can be saved in any media such as XML file.
4- What is the DX DataBase?
In addition to collected DA tags, the OPC DX Server maintains a reserved subtree named “DX” under the root of its address space for DX items. This subtree is called DX DataBase. It contains 3 braches at the top level:
- ServerStatus: provides information about the DX Server status such as DXConnectionCount, MaxDXConnections and SourceServersTypes (the supported DA versions for source servers).
- DXConnectionRoot: contains all configured DX connections
- SourceServers: contains all configured source servers
5- What is the role of the DA Client communicating with the DX Server?
The DA Client can monitor and control the DX Server through runtime attributes of DXConnections such as:
- DXConnectionState
- WriteValue, WriteQuality, WriteTimestamp
- WriteErrorID, WriteErrorDiagnostic
- Etc.
A DXConnection is represented as a read-only OPC DA item.
6- When the data transfer is started?
Once the DX configuration step is performed successfully, the DX Server opens a DXConnection under the following conditions:
- the attribute “SourceServerConnected” of the requested source server is TRUE
- At least one DXConnection among the configured ones whose source server is this server and its SourceItemConnected attribute is TRUE
Under the conditions above, the data exchange is automatically started even though there is no OPC DA/DX client connected to the DX server.
7- What are the types of data transfer defined by OPC DX?
The OPC DX specification does not have any restrictions on this matter. In fact, this can be a simple copy of data, any mathematic operation (sin, cos, arithmetic, etc). OPC DX unifies the way to collect data from source servers; and it is up to the target server to perform any processing on the received data values.
8- What are the OPC DA versions supported by OPC DX?
The supported versions are DA2, DA3 and XML-DA.
Although benefits of OPC DX standard since it enables data exchange between heterogeneous systems from various vendors, this standard was not very welcomed by industrials. Unfortunately, this standard is dying!!
If you have questions not shown in the list above, please do not hesitate to send them to my email: hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
Inscription à :
Articles (Atom)