User Access System

Using the Access System

Logging In

There are three ways to log into a system:

• When RF ID reader is enabled, scan RF ID card asynchronously without login dialog.
• Using login dialog triggered by login control tag.
• Using login dialog triggered by attempting to access a protected component while not having sufficient privileges, or authorize is set with onEachAccess option.

The login dialog is displayed each time an authentication procedure needs to be followed before access to a particular controlled component and/or screen is granted. Currently, the login dialog support two ways to authenticate a user:

• User name and password
• RFID

When RFID reader is enabled on the terminal (Config->User Management), it is selected by default. Users just need to their RFID card to log into the system. If they prefer to authenticate via user name/password in stead of RF ID, they may select the Password tab to proceed entering the user name/password.

WARNING

If a user is created without a password, the user may log into the system without a password.

When a user tries to enter a name not defined in the user management system, a “User does not exist” message will be displayed on the screen.

Logging Out

There are three ways to log out of a system:

• Logout event can be triggered by changing in value of logout control tag. A message with the name of last user will be displayed.
• When a new user is authenticated, the previous user is logged out without any messages.
• In OI versions 1.10 and later, users can be automatically logged out after a period of time specified in the User Management settings dialog.

Using in OIB

Status Tags

• User ID (type: Integer)
  • A non-zero User ID is assigned to each user at the time it is created. When the value of this tag is zero, no user is currently logged into the system. A non-zero value corresponds to the actual user id of the user currently logged into the system.
• User Name (type: Character Array)
  • This tag contains the name of the user currently logged into the system. The name is specified through the user management dialog and can not be empty/all spaces. Therefore, if the tag contains all spaces or an empty string, there is no user currently logged into the system. The maximum length is 30 characters.
• User Group (type: Array of 16 bits / Integer)
  • This tag contains an array of 16 bits and can be presented as an integer. A user's access level is specified via the user management dialog and any combination of group access can be granted. See Access Groups for more information.

Values when no user is logged in:

Control Tags

• login
  • Change from zero to nonzero in its value will trigger the system to display the user login dialog. The user may proceed through the authentication process by either entering the correct username/password combination, or by scanning the RF ID card. Upon successful verification, the user is logged into the system. The operation may be canceled on screen. The integer value itself does not have any significance; the system will only react to its changes.
• logout
  • Change from zero to nonzero in its value will cause the current user to be logged out of the system. A brief message will be displayed on screen and no user is logged into the system from that point on until the next authentication process. Similarly, the integer value itself does not have any significance.

Adding Authentication to Components and Screens

All components which react to user actions (Numeric Input, Text Input, List Box Input, Push Button, Screens, Message, Video Player, PDF Viewer and VNC Viewer) have additional properties added in order to support the new user access management system.

authorize

There are three options for this property:

• freeAccess
  • The component setup with this option is freely accessible by anyone.
• useLoggedUser
  • The OI system maintains the information about the user currently logged into the system. A user will remain the current user until the value of the logout control tag changes or another user logs into the system instead. If the current user attempts to access a component setup with this property without proper privilege, the user login dialog will be displayed to prompt for another user with proper privilege to authenticate through the system. If the current user already has sufficient privilege, no login dialog will be displayed and the user may interact with the component without further authentication process.
• onEachAccess
  • This option provides further protection to sensitive components. It requires a user to go through the authentication process each time accessing a component, even if the user may already be the current user and has sufficient privilege to access the component. The last authenticated user will becomes the current user of the system.

allowedGroups

This is the integer value of the allowed groups. See discussion below on Groups for more information.

accessTimeout

This property was present with some components in previous OI versions and was named accessPasswordTimeout. This property allows a user to repeatedly access a controlled component, after the access privilege has been verified and granted initially, until the specified timeout period has expired. The timeout value is defined in seconds. It is accumulated from the last authorized access of the component and starts counting from 0 again after a re-access when the timeout has not yet expired. This property is used with accessPassword or authorization in onEachAccess mode which is described in the later section.

accessPassword

This property was present with some components in previous OI versions and it is kept for compatibility reasons. We recommend application engineers not to use this property in future applications and use the new user access management system instead. This property defines a static password, meaning it has to be specified when the OI application is created and cannot be changed at runtime, which needs to be entered upon each component access, unless a non-zero value is specified in the accessTimeout property.

allowPLC (Screen Property)

When allowPLC property is true for a particular screen, PLC may change to this screen via screen control tag in complete disregard of the access control system.

When allowPLC property is false, the system will take the access control properties into consideration as usual.

Config Screen Access

Access to Config Screen can be specified in the Application Settings dialog in OIB. In case no users have been specifically given privilege to any access groups that are allowed by config screen, the config screen becomes freely accessible by everyone.

User Management

Users are managed from the config screen.

WARNING

Any user who gains access to the User Management dialog may add, delete and edit users in the system.

Username Requirements

• name must be unique
• cannot be empty or consisted of only spaces
• the maximum length of a user name is 30 characters
• the username is case sensitive

User ID

A unique user id is automatically assigned to the newly created user and maintained by the system internally.

Password

The user name and password are case sensitive. When a user is created without a password, the user may log into the system without a password after entering the correct user name.

Allowed to access User Management

A setting for each user. If enabled for a user then that use may access the User Management area from the config screen. It is possible to have no users with access to user management in which case configuring users may be accomplished by editing the User Database File.

Allowed to use Password

A setting for each user. If enabled/yes then the user may log in using password. If disabled/no then the user may only log in via RFID.

RFID

The use of an RFID reader is optional and can be enabled from the user management dialog. When enabled, a separate tab in user edit dialog will be available for RFID enrollment, as well as a separate column in User Management dialog which displays which RF ID is assigned to which user.

Automatic Logout

Users can be automatically logged out after a period of time by specifying a time in the User Management -> User Management Config dialog.

RFID Access

When the user edit dialog is displayed with RF ID tab a RF ID card can be enrolled any time. This operation will assign particular card to the user. It is confirmed by message “User Enrolled” . The RF ID number assigned to the user is displayed in the Enrolled Card Number field. When the administrator wants to unassign a card he can press the Clear button.

Configuration of serial RF ID reader communication is done via Configure button. At the top of the configuration dialog a COM serial port or a USB to Serial converter can be selected.

A typical setting for RF ID reader is Baud Rate 9600, Data Bits 8, Stop Bits 1, Parity None, XON/XOFF disabled, and RTS/CTS disabled.

Current settings of the selected port and status of the RF ID reader communication is displayed at the bottom of the User Management dialog.

Configuring the RFID Reader

1. Enable RFID
2. RFID Configure
3. Default settings: - OI-Embedded - USB_CDC_ACM1 - 9600 / 8 / 1 - None Disabled Disabled - OI-Windows - COM# (match the Com port Windows assigns to the device) - 9600 / 8 / 1 - None Disabled Disabled

   WARNING

   When using OI-Windows, the Com port will change if the device is plugged into a different port. This setting will need to be updated manually in OI user configuration.

Enrolling a User

In the User Management screen, select one of the Users and press the Edit User button. A new window comes up, open the RFID tab and then scan the RFID badge for the user. If successful, a notice will appear showing that the user is now associated with the badge #.

Access Groups

A component may belong to multiple access groups, and a user may have privilege to access multiple access groups. OI supports 16 access groups.

OIB allowedGroups

In OIB, the allowedGroups property accepts an integer representation of the 16-bit arrays. For example, when the access control is enabled for a component, i.e. not in freeAccess mode and no static password has been specified, an allowedGroups value of 0 means no access group has the privilege to access this particular component, and at the opposite extreme, a value of 65535, i.e. all bits are 1s, gives any user with at least one access group privilege the right to access this particular component. We recommend the project engineers to plan out the access groups ahead of time and not to over complicate the scheme.

Calculating Access Group Values

Access groups are set as binary values. There are 16 possible access groups. To define which groups are allowed access, compute the integer value of the binary.

Access Group Tool

Click on the bits below or enter a value to calculate the Access Groups.

Group:	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
Value:	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
Bits:	0000000000000000
Groups:	[]
Access Group Value:

System Details

User database file

All information about defined users, including the RFID value if RFID is enabled, is stored in a (CSV) text file oiusers.csv. The format of this file is optimized for spreadsheet compatibility so it can be edited by external program. This file can be transferred from the OI by ftp client or transferred to USB Flash drive using Transfer Files dialog.

The file can also be transferred to other OI screens in a similar manner.

Authentication Logic

The following is the logic used to authenticate a user for accessing a protected component or screen:

1. If no accessPassword is defined, and authorize with freeAccess option, the component or screen is freely accessible.
2. If accessPassword is defined and authorize with freeAccess option, a password is required to authenticate. (Note: when an older applications created using v1.6 and older OI Builder with predefined accessPassword property, the authorize option is default to freeAccess.)
3. If the accessPassword is not defined, and authorize with either useLoggedUser or onEachAccess option, the authentication is handled by the new user access management system. Only authorized users with sufficient privilege will be able to gain access.
4. If the accessPassword is set, and authorize with options other than freeAccess, the authentication process will be handled by the new user access management system. The accessPassword settings will be ignored.
5. GoTo Screen buttons have five static password options instead of a single accessPassword property. If these options are used, they are used along with the new user access management system, meaning the user will have to enter one of the predefined static password first before the new user access system takes over. User needs to pass both authentication scheme in order to trigger the button. This behavior is implemented for backward compatibility reasons and we recommend application engineers to switch to the new user access management system instead if at all possible.

Authentication Behavior

Every time a user is successfully authenticated, an information message with name of logged in user is displayed. If for some reason, the current user can no longer meet the privilege requirement, e.g. When the screen is changed from PLC, a login dialog will be displayed and it will not close until a user with sufficient privilege is logged in. The last authenticated user, regardless whether having sufficient privileges, will become the current user. A dialog with message ”Access Denied!” will appear indicating access has not been granted. User will remain logged in even if OI application is restarted.

Best Practices

We recommand the access groups to be organized in one of the two ways:

• From components' perspective, access groups can be considered as function groups. For example, we can think of group one as robot controls group and make all components dealing with robot controls allow group one as part of their allowedGroups, similarly, we can have groups like tooling manual controls group and errors recovery group, etc. Then, depends on users' privileges, we may assign one or more function groups to them.
• From user's perspective, we may consider access groups as privilege levels. For example, application engineers will need access to everything in order to design and trouble shoot the application, maintenance will need access to components that have to do with maintenance tasks such as robot controls and various day-to-day operation tasks, whereas operators will only need very basic access to things that will help them keep the production going.
• Last but not the least, we recommend using screen level access control more than components level access control. Remember that once a user gains access to a particular screen, if no further distinction of access level among components within this screen is needed, we do not need to double protect these components, namely, they can be granted freeAccess within this protected screen. It would make the application cleaner and better organized.