Since the SmartUI Server is a data portal that can aggregate data from numerous sources, it is possible that data with varying degrees of sensitivity may be made available to the SAME Server. For this reason, it is essential that the data is appropriately secured.

As the architecture allows the SmartUI Server to be accessed by both Designers primarily used by engineers, and Operators primarily used by end-users, it is necessary to ensure that different users have different levels of access to this data.

NOTE: SmartUI “locks” down everything and one of the functions of the designer of the system is to grant the necessary access to the required users. This approach to security follows very much along the lines of Windows security, as implemented by Microsoft in Windows XP SP2.

Security in SmartUI is user-centric and operates on top of the traditional Windows operating system security, using a configurable subset of the existing users and groups on each Server computer known as the “allowed” users and groups.

For instance, when a Client (Designer and Operator) is launched, it is necessary to log in to a Server and only a user that is either an allowed user or a member of an allowed group on this Server is able to log into it.

In addition to controlling the access of these “allowed” users and groups to the Server, its configured data sources and their data, it is possible to control or limit the access that these users have within each Client (Designer and Operator).

The following diagram illustrates how security in SmartUI operates on top of the traditional Windows operating system security by means of the allowed users and groups, which is a selected set of the existing Windows users and groups on the SmartUI Server machine.

Security should typically be implemented during the deployment of SmartUI so that the initial allowed users and groups can be configured on each Server. Then the access of these allowed users and groups should be specified within each Server and Client.

However, security configuration should continue throughout the life of the project to secure new data sources by limiting the access of new users and modifying the access levels of existing users as required, etc.

Server security must be configured per Server in the Enterprise Manager by using its Security component within the Management category.

Most importantly, this Security component configures the allowed users and groups which provides the first or foundational level of ALL user security and management within SmartUI, not only for Server security but also Client security too and is therefore mandatory.

Furthermore, this Security component configures the first level of purely Server-specific security in the form of Policies, which can be used to provide a general (large-scale) level of control to safeguard the data that is made available to the Server.

The second level of Server-specific security can be broadly termed Datasource-specific security, which can be used to provide a precise (finely tuned) level of control to safeguard the data that is made available to the Server. This is therefore configured per data source and its exposed data elements and special functions. For details of the structure of data within SmartUI, see the section on Data Architecture.

Allowed Users and Groups

As previously discussed, security in SmartUI is user-centric and operates on top of the traditional Windows operating system security.  This is made possible by using a configurable subset of the existing users and groups on each Server computer known as the “allowed” users and groups.

NOTE: SmartUI uses the Active Directory to expose the available Users and Groups from which the person designing the SmartUI application can then choose his allowed SmartUI users.

These allowed users and groups, therefore, provide the first or foundational level of ALL security within SmartUI, hence their creation is mandatory for every SmartUI Server.  In other words, unless a user is either an allowed user or a member of an allowed group, he/she will be unable to log in to the Server and use SmartUI.  Before a SmartUI client (Designer or Operator) can be used, it is necessary to log in to a Server first.

The allowed users and groups are the means by which all other user security and management in SmartUI is applied.  They are typically added and removed via the Designer in the Enterprise Manager by using the Users and Groups list of the Security component that is within the Management category of each Server.

However, it is possible to give certain users and groups total or global security access to each Server, which essentially become “master” users and groups that:
Permanently become allowed users and/or groups that cannot be removed from the lists of the allowed users and groups maintained by this Server so that these users will never be able to lock themselves out of the Server; and
Are always able to login to and have unrestricted access to this Server, its data sources and their data.

These global security users and groups should be used to administer the security of the Server by adding the other allowed users and groups and assigning the necessary access rights to each of them.  By default, only the Administrators group and the default login user is assigned global security access to each Server.

In addition to adding existing users and groups to the allowed users and groups for a Server, it is possible to create users that impersonate or masquerade as an allowed user.

For instance, when users are not part of the Windows security or where you do not want to expose a domain username and password when someone logs in to a Server over the Internet.  The impersonated user is then able to log in to a SmartUI client (Designer or Operator) and merely assumes the user security and management settings of the allowed user that is being impersonated.

Policies

Policies can be used to provide a general (large-scale) level of control to safeguard the data that is made available to the Server.  They can only be implemented after allowed groups and/or users have been added to this Server.

Policies are essentially a configurable set of rules that govern the access to a Server and its available datasource plugins (the types of data that the Server is able to connect to), as follows:

• Each policy represents a specific service or activity that can be performed by the Server, such as the ability to retrieve a list of its available datasources.
• Each policy can then be associated with one or more allowed users and/or groups with each policy.
• Any allowed user and/or group not associated with a policy is unable to perform the service that it represents.

In other words, whenever a Server receives a request for a service it first determines whether the currently logged in user is part of the allowed users or groups that are able to perform this request, and then denies or grants access based on this result.  By default, the Users group and any group(s) and/or user(s) that have been assigned global security access to this Server is automatically associated with every policy.

Certain policies represent datasource plugin-specific services such as the ability to add or remove a new datasource.  In this case, the policy contains a list of the available datasource plugins so that the required allowed users and/or groups need to be associated with the applicable datasource plugin.  Once a datasource plugin has been secured using a policy, this security will be applied to all of its existing and future datasources that are configured.

NOTE: In order to secure a specific datasource and/or its data, data source-specific security is required.

Allowed users and/or groups are added to and removed from policies via the Designer in the Enterprise Manager by using the Policy list of the Security component that is within the Management category of each Server.

Datasource-specific Security

Datasource-specific security is a general classification that encompasses all the security measures that can be used to provide a precise (finely tuned) level of control to safeguard the data that is made available to the Server.  This too can only be implemented after allowed groups and/or users have been added to this Server.

As its name implies, this essentially involves securing the specific datasources that have been added to a Server and their configured exposed data elements and/or special functions.

However, since datasources are themselves data elements, datasource-specific security simply consists of the following two security methods:

Data Element Security

Since every datasource exposes its data in the form of data elements, it is therefore essential that the access to these data elements be sufficiently controlled to provide the necessary security for your data.

Each data element (and datasource) can be assigned security permissions that determine which users are able to configure its security settings and which users are able to view, set and/or remove it.

Data element security is applied via the Designer in the Enterprise Manager by right-clicking the required datasource and/or data element and selecting the Security item.

NOTE: This item is only available if the currently logged-in user has the necessary security permissions to configure the security settings of this datasource and/or data element.

The following strategy is recommended for implementing data element security:

• Specify the extent of the access that allowed users and/or groups are given to the available datasources so that only the necessary datasources are available for them to perform their required duties.
• Specify the extent of the access which allowed users and/or groups given to the specific data elements within these datasources so that only the necessary data is available for them to perform their required duties.

In this way, the currently logged in user should only be able to see the datasources and their data elements that are necessary to perform his/her function.  Furthermore, whenever any data element is accessed, this Server will always determine whether the currently logged in user is able to perform the requested data element operation and accept or reject the request accordingly.

By default, only the group(s) and/or user(s) that have been assigned global security access to this Server are automatically assigned full access to all datasources and their data elements.  Data elements need to be secured separately for EACH datasource that is created.

However, data element security does not need to be applied manually as it is also possible to automatically:

• apply the security configuration applied to a datasource to all of its data elements (both existing and future); and
• Inherit the security configuration applied to a datasource to simply configure the security for a data element.

Special Functions Security

In addition to making its data available as data elements, a datasource may only provide special functions.  By securing the provided special functions it is possible to secure this specific functionality provided by the datasource itself, which is especially evident when the special function is the only means provided for performing a specific action.

Although special functions are provided by datasources, their security is entirely unaffected by the security settings applied to their datasources.  Each special function can be assigned security permissions that determine which users are able to configure its security settings and which users are able to use it.

Special function security is applied via the Designer in the Enterprise Manager by right-clicking the required special function and selecting the Security item.

NOTE: This item is only available if the currently logged-in user has the necessary security permissions to configure the security settings of this special function.

The following strategy is recommended for controlling access to special functions:

• Specify which allowed users and/or groups are able to use special functions at all, by associating them with the Invoke Special Function
• Specify which special functions these allowed users and/or groups are able to use for each datasource so that they will be able to perform their required duties.

In this way, whenever a special function is used either specifically or by the datasource itself, the required Server first determines whether the currently logged in user is part of the allowed users or groups that are able to use special functions.  If this is so, it will then determine whether the user is actually allowed to use the special function associated with this specific datasource and accept or reject the request accordingly.

By default, only the group(s) and/or user(s) that have been assigned global security access to this Server are automatically assigned full access to all special functions.  Special functions need to be secured separately for EACH datasource that is created.

Client Security

Security is normally implemented by the Server to secure the data exposed by it.  However, the Client (Designer and Operator) can implement its own security.  Although these security measures are distinct from Server security, they can only be implemented after the necessary allowed groups and/or users have been added to the Server.  Client security is usually configured by means of user-profiles to control the access a user has within the Designer and Operator applications.  In addition to customising the display of these applications, profile settings can be used to limit the access users have within these applications too, as follows:

• to specify which menus and even which menu items can be accessed within the Designer; and
• To specify the permitted user interaction within the Operator.

Profiles can also specify whether you want to automatically logoff its assigned users from the Client (Operator or Designer) after a specific period of inactivity.  This is an added security feature that is often required by particular industries.  For instance, this is required to comply with CFR (The Code of Federal Regulations), the codification of the general and permanent rules published in the Federal Register by the executive departments and agencies of the Federal Government 21 (Food and Drugs) requirements.

It is also possible when designing graphic forms, to specify which users have access to which properties are exposed by the controls that have been added to the graphic form.  In other words, it is possible to provide alternate sets of properties, from the default or standard properties displayed for controls, for one or more of the allowed users and/or groups.