Document toolboxDocument toolbox

14.1 Access Control

Owned by Billy Sewell (Unlicensed)
Jan 26, 2024

On This Page:

Related Pages:

All clients of ServiceOptimizer are authenticated before access is allowed to the system. The method of user authentication is as follows and applies to all ServiceScheduling Clients:

  1. The Username is compared with those stored in sp085_users.user_id, if the user does not exist the login is rejected.
  2. If the user exists then the field sp085_users.auth_type is used to determine further authentication. If this value is set to “LDAP” then the LDAP Server is requested to validate the supplied password. Any LDAP Server problems (Server down etc) result in an authentication failure. The success/failure of the LDAP authentication is returned to the user.
  3. If the sp085_users.auth_type field is set to anything other than LDAP (default SECURED), then the following method of authentication is invoked:
    1. If the sp085_users.password is not NULL then the incoming password is hashed and then compared against the database entry with the result returned accordingly.
    2. If the sp085_users.password field is NULL, then we proceed to client type authentication. The client type and password are validated against sp430_client_types.
    3. If the appropriate sp430_client_types.password is NULL then the final authentication is to compare the supplied password with the password used for ServiceOptimizer connection to the Database.


Passwords

N.B. It is not possible to user passwords that contain commas – this will result in a failed authentication.

Using different authentication mechanisms

It is possible to support different authentication methods for different users as the sp085_users.auth_type field is per user

LDAP Server

Configuration of the LDAP Server is defined via the sp083_system_parameters LDAP_URL, LDAP_version & LDAP_DN (14.1 Access Control).

Adding a new user

A list of users who can use ServiceManager and the Gantt is held in the ServiceScheduling database table sp085_users.

To create an entry for a new user use ServiceManager, or use an appropriate script. Entries are required in both Database sp085_users and Database sp088_user_units, the latter to tell the system which units (BRU,DRU, FRU) the user is to have access to.

ServiceGANTT Access Controls

ServiceGANTT access control centres on the setting up of profiles. Each profile defines which operations can be performed.  Each user is assigned to one of the available profiles (which define a set of permissions) and either a responsibility unit or a set of teams to which that set of permissions apply.  Profiles are defined in the ServiceScheduling database tables Database sp214_application_permissions and Database sp084_user_profiles.

It is possible to change the permissions that apply to each profile, including the default permissions that they have to entities outside their home domain.  The permissions described here are the default ones, and the ones which are probably the most sensible for most sites. ServicePower consultants might change these permissions as part of system set-up.

ServiceGANTT allows access to other ServiceScheduling Web applications if appropriately configured. This is done as follows:

Access to the Interactive Map

To enable access to the interactive map a profile must have:

-           ‘M’ privilege for the operation gantt.interactivemap.

-           ‘M’ privilege for gantt.svm.planner (i.e. permission to access planner)*.

-           ‘M’ privilege for gantt.svm.manager (i.e. permission to access SERVICEManager)*.

Note that these privileges belong to the gantt.svm group so ‘M’ privilege for this can be used instead (although this will also give access to Analytics – gantt.svm.analytics, GPS - gantt.svm.GPS and ABS - gantt.svm.abs unless they are explicitly set with a lower privilege).

ServiceScheduling Passwords

The Client Password System

By default, the Client Password is simply the part of the database connection string defined to be the password (and is database specific).  However, this can be overridden by setting up the database table Database sp430_client_types, thus allowing you to set up a different password for each of the different client types. 

To enable individual users to each have their own distinct password, set up the Database sp085_users table appropriately.  There is an entry here for each user, and the password field will initially be NULL.  This means that the password required will default to the client type password as set up in Database sp430_client_types.  To override this setting for individual users:

SQL
update sp085_users set password = '<user password>', auth_type = 'INTERNAL' where user_id = '<required user id>';

Once the above has been executed, the 14.1 spsecure utility must be run to hash the plain text password, and set the INTERNAL authentication to the supported SECURED type.


In summary, the password system for the each client type acts as a hierarchy with each level defaulting to the value of the next level :

SQL
IF <user entry in sp085> ELSE IF <clienttype entry in sp430> ELSE <database schema password>

Single password for all users

To enable all users of a given client type to use the same single password (other than the default), alter the value for the entry for that client type via SQL e.g, for ServiceGantt the SQL would be:

SQL
update sp430_client_types set password = '<your password>' where client_type = 3;

Once the above has been executed, the 14.1 spsecure utility must be run to hash the plain text password, and set the INTERNAL authentication to the supported SECURED type.

Initial sp430_client_types table



No

Description

Password

1

'API'

Null

2

'DAA'

Null

3

'Gantt'

Null

4

'APIproxy'

Null


This means that all client types use the database schema password.

HP-UX

HPUX can associate a group with a list of privileges, thus providing access to certain system capabilities for members of a particular group or groups. The privileges can be displayed with the "getprivgrp" command.

Implicitly, the super-user has ALL privileges. This allows some (slight) relaxing of UNIX's 'all or nothing' approach to distributing privileged capabilities. Privileged groups are an HP-UX-specific feature. 

CHOWN

Note that, by default, CHOWN is granted globally, but it is recommended that CHOWN be disabled globally!

ServiceOptimizer must have the privilege RTSCHED (see "man 1M setprivgrp" for a list of available privileges).

RTSCHED can be granted globally to all users of the machine or to just a specific group or groups.

To grant privileges the file "/etc/privgroup" needs to be created or edited. To disable CHOWN globally and to grant RTSCHED globally then /etc/privgroup should contain the 2 lines: 
-n CHOWN
-g RTSCHED 


To disable CHOWN globally and to grant RTSCHED to group spower then /etc/privgroup should contain the 2 lines: 
-n CHOWN
spower RTSCHED

 
Once /etc/privgroup is OK then apply them with: 
"/sbin/init.d/set_prvgrp start" 


Any changes to /etc/privgroup can be applied by re-running the above command. Type "getprivgrp" to check they have been applied OK. 


The settings persist through a reboot because /sbin/rc1.d/S400set_prvgrp is a link to /sbin/init.d/set_prvgrp