Security

Core Process

About Security

Security for IFS Field Service Management (FSM) includes the following:

Controlling access to FSM using license types
Controlling access to applications using a person ID and password
Enabling single‐signon using OpenID credentials
Controlling access to menus and screens using roles
Controlling read‐only access to views and functions using roles
Controlling access at the record level using access groups

About License Types

The license type identifies which FSM applications a person can access. The following license types are available:

STUDIO—The person can access any FSM application or portal, including Studio.
NAMED—The person can access any client or portal. This option appears if you have a named‐user license.
MESSAGE—The person can only use XML messaging. The personcannot access any client or portal.
MOBILE—The person can only use an FSM mobile application.
TECHPORTAL—The person can only access the Technician Portal.
CUSTPORTAL—The person can only access the Customer Portal.
REPRPORTAL—The person can only access the Repair Portal.
WHSEPORTAL—The person can only access the Warehouse Portal.
DEALPORTAL—The person can only access the Dealer Portal.

About Authentication

You can specify authentication using FSM authentication or Windows authentication using OpenID Connect. You can also choose to allow both kinds of authentication, specifying which type of authentication is offered first. The following OpenID Connect providers are supported:

Azure AD for cloud implementations
AD Federated Services (AD FS) on‐premise with Windows Server 2016

The following are benefits of Windows authentication using OpenID Connect:

Enforced at client and server level
Open, modern claims‐based standard
Works with Smart Client, Web Client, Mobile clients, portals, and PSO

For more information, see http://www.openid.net/connect/faq.

To prevent a person logging in to FSM, you can make the Person record inactive. Only delete a person record when it is created in error, to avoid losing history information related to that person.

Dynamic Scheduling

You can also log in to dynamic scheduling features at the same time you log in to FSM. By selecting PSO System User on the Person record, hashed password information is passed to Dynamic Scheduling.

When a password changes on FSM, the person must log out and log in again.

About Roles

Role records are used to identify the menus and screens that a person cannot access in FSM. Role records are associated with a Person record. Role records are generally identified using codes and descriptions that describe a specific job function.

If you do not want a menu or screen visible to a person, you must explicitly disable access. By default, menus and screens of FSM are accessible. For example, you might choose to restrict access to application administration screens to all but a few employees; in this case, most roles would include an entry that disables access to the Admin menu.

Three kinds of restricted access are available on the Roles screen.

When Disabled is selected, the function or menu item does not appear.
When Read Only is selected, the function or menu item can beaccessed but no changes can be made.
When No Delete is selected, the function or menu item can be accessed but records cannot be deleted.

For example, you might allow your field service representative supervisors to have read‐only access to screens on the Admin menu, and deny your field service representatives access to the Admin menu altogether.

To protect tables from being potentially affected by messages received, you can generate role tables. These tables are used to associate read‐only and do not delete characteristics with tables that each role function applies to. To generate or regenerate role tables, the button Generate Role Tables is clicked on the Role screen. This feature must be used sparingly when multiple roles are assigned to a person because different roles can assign different permissions to the same table.

You can assign multiple roles to a person. If multiple roles specify different access to the same item, the least restrictive access is used, unless the Incremental option is selected. Then, each line is applied separately.

Certain roles are necessary for administration of Person records. An administrator requires the role function EDITPERSONANY to set the license type; the role function EDITROLEANY is required to set the role.

The role function IS_ADMIN_ROLE is required to edit the following critical application parameters:

BING_MAP_PROVIDER_KEY
DYNAMICS_PASSWORD
EBAY_SANDBOX_TOKEN
FACEBOOK_APP_AUTHORIZER_URL
FSM_AUTHENTICATION_METHODS
GOOGLE_MAP_PROVIDER_KEY
IFS_APPS_INTEGRATION_CON_STR
IFS_APPS_INTEGRATION_PWD
INTEGRATION_MONITOR_PASS
INTEGRATIONS_FILE_SHARE
PAYPAL_API_PASSWORD
SALESFORCE_PASSWORD
SALESFORCE_SECURITY_TOKEN
SMS_SERVICE_LICENSE_KEY
SMTP_PASS
UPS_ACCOUNT_NUMBER
UPS_API_PASSWORD
UPS_APP_LICENSE
UPS_SHIPPER_NUMBER

About Access Groups

Access groups enable you to restrict access to certain records. The records a person can see is determined by the access group specified on the roles associated with the person.

For example, if a record has an access group value of 087, a person can see that record if the assigned role includes an access group value of 087.

There are three important things to remember when using access groups:

The access group specified on the Person record is used to determine who can view that Person record, not access for that person.
You can create records with access groups other than your own. When you save the record, you can no longer see it.
If you use access groups to control access within a process, for example, stock transactions, you must also grant access to all related records involved with that transaction, for example parts and places.

Determining Access Groups for Child Tables

Tables which are parents, such as Request and Place, typically contain an access group column. The child tables which are linked to those parent tables, such as Request Event and Place Note, use the access group value from the parent table to determine who can access rows in those tables.

FSM does this by utilizing the Parent type relationships to find the access group value.

It will check the Parent type relationships, in order of ascending sequence, for the first relationship which has a parent table which has an access group column.

Access Relationship Types

Occasionally a table has multiple parent tables which each have their own access group columns. In that case, it might be difficult for FSM to determine exactly which parent is appropriate for every child.

In that case, a user may receive access violations when not appropriate because FSM is looking in the wrong location.

Should this situation occur, an Access relationship can be added so FSM always knows exactly where to find the access group value.

The Access relationship is setup on the Custom Metadata screen. The relationship is added to the child table and should have the related table be the table which contains the access group column. Relationship Map records should be setup to link the two tables. Default records are not used for this relationship type.

There should be at most one Access relationship for a table. Should more than one Access relationship exist, FSM will only use the Access relationship with the lowest sequence value and any remaining Access relationships will be ignored.

When the Access relationship exists, the Parent relationship behavior described above is not used.

Using a View for Access Relationships

Should a child table have multiple different parents then it may be necessary to create a view which joins the child table rows to the various types of parent rows so that an access group column can be found for each row. The view should contain the key columns from the child table and an access group column. The definition should select the access group column from the different types of parent tables and perform a union of the selects.

Once the view is created, an Access relationship should be created from the child table to the view as described above.