From OpenSCADAWiki
Jump to: navigation, search
Other languages:
English • ‎mRussian • ‎Українська
Module Name Version License Source Languages Platforms Type Author
LDAP Directory by LDAP 0.6 GPL2 en,uk,ru,de x86,x86_64,ARM DB Roman Savochenko
BD module. Provides support of directories by LDAP.
  • Total complexity: 1.9 HD[!]
  • Sponsored by, for initial implementation on 1.7 HD[!]: Alexander Kolesov, BIOCAD, 2017
  • To Do:
- expand the authentication mechanism by the storage functions (the DB object), that is virtual functions to TBD:
  • auth() — direct checking the user authentication, through "bind" or ldap_whoami();
  • passHash() — obtaining the password hash, to comparing, if auth() is missed, and changing the password by the function ldap_passwd() or see to the utility slappasswd.
- expand the "OSCADA-user" scheme:
  • set the password field "PASS" as a synonym of "userPassword";
  • make the own scheme dependent from "simpleSecurityObject";
  • check of working with the field-type "userPassword".

The module gives to OpenSCADA support of directories by Lightweight Directory Access Protocol (LDAP). The module is based on the OpenLDAP library on the programming language "C". Due conceptual difference the directory service from data bases (DB) the module allows you to perform mostly reading and modification entries represented as tables' records in the DB conception.

Directory service or name service maps the names of network resources to their respective network addresses. It is a shared information infrastructure for locating, managing, administering and organizing everyday items and network resources, which can include volumes, folders, files, printers, users, groups, devices, telephone numbers and other objects. A common use of LDAP is to provide a central place to store usernames and passwords. This allows many different applications and services to connect to the LDAP server to validate users. The protocol provides an interface with directories that follow the 1993 edition of the X.500 model:

  • An entry consists of a set of attributes.
  • An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema.
  • Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN), constructed from some attribute(s), in pairs {name}={value} separated with the sign '+', in the entry, followed by the parent entry's DN, separated with the sign ','. Think of the DN as the full file path and the RDN as its relative filename in its parent folder.

1 Operations over the database

The module provides only opening database (representing in that way of a base entry) operation. In terms of the subsystem "DB" of OpenSCADA, opening of a DB is its registration for further using of the program. It also supports the operation of requesting the list of tables in the database.

LDAP database (connection) is addressed in the following format "ldap[s]://{host}[:{port}];bdn[;{adn};{pass}[;{tm}]]", where:

  • host — hostname of the directory service;
  • port — port, default 389;
  • bdn — base DN, an entry which sub-entries means as tables of the database with RDN attribute "ou" presence (usually it is the object class "organizationalUnit");
  • adn — Distinguished Name of the authenticate user, omitting the user and next password will cause to anonymous connection;
  • pass — password of the Distinguished Name of the authenticate user;
  • tm — network and generic timeout in seconds by real number.

2 Operations over the table

The operations of opening and closing of the table (representing in that way of an entry into the base entry) only are supported. As a table is considered to be elements with existing the attribute "ou" (usually it is the object class "organizationalUnit") that are included in the base element.

3 Operations over the table content

  • scanning of the table records;
  • requesting the values of specified records;
  • setting the values of specified records.

API of the subsystem "DB" suppose the access to the contents of the table on the value of key(s) fields. Thus, the operation of requesting of the record implies the preset of key columns of the object TConfig, which will do the request. Creating a new record (row) is performed by setting the record values that are missing.

Before setting any value, the module loads the current value, compares them and then sends only the changed value.

The module currently does not differentiate the attribute types of the elements and considers all of their as strings.

To perform all this operations for the OpenSCADA nodes you need to create, load and use of the specific schemes of this nodes to the directory server. All known schemes of the OpenSCADA nodes provided into the followed table:

OpenSCADA node Value of the Organizational Unit "ou" (table name) Structure Scheme, auxiliaries mostly
Users group ou=Security_grp NAME, DESCR, LONGDESCR, USERS OSCADA-grp

A subtree of LDAP entries of the typical tables of users and their groups looks like:

  • dc=oscada,dc=org — base DN (bdn) pointed into the DB object address
    • ou=Security_user — RDN of the table "Security_user" of the OpenSCADA users, in the structural object class "organizationalUnit"
      • name=user1 — RDN of a record of the table "Security_user" for the user "user1", in the structural object "account" and the auxiliary class "OSCADA-user"
      • name=user2 — RDN of a record of the table "Security_user" for the user "user2", in the structural object "account" and the auxiliary class "OSCADA-user"
    • ou=Security_grp — RDN of the table "Security_grp" of the OpenSCADA groups, in the structural object class "organizationalUnit"
      • name=grp1 — RDN of a record of the table "Security_grp" for the user group "grp1", in the structural object "account" and the auxiliary class "OSCADA-grp"
      • name=grp2 — RDN of a record of the table "Security_grp" for the user group "grp2", in the structural object "account" and the auxiliary class "OSCADA-grp"

4 Access rights

Access rights to the database are determined by the user rights of the connection.