Realm Filtering

Customers who are familiar with legacy versions of VTS/VTScada may be looking for "Realm Area Filtering".
Filtering has been extended to allow filters that specify tag hierarchies instead of, or in addition to, area properties and is now referred to as "Realm Filtering".

A new section name notation, [-REALMFILTER] has been defined. Legacy applications may continue to use the older notation, [-REALMAREAS], but that keyword will not appear elsewhere in these notes.

Realm filtering is based on a combination of security realms (as defined using the Accounts dialog) and either a set of selected tags (usually upper-level tags in a hierarchy), a set of area properties, or both. It will affect your application in the following ways:

  • Members of a security realm can see and acknowledge only the alarms from tag hierarchies or areas matching their designated realm filtering list.
  • When working with reports, members of a security realm can select tags only from tag hierarchies or areas matching their designated realm filtering list.
  • When working with the Historical Data Viewer, members of a security realm can select tags only from tag hierarchies or areas matching their designated realm filtering list.
  • The tag browser is affected, such that users in a given security realm will see only the tags that match their designated realm filtering list.

Ensure that you maintain one super-user account, which is an account having the manager privilege and which is not a member of any realm. Failing to do so will make it impossible for you to manage accounts outside your realm.

  • Realm filtering does not change what is visible on a page. All tags are visible on all pages to all users unless that page is protected by a security privilege. Any tag's trend window may be viewed.
  • While an operators may be able to see a control widget linked to a tag outside their realm, they cannot write to hardware using that tag.
  • Similar to the last point, operators with the Tag Modify privilege will not be able view or edit the properties of tags that are outside their realm
  • Alarm notification rosters must be configured with each contact user name including the full realm qualifier.
  • ODBC queries cannot see tags outside the matching realm list.

Why Should I Use Realm Filtering?

Realm filtering is most often used for larger applications where there users should be restricted to access tags or alarms from one part of the application but not another. Use Realm tag filtering to specify:

  • What alarms should be visible to a user, based on their security realm.
  • What tag hierarchies or areas should be shown in the tag browser, reports screen and historical data viewer when a user who is part of a defined security realm is signed in to the application.
  • What tag areas should be shown in the tag browser (if any) when no user is signed in to the application.

 

While realm filtering can prevent users from seeing and therefore acknowledging alarms in tags or areas they are not authorized for and can also prevent them from selecting those tags in reports and trends, it does not affect any page displays other than the alarm list. It does restrict access to controls on pages.

Filtering is only one part of security. You should also use application-specific security privileges to Protect Pages and Output Tags. Some benefits of realm filtering can also be achieved by using Master & Subordinate Applications.

How Does Realm Filtering Differ From Tag Area Filtering and Alarm Area Filtering?

Realm filtering affects lists of tags and alarms configured for tags in specific hierarchies or having specific area properties, hiding them from users according to their security-realm. It is not limited to any one workstation. The user may sign in to any workstation and they will still only have access to the alarms permitted by the filter.

Tag area filtering prevents tags that have been configured with specific areas from loading on a given workstation.

Alarm area filtering hides alarms associated with specific area properties from loading on a given workstation.

Where is Realm Filtering Configured?

  • Security Realms are configured for each user in the Accounts dialog.
  • Filters are configured in your application's Settings.Dynamic file using the Edit Properties page of the Application Configuration dialog.

How do I Configure Realm Filtering?

The following elements are involved in realm tag filtering:

  • Security realms must be configured and accounts assigned to realms.
    See Security Realms and follow the steps there to enable realm sign-ins and add users to realms before proceeding with the remaining steps.
  • Define one or more [RealmName-REALMFILTER] Sections. While these are stored in Settings.Dynamic, you are advised to use the advanced mode of the Application Properties dialog.
    • Name = properties in the above section.
    • Area = properties in the above section.
  • (Optional) Define a [RealmFilter] section containing names or areas whose alarms should be visible when no user is signed in.
  • (Optional) Define a [*-REALMFILTER] section containing the names and areas that should be visible with a super-user is signed in.

How should I format my filters?

For both Name and Area filters, an exact text match can be used. Additionally, the question mark (?) and asterisk (*) wildcard characters are permitted. Filters are not case-sensitive.

 

From an efficiency standpoint, the best name filters formats are:

  • An exact tag name with no wildcards.

    For example A\B\C\D for just one tag.
  • An exact tag name followed by "\*".

    For example, A\B\C\D\* for A\B\C\D and all of its children.

In the case where you want to see the parents of A\B\C\D, but not all of their children, the pattern set would be:

A\ , A\B\ , A\B\C\ , A\B\C\D\*

Other patterns are possible, but may be much slower.

 

If working with Master & Subordinate Applications and attempting to filter for tags in a subordinate application, you must use the name of the subordinate tag as seen the master, rather than wildcards. The only exception is to use a single leading wildcard, which will filter for tags in both the master and subordinate application. Note the use of backslashes in all the following examples.

Good examples:

MasterFolder\SubordinateAppName\MySites\*
*MySites\*

Bad examples:

Master*Folder?\SubordinateAppName\MySites\*
MySites\*

Security Realms and the VTScada Thin Client Server

Security realms also affect user's access to an application through the VTScada Thin Clients. On the VTScada Thin Client Server, add one realm for each security realm. Each realm must be given the same name as the security realm, and must include a reference to this application.

An operator can then connect to the application using a URL that includes the name of the Realm he is connecting to. For example, members of the Western realm would use the address: http://www.yourdomain/Western.

You must also define the RootNamespace property to designate an Internet realm for users who do not belong to any security realm.

[RealmName-REALMFILTER] Section

The Settings.Dynamic [RealmName-REALMFILTER] section holds the list of tag areas or tag names (and their alarms) that should be visible when a user in a given security-realm is signed in.

To specify the visible tags:

  1. Open your Application Configuration dialog.
  2. Select the Edit Properties page.
  3. Select the Advanced Mode.
  4. Select Add.
  5. Complete the dialog as shown.
    (Area filter shown on the left, tag filter shown on the right.)
          
  6. Select OK
  7. Repeat for as many tag names as you require.
    You may use the asterisk (*) wildcard character as any part of the Value, but for best results you are advised to restrict wildcards to the beginning or end of the tag names.

For each subsequent Name or Area property in the same section, you will be warned that the property already exists. Proceed anyway.

 

[REALMFILTER] Section

The [REALMFILTER] section of Settings.Dynamic is used only if you want to define the alarm areas that should be visible when no user is signed in. This is typically used if there is an Alarm List drawn on the default page because the Alarms page will not be accessible when no user is signed in. (See also, RealmAreasExcludeInvalid which controls whether tags that do not have any area defined will be included or excluded from view.)

To create a REALMFILTER section:

  1. Open your Application Configuration dialog.
  2. Select the Edit Properties page.
  3. Select the Advanced Mode.
  4. Select Add.
  5. Complete the dialog as shown on the left to filter on tag Area properties.
    Complete the dialog as shown on the right to filter on named tags. Note the \* in the value, which includes child tags of Station 2.
        
  6. Select OK
  7. Repeat for as many areas and tags as you require.
    For each subsequent area, you will be warned that the property already exists. Proceed anyway.

[*-REALMFILTER] Section

This optional section is used to restrict the tag areas that should be visible when a super user is signed in. (A super user is one who does not belong to any realm.) If you do not provide a [*-REALMFILTER] section, the super user can see all areas. If you do provide the section, then they can see only the areas specified in that section.

(The [*-REALMFILTER] section has no relation to the RootNamespace property. There is no realm named "*" for your super users to be a member of.)

To specify the tag areas that should be visible when a super user is signed in:

  1. Open your Application Configuration dialog.
  2. Select the Edit Properties page.
  3. Select the Advanced Mode.
  4. Select Add.
  5. Complete the dialog as shown on the left to filter on tag Area properties.
    Complete the dialog as shown on the right to filter on named tags.
         
  6. Select OK
  7. Repeat for as many areas or tag hierarchies as you require.
    You may use the asterisk (*) wildcard character as any part of the Value.
    For each subsequent property, you will be warned that the property already exists. Proceed anyway.

While realm filtering can prevent users from acknowledging alarms in areas they are not authorized for and can also prevent them from drawing tags having those areas, it does not affect any page displays other than the alarm list, and does not restrict access to controls.

If you wish to restrict user access to pages or to control tags, use application-specific security privileges. Some benefits of realm filtering can also be achieved by using Master Applications.

Restricting realm access to areas does not mean that the operators cannot see the tags belonging to areas outside of their realm's defined set of areas. It does mean that they cannot see or acknowledge alarms resulting from those tags. It also restricts their ability to select tags for use in reports and the Historical Data Viewer.

 

A related property is RealmAreasExcludeInvalid. This variable controls whether tags that do not have any area defined will be included or excluded from view.

If RealmAreasExcludeInvalid is set to 1, then no user will be able to view tags that do not have an associated area.