2 User Management – Basic Topics
This chapter provides information about the user management capabilities in VoiceObjects, and how to make best use of them to manage an installation.
Introduction
Application development usually takes place in teams. Some team members build the core dialog flow, others provide the back-end connectivity, and still others test the application to find problems and to evaluate user acceptance. Once the application is deployed, there are usually separate team members who monitor and control the operations.
User management in VoiceObjects provides the capability to create and maintain individual user accounts for all team members, and to assign roles to them that match their responsibilities in the application lifecycle. Access can be restricted to only those functions and views that team members need to do their job.
User accounts are represented by User objects in VoiceObjects. User objects are displayed in the User folder below the Configuration folder in the Repository Browser. In Desktop for Web the Configuration folder can be found in the Object Browser.
VoiceObjects supports different process approaches to managing users within an installation. For details, refer to the paragraph on User Management Process Options.
VoiceObjects also supports multi-tenant environments through the concept of sites. Each tenant corresponds to a single site, and different sites are kept separate from each other. For details, refer to Chapter 3 – User Management - Managing Sites.
For security purposes, it is possible to audit user actions separately for VoiceObjects Desktop, VoiceObjects Server, and Web Services Interface operations.
First Steps
This paragraph explains the first steps to take in a new or upgraded VoiceObjects installation. It describes the basic tasks that are required to create and configure the set of users and roles you need to work within the VoiceObjects platform.
8 Caution: If you need to configure a multi-tenant environment, make sure to read Chapter 3 – User Management - Managing Sites after you have familiarized yourself with the basics of user management.
New installation
After a fresh installation of VoiceObjects, a single user voadmin with password manager and role Server Administrator is created (though you may change the password during the installation process).
As a first step after installation, make sure to log in and change the password for this user if you have not done so during the installation. For further information on how to change passwords see the paragraph Change passwords.
8 Caution: Keep the Server Administrator password in a safe place. If you lose it and cannot log in as a Server Administrator anymore, your VoiceObjects installation may become unmanageable.
After having changed the password for voadmin, you may proceed by creating additional users as required. For details, see the paragraph Configuring a New User.
Refer to the paragraph on User Management Process Options for details on the different approaches that can be taken to managing users within an installation.
@8 Tip: We strongly recommend to create a second user with a Server Administrator role, and to use this second user for all normal administration tasks. The voadmin account should only be used in emergency situations.
Upgrade an existing installation
Upgrading from VoiceObjects 6 or VoiceObjects 7 does not require manual operations.
When upgrading from VoiceObjects X5, all existing users will remain as they are. Root Site Administrators will have a new Site Settings section on the Security section. For details, refer to Chapter 3 – User Management - Managing Sites.
As a first step after the upgrade, make sure to log in and change the password for the Server Administrator voadmin.
8 Caution: Keep the password of the Server Administrator in a safe place. If you lose it and cannot log in as a Server Administrator anymore, your VoiceObjects installation may become unmanageable.
After having changed the password for voadmin, you may proceed by creating additional users as required. Also, assign appropriate roles and passwords to the user accounts that were upgraded from the existing installation. For details, see the paragraph Configuring a New User.
@8 Tip: We strongly recommend to create a second user with a Server Administrator role, and to use this second user for all normal administration tasks. The voadmin account should only be used in emergency situations.
User Roles
VoiceObjects supports nine user roles that represent different tasks within a project or an installation. As a matter of best practice, each task should be performed with the lowest role that is capable of it.
Reviewer
Reviewers have read-only access to projects to inspect and review applications without making changes. They do not have access to the Control Center and cannot change any configuration settings.
A Reviewer is typically responsible for making sure that certain guidelines are followed in building applications. Reviewers can attach annotations to project versions to document their findings. These annotations cannot be changed by other users.
Designer
Designers work within projects to create and maintain applications. They do not have access to the Control Center or to configuration settings.
A Designer is typically responsible for the Voice User Interface (VUI) design of an application, and for assembling the dialog flow. Since Designers do not have access to the operations control provided by VoiceObjects, they need the help of a user with a Service Controller or higher role to deploy changes they have made to an application.
Service Controller
Service Controllers are Designers who may also manage specific services. They have limited access to the Control Center and to configuration settings.
A Service Controller is typically responsible for both building and testing an application. Service Controllers have all the rights of a Designer, and may also deploy a given set of services (typically in a development environment).
Observer
Observers have read-only access to the Control Center to inspect and review deployments. They do not have access to projects and cannot modify any objects.
An Observer is typically responsible for monitoring deployments without interfering with them. Observer roles on a production environment may be given to developers so they can spot problems and assist in troubleshooting without the risk of making unintentional modifications.
Site Controller
Site Controllers manage the deployment aspects of a specific site (for details, see Chapter 3 – User Management - Managing Sites). They have access to the server and service configuration settings for their site, but they are not allowed to manage users.
A Site Controller is typically responsible for operating a given set of servers and services for one site, which may correspond to a tenant in a managed services environment, a department in an enterprise, etc. Site Controllers only have access to the Control Center and cannot themselves make any changes to applications.
Site Controllers can only be created by Site Administrators, which implies that they can only exist in custom sites (and not in the system site).
Site Administrator
Site Administrators manage all aspects of a specific site, including users (for details, see Chapter 3 – User Management - Managing Sites). They have full access to all configuration settings for their site.
A Site Administrator is typically responsible for managing a site, which may correspond to a tenant in a managed services environment, a department in an enterprise, etc. Site Administrators create users, services, and servers. They may work on projects, but typically this would be delegated to lower roles.
Server Controller
Server Controllers manage the deployment aspects of a VoiceObjects installation. They have access to the server and service configuration settings, but they are not allowed to manage users.
A Server Controller is typically responsible for operating all servers and services in an installation, across all sites. Server Controllers only have access to the Control Center and cannot themselves makes any changes to applications.
User Manager
User Managers create and maintain User objects within a site or within an entire VoiceObjects installation. They do not have access to projects, the Control Center, or server and service configuration settings.
A User Manager is typically responsible for creating and maintaining the set of users working within a VoiceObjects installation.
Server Administrator
Server Administrators have full access to all aspects of a VoiceObjects installation.
A Server Administrator is typically responsible for managing an entire installation, across all sites. Site Administrators create users, sites, services, and servers. They may work on projects, but typically this would be delegated to lower roles.
Relationships
The following diagram illustrates the relationships between the different user roles:
Service Controllers have all the privileges of a Designer, as well as access to specific services in the Control Center. Thus, the Service Controller role is a direct extension of the Designer role. Reviewers on the other hand are restricted Designers with read-only access to projects.
The higher controller roles (Site Controller, Server Controller) differ from this in that they do not have access to projects. They focus solely on operations, and may only access the Control Center. There, however, they have full access to all servers and services either within their site (for Site Controllers), or within the entire installation (for Server Controllers).
Observers have the same scope of access as Server Controllers or Site Controllers, but in a read-only mode to facilitate a pure monitoring of deployments.
The administrator roles combine all access of Designers and Controllers, and add the capability to create new users. Administrators have complete control over either their site (for Site Administrators), or the entire installation (for Server Administrators).
The User Manager role provides the ability to cleanly separate responsibilities between development, deployment, and access management. It also offers an additional level of security by means of a built-in cross-check and validation mechanism.
Configuring a New User
Only Server Administrators, User Managers, and Site Administrators have the permission to create a new user.
To create a new user, do the following:
In the Object Palette, open the Configuration folder and double-click User. The User editor will open up in the editor area.
In Desktop for Web you open up the User editor by selecting Configure New User from the Tools menu.
The Definition section of the User editor provides two sections for configuring the User Credentials and Audit Trail Options.
The Name of the User object is the name shown for the user within VoiceObjects Desktop. It corresponds to a user’s full name (e.g. “John Smith”).
User Credentials
The User ID is the login name for the user (e.g. “jsmith”). It is used together with the Password e.g. when entering VoiceObjects Desktop, or when controlling VoiceObjects Server through the Command Line Interface (CLI) or the Web Services Interface (WSI).
i8 Note: User IDs must be unique within the repository, across all sites. Also, user IDs must not be the same as server reference IDs or VSNs (VoiceObjects Service Names). Finally, user IDs must not contain blanks or special characters other than underscores.
In the E-mail field, specify the user’s e-mail address. Note that the e-mail address is mandatory when using automatically generated passwords. For details refer to the paragraph on User Management Process Options.
Select the appropriate User role from the drop-down list. The description field below provides a brief description of the currently selected role.
The drop-down field Account status can be used to activate or deactivate a User object. For more details, refer to the paragraph Modifying an Existing User below.
8 Caution: When a User Manager creates a new user or modifies an existing user, this user’s account status is automatically set to Inactive. The user account must be re-activated by a different User Manager or by an Administrator. This serves the security purpose of cross-checking any User Manager action on user accounts.
From the drop-down list Password change, select how to manage the user’s password. Next login, the default, indicates that the user must change the password with the next login. Allowed indicates that the user may, but does not need to, change the password. Not allowed indicates that the user cannot change the password. For more details see the paragraph on Password Policies.
By default, Designers and Service Controllers are allowed to create new projects. To prevent them from creating projects, clear the check box Allow project creation. Note that for all other user roles, this check box has no effect since Reviewers and Observers cannot create any objects, Controllers and User Managers cannot access projects, and Administrators are always allowed to create new projects.
By default, all users are allowed to access the Web Services Interface (WSI). To prevent them from accessing the WSI, clear the check box Allow WSI access.
8 Caution: Desktop for Eclipse relies on the Web Service Interface, so users without WSI access will not be able to use Desktop for Eclipse in network mode.
For more information on the Audit Trail Options, refer to the Audit Trail Options paragraph below.
If the newly created user is the root Site Administrator of a new custom site, additional settings relating to the site can be made in the Security section. For more information, refer to Chapter 3 – User Management - Managing Sites.
Modifying an Existing User
To prevent accidental corruption of a VoiceObjects installation, users cannot save or delete their own User object.
Other user accounts can either be temporarily deactivated, or permanently deleted.
Deactivate users
A user account can be temporarily deactivated by setting the Account status to Inactive. Server or Site Administrators and User Managers may do this in the User editor.
If a User object is set to Inactive its object name is grayed out and displayed in italic style in the Repository Browser.
In Desktop for Web a deactivated User object is displayed in the Object Browser with a Disabled icon 
in front of it.
To re-activate the user account, set its status back to Active in the User editor.
i8 Note: A user account may also be disabled by the VoiceObjects platform if the number of failed login attempts in a row reaches the limit defined by the <allowedLoginAttempt> setting in the components.xml configuration file. The default value is 3. For more information, refer to Failed login attempts in the paragraph on Password Policies.
8 Caution: When a User Manager modifies an existing user, this user’s account status is automatically set to Inactive. The user account must be re-activated by a different User Manager or by an Administrator. This serves the security purpose of cross-checking any User Manager action on user accounts.
Delete users
A user account can be deleted by right-clicking the corresponding User object and selecting Delete from the context menu.
Note that deleting a User object does not completely remove it from the repository, but merely sets its status to deleted. This is done in order to keep object ownership relations intact.
Only Server Administrators, Site Administrators, and User Managers may delete user accounts.
A User object representing a deleted user is shown with a Deleted icon 
in front of it. Only Server Administrators can see deleted users.
When deleting a user account, a timestamp is appended to its user ID and to its name. This provides a reference when the User object was deleted, and ensures that a new user account with the same user ID or name as the deleted one can be created.
Depending on the overall number of projects and users managed by your Metadata Repository the number of deleted User objects may grow over time. As deleted User objects are still shown in the Repository Browser, Desktop for Eclipse provides a way to filter them out. In order to activate this filter mechanism, do the following:
Bring the Repository Browser to the front. Click the Menu button 
in the upper right corner, then Filter, and then Hide Deleted User Objects.
Note that this filter mechanism is only available when using Desktop for Eclipse.
8 Caution: When deleting users, make sure to always retain at least one active Server Administrator. Failure to do so will result in an unmanageable VoiceObjects installation. The best precaution is to never use the initial voadmin account, and to never make any changes to it after the initial password change.
As a security precaution, the voadmin account itself cannot be deleted.
Modify user roles
After users have initially been created, their role may be modified within certain limits. These limits depend on whether the user comes from the system site or from a custom site. For more information on sites, refer to Chapter 3 – User Management - Managing Sites.
Users from the system site
Roles of users belonging to the system site can only be changed in such a way that they continue to belong to the system site. This implies that they cannot be assigned a role of Site Administrator or Site Controller.
The set of roles available within the system site is Server Administrator, User Manager, Server Controller, Observer, Service Controller, Designer, and Reviewer.
8 Caution: When modifying the role of a Server Administrator, make sure to always retain at least one active Server Administrator. Failure to do so will result in an unmanageable VoiceObjects installation.
As a security precaution, the role of voadmin cannot be modified.
Users from a custom site
Roles of users belonging to a custom site can only be changed in such a way that they continue to belong to the same custom site. This implies that they cannot be assigned a role of Server Administrator or Server Controller.
The set of roles available within a custom site is Site Administrator, User Manager, Site Controller, Observer, Service Controller, Designer, and Reviewer.
The role of the root Site Administrator who defines the custom site cannot be changed.
Change passwords
To change your own password, select Change Password from the VoiceObjects menu in Desktop for Eclipse. In Desktop for Web select Change Password from the Tools menu.
This entry is only available if the Password change option is set to Allowed or Next login for your user account.
The Change Password window comes up:
Enter the old (current) password and then the new one. To avoid problems caused by typos, repeat the new password to confirm it. To activate the new password, click Change. To close the window without changing the password, click Cancel. For further information, click the Help button 
.
i8 Note: Sometimes users are required to change their password immediately upon login, e.g. after their account has initially been created or after a password reset (using the default settings). In these cases the Change Password window comes up automatically after login.
To change another user’s password, Server Administrators, Site Administrators, and User Managers may open the corresponding User object and type in a new password. This would typically be used to reset a forgotten password.
There is also the option to automatically create passwords and send them to users by e-mail. For details, refer to the paragraph on User Management Process Options.
Audit Trail Options
Auditing allows administrators to track user activity, and to identify suspicious behavior. Auditing can be configured on a per-user basis, and individually for VoiceObjects Desktop, VoiceObjects Server, and the Web Services Interface.
Configuration is done in the Audit Trail Options section of the User editor.
The drop-down fields for VoiceObjects Desktop, VoiceObjects Server, and Web Services Interface offer three levels of auditing:
· None
No audit data is written. This is the default for VoiceObjects Desktop.
· Denied
Only user activities that were denied due to insufficient privileges are written to the audit log files. This is the default for VoiceObjects Server and Web Services Interface.
Note that due to filtering in the Control Center (see Control Center Filtering below) such denied activities can only be attempted through the Command Line Interface or the Web Services Interface (see the Deployment Guide for details).
· All
All user activities are written to the audit log files. Note that in case of VoiceObjects Desktop this may lead to large amounts of data.
For the standard Server Administrator account voadmin this is the default setting for all three interfaces (VoiceObjects Desktop, VoiceObjects Server, and Web Services Interface) so that access using this account can be tracked. Keep in mind that this account should not be used for routine administration tasks.
Audit log information is written to the file SRV_AuditTrail.log in the same location as other server log files, and can be accessed via the Server Logs section in the Control Center. Note that the server instance that is master server manager writes the data. For more information, refer to the Deployment Guide.
The lines below show three sample entries from the audit log file. Each entry contains the following elements:
· Timestamp indicating when the entry was written
· IP address from which the request was made
· User ID of the user who made the request
· Role of the user who made the request
· Site ID for the respective User object
The site ID is the GUID of either the user voadmin (for users from the system site), or the GUID of the root Site Administrator (for users from a custom site).
This information may be used to separate audit log entries for different sites in a multi-tenant environment.
· Message describing the activity itself
2008-01-26 10:28:13:752 [127.0.0.1] [jsmith] [ServiceController] [0.0.0:OVAPac1617ae0000000000000056000001016084cbc4_UO_User]: User 'jsmith' logged in.
2008-01-26 10:32:53:283 [172.22.23.174] [jsmith] [ServiceController] [0.0.0:OVAPac1617ae0000000000000056000001016084cbc4_UO_User]: Executing command 'stop' [ DENIED ]
The first entry indicates that a user with ID “jsmith” has logged into VoiceObjects Desktop.
The second entry indicates that this user tried to stop a server, and that this request was denied.
Auditing is typically used to track activity in production deployments, or to detect manipulation attempts. This relates primarily to VoiceObjects Server activity.
Note that when tracking all activity on VoiceObjects Desktop, this may lead to large amounts of audit log data.
Access Control
User access can be controlled on projects, libraries, servers, services, and users.
By default, the following users have access to objects:
· The object’s owner has full access, regardless of his role
· Server Administrators have full access to all objects in a VoiceObjects installation
· User Managers from the system site have full access to all User objects in a VoiceObjects installation
· Server Controllers have full access to all Service and Server objects in a VoiceObjects installation
· Observers from the system site have read-only access to all Service and Server objects in a VoiceObjects installation
· Site Administrators have full access to all objects within their custom site
· User Managers from a custom site have full access to all User objects within their custom site
· Site Controllers have full access to all Service and Server objects within their custom site
· Observers from a custom system site have read-only access to all Service and Server objects within their site
To provide additional users with access, they need to be added to the object’s access control list (ACL). The ACL can be specified in the corresponding editor of a project, library, server, service, or user. Open the respective editor and switch to the Security section.
Add the users you want to invite to the ACL of the respective object.
For information on how to add objects to a list refer to the relevant chapters in the Desktop for Eclipse Guide or Desktop for Web Guide.
Users who are not allowed to edit User objects (i.e. any role other than Server Administrator, Site Administrator, or User Manager) are still able to view all existing User objects and to add them to the ACL.
As a convenience, the user group Everyone is provided. This group always refers to all users within the respective site. Thus, e.g. if a Designer in a custom site creates a new project and invites Everyone to it, then every other user within this site has access to this project.
Users who are invited to access a project, library, server, service, or user, but who do not belong to the privileged group described above, will not be able to access the Security section. In particular, they will not be able to invite additional users to access the project, library, server, service, or user, nor to delete it.
For root Site Administrators of custom sites, the Security section also provides an additional section Site Settings. For more information on sites, refer to Chapter 3 – User Management - Managing Sites.
Desktop Filtering
Depending on a user’s role, VoiceObjects Desktop allows or denies access to certain components, menu entries, etc. The following paragraphs describe what is accessible to the nine available roles.
Two overview tables at the end summarize the access rights both for Desktop for Eclipse and for Desktop for Web.
Server Administrators
Server Administrators have full access to all components of VoiceObjects Desktop. They can see all projects, libraries, servers, services, and users.
In Desktop for Web Server Administrators may decide upon login to either open a project, or to enter the Control Center mode in which only the Configuration folder is available in the Object Browser.
User Managers
User Managers have full access to all User objects within a site or within an installation, depending on whether they belong to a custom site or to the system site.
In Desktop for Web User Managers are automatically routed to the Control Center upon login, since they cannot access projects or libraries.
Server Controllers
Server Controllers can see all servers and services. They do not have access to the project-related entries in the menu bar.
In Desktop for Web Server Controllers are automatically routed to the Control Center upon login, since they cannot access projects or libraries.
Site Administrators
Site Administrators have access to all components of VoiceObjects Desktop that are not directly related to the installation itself (such as license configuration). They can access all projects, libraries, servers, services, and users within their own site. In addition, they have limited access to servers and services from the system site that they have been invited to.
In Desktop for Web Site Administrators may decide upon login to either open a project, or to enter the Control Center mode in which only the Configuration folder is available in the Object Browser.
Site Controllers
Site Controllers can access all servers and services within their own site. In addition, they have limited access to servers and services from the system site if they have been invited to them. They do not have access to the project-related entries in the menu bar.
In Desktop for Web Site Controllers are automatically routed to the Control Center upon login, since they cannot access projects or libraries.
Observers
Observers have read-only access to all servers and services within their site or within the installation, depending on whether they belong to a custom site or to the system site. They do not have access to the project-related entries in the menu bar.
In Desktop for Web Observers are automatically routed to the Control Center upon login, since they cannot access projects or libraries.
Service Controllers
Service Controllers have access to their own projects, libraries and services, and to those they have been invited to.
In Desktop for Web Service Controllers can see Server objects if they have been invited to them (so they can open the corresponding Control Center), but they cannot edit these objects. Upon login they may decide to either open a project, or to enter the Control Center mode in which only the Configuration folder is available in the Object Browser.
Designers
Designers have access to all components of VoiceObjects Desktop that are related to working with projects. They cannot access the Control Center nor servers, services or users.
In Desktop for Web they do not see the Configuration folder in the Object Browser.
Reviewers
Reviewers have read-only access to all components of VoiceObjects Desktop that are related to working with projects. They cannot access the Control Center nor servers, services or users and do not see the Configuration folder.
Overview: Desktop filtering in Desktop for Eclipse
The following table summarizes the menu access rights for the various user roles.
· “X” indicates that the menu entry is accessible.
· “O” indicates that the entry is accessible under certain circumstances, for instance if the user has opened a project version already.
· An empty cell indicates that the entry is not accessible or if the entry is available that the user does not have the right to open the corresponding view.
|
|
Reviewer |
Designer |
Service Controller |
Observer |
Site Controller |
Site Administrator |
Server Controller |
User Manager |
Server Administrator |
|
VoiceObjects |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Import |
|
O |
O |
|
|
X |
|
|
X |
|
Export Project Version |
X |
X |
X |
|
|
X |
|
|
X |
|
Project Documentation |
X |
X |
X |
|
|
X |
|
|
X |
|
Storyboard Export |
X |
X |
X |
|
|
X |
|
|
X |
|
Change Password |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Configure Licenses |
|
|
|
X |
|
|
X |
|
X |
|
Enter Reviewer Annotation |
X |
|
|
|
|
|
|
|
|
|
Optimize Embedded Database (*) |
|
|
|
|
|
|
|
|
|
|
Window |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Show View - |
|
|
X |
X |
X |
X |
X |
|
X |
|
Show View - |
|
|
|
X |
X |
X |
X |
|
X |
|
Show View - |
|
|
|
|
|
X |
|
X |
X |
|
Show View - |
|
X |
X |
|
X |
X |
X |
X |
X |
|
Show View - |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Help |
X |
X |
X |
X |
X |
X |
X |
X |
X |
(*) = This menu entry is only available when working in standalone mode.
Overview: Desktop filtering in Desktop for Web
The following table summarizes the menu access rights for the various user roles.
· “X” indicates that the menu entry is accessible.
· “O” indicates that the entry is accessible if the user has the optional right to create new projects.
· An empty cell indicates that the entry is not accessible.
|
|
Reviewer |
Designer |
Service Controller |
Observer |
Site Controller |
Site Administrator |
Server Controller |
User Manager |
Server Administrator |
|
File |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
New Project |
|
O |
O |
|
|
X |
|
|
X |
|
Open Project |
X |
X |
X |
|
|
X |
|
|
X |
|
Configure Project |
X |
X |
X |
|
|
X |
|
|
X |
|
Publish Project Version |
|
O |
O |
|
|
X |
|
|
X |
|
Open Project Version |
X |
X |
X |
|
|
X |
|
|
X |
|
Export Project Version |
X |
X |
X |
|
|
X |
|
|
X |
|
Configure Project Version |
X |
X |
X |
|
|
X |
|
|
X |
|
Enter Reviewer Annotation |
X |
|
|
|
|
|
|
|
|
|
Exit |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
New |
|
X |
X |
|
|
X |
|
|
X |
|
Objects |
|
X |
X |
|
|
X |
|
|
X |
|
Tools |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Import Object from File |
|
X |
X |
|
|
X |
|
|
X |
|
Import Object from Browser Clipboard |
|
X |
X |
|
|
X |
|
|
X |
|
Audio File Registration |
|
X |
X |
|
|
X |
|
|
X |
|
Search Objects |
X |
X |
X |
|
|
X |
|
|
X |
|
Search Unused Objects |
X |
X |
X |
|
|
X |
|
|
X |
|
Change Password |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Configure New Server |
|
|
|
|
X |
X |
X |
|
X |
|
Configure New Service |
|
|
X |
|
X |
X |
X |
|
X |
|
Configure New User |
|
|
|
|
|
X |
|
X |
X |
|
Configure Licenses |
|
|
|
X |
|
|
X |
|
X |
|
VoiceObjects Analyzer |
|
X |
X |
X |
X |
X |
X |
X |
X |
|
Project Documentation |
X |
X |
X |
|
|
X |
|
|
X |
|
Storyboard Export |
X |
X |
X |
|
|
X |
|
|
X |
|
Voxeo Prophecy Hosting |
|
X |
X |
|
X |
X |
X |
|
X |
|
View |
|
X |
X |
X |
X |
X |
X |
X |
X |
|
Refresh |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Project Homepage |
X |
X |
X |
X |
|
X |
|
X |
X |
|
Desktop Logging |
|
|
|
X |
X |
X |
X |
|
X |
|
Desktop Sessions |
|
|
|
|
|
X |
|
X |
X |
|
Help |
X |
X |
X |
X |
X |
X |
X |
X |
X |
Control Center Filtering
Depending on a user’s role, the Control Center allows or denies access to certain components, menu entries, etc. The following paragraphs describe what is accessible to the nine available roles.
Two overview tables at the end summarize the access rights both for Desktop for Eclipse and for Desktop for Web.
Note that the set of server control functions allowed by the Command Line Interface (CLI) corresponds exactly to those allowed by the Control Center. For more information, refer to the Deployment Guide.
Server Administrators
Server Administrators have full access to all components of the Control Center. They see all servers, all services, and all users. In addition, they have access to all server and service log files.
User Managers
User Managers do not have any access to the Control Center.
Server Controllers
Server Controllers can see all servers, all services, and have access to all server and service log files.
In Desktop for Web Server Controllers are automatically routed to the Control Center upon login, since they cannot access projects or libraries.
Site Administrators
Site Administrators have access to all servers, services, and users within their site. They can see the servers and services from the system site that they are invited to.
On servers from within their own site, Site Administrators have access to all server and server instance commands.
On servers from the system site, Site Administrators may only use the server command Reload Service List, and none of the instance commands.
On services from the system site, Site Administrators may not modify the communication parameters. For more details, refer to Chapter 2 – Configuring Servers and Services in the Deployment Guide.
In Desktop for Web Site Administrators upon login may either open a project or go directly to the Control Center.
Site Controllers
Site Controllers have access to all servers and all services within their site. They can see the servers and services from the system site that they are invited to.
On servers from within their own site, Site Controllers have access to all server and server instance commands.
On servers from the system site, Site Controllers may only use the server command Reload Service List, and none of the instance commands.
On services from the system site, Site Controllers may not modify the communication parameters. For more details, refer to Chapter 2 – Configuring Servers and Services in the Deployment Guide.
In Desktop for Web Site Controllers are automatically routed to the Control Center upon login, since they cannot access projects.
Observers
Observers have read-only access to the Control Center.
Service Controllers
Service Controllers have access to their own services, as well as to services they are invited to.
On services they are invited to, Service Controllers may not modify the communication parameters. For more details, refer to Chapter 2 – Configuring Servers and Services in the Deployment Guide.
In Desktop for Web Service Controllers upon login may either open a project or go directly to the Control Center.
@8 Tip: Note that Service Controllers need to be invited to the respective servers before they can administer their own services. Service Controllers may not open Server objects in the editor, and thus cannot make any changes to the settings.
Designers
Designers do not have any access to the Control Center.
Reviewers
Reviewers do not have any access to the Control Center.
Overview: Control Center filtering in Desktop for Eclipse
The following table summarizes the Control Center access rights for the various user roles that have access to it.
· “X” indicates that the menu entry is accessible.
· “O” indicates that the entry is accessible if the corresponding Server object belongs to the same site as the user.
· An empty cell indicates that the entry is not accessible.
|
|
Service Controller |
Observer |
Site Controller |
Site Administrator |
Server Controller |
Server Administrator |
|
Server Manager |
X |
X |
X |
X |
X |
X |
|
Server Context Menu |
|
X |
X |
X |
X |
X |
|
Edit |
|
X |
X |
X |
X |
X |
|
Reload Service List |
|
|
X |
X |
X |
X |
|
Commands |
|
|
O |
O |
X |
X |
|
Options |
|
|
O |
O |
X |
X |
|
Details |
X |
X |
X |
X |
X |
X |
|
Server Instance Context Menu |
X |
X |
X |
X |
X |
X |
|
Commands |
|
|
O |
O |
X |
X |
|
Details |
X |
X |
X |
X |
X |
X |
|
Service Manager |
X |
X |
X |
X |
X |
X |
|
Service Context Menu |
X |
X |
X |
X |
X |
X |
|
Commands (all) |
X |
|
X |
X |
X |
X |
|
Server Logs |
X |
X |
X |
X |
X |
X |
|
Log files |
|
X |
X |
X |
X |
X |
|
Service Logs |
X |
X |
X |
X |
X |
X |
|
Log files |
X |
X |
X |
X |
X |
X |
|
Session Tracing |
X |
X |
X |
X |
X |
X |
|
Trace files |
X |
X |
X |
X |
X |
X |
|
Session Partitioning |
|
X |
X |
X |
X |
X |
Overview: Control Center filtering in Desktop for Web
The following table summarizes the Control Center access rights for the various user roles that have access to it.
· “X” indicates that the menu entry is accessible.
· “O” indicates that the entry is accessible if the corresponding Server object belongs to the same site as the user.
· An empty cell indicates that the entry is not accessible.
|
|
Service Controller |
Observer |
Site Controller |
Site Administrator |
Server Controller |
Server Administrator |
|
Server Management |
X |
X |
X |
X |
X |
X |
|
Server Context Menu |
|
|
X |
X |
X |
X |
|
Edit |
|
|
X |
X |
X |
X |
|
Reload Service List |
|
|
X |
X |
X |
X |
|
Commands |
|
|
O |
O |
X |
X |
|
Options |
|
|
O |
O |
X |
X |
|
Properties |
|
X |
X |
X |
X |
X |
|
Server Instance Context Menu |
|
|
O |
O |
X |
X |
|
Commands |
|
|
O |
O |
X |
X |
|
Service Context Menu |
X |
|
X |
X |
X |
X |
|
Commands (all) |
X |
|
X |
X |
X |
X |
|
Server Logging |
X |
X |
X |
X |
X |
X |
|
Log files |
|
X |
|
|
X |
X |
|
Service Logging |
X |
X |
X |
X |
X |
X |
|
Log files |
X |
X |
X |
X |
X |
X |
|
Session Tracing |
X |
X |
X |
X |
X |
X |
|
Trace files |
X |
X |
X |
X |
X |
X |
|
Session Partitioning |
|
X |
X |
X |
X |
X |
Monitoring Desktop Sessions
VoiceObjects Desktop works on the basis of a concurrent sessions licensing model. Multiple users with different roles may be logged in at the same time.
The number of concurrent sessions is limited as defined in the license key. In order to release a session VoiceObjects Desktop has to be closed properly. In Desktop for Web users have to logout using the Exit command from the File menu to successfully release their session. Otherwise all user sessions are maintained until a timeout occurs.
To prevent accidental timeouts during normal work, the timeout threshold is typically set to several hours. Thus the situation may arise that no more concurrent session licenses are available, even though not all of the existing sessions are really used.
To remedy such situations, Server Administrators, Site Administrators, and User Managers can access an overview of existing Desktop sessions. Site Administrators and User Managers from a custom site see Desktop sessions for users from their site only, while Server Administrators and User Managers from the system site see all active Desktop sessions.
To open the Desktop Sessions, select Show View from the Window menu and click Desktop Sessions.
In Desktop for Web the Desktop Sessions can be opened by selecting the Desktop Sessions command in the View menu.
The list shows the currently active Desktop sessions along with the corresponding user name and role, IP address from which the login occurred, the session type (showing if the user is using Desktop for Eclipse or Desktop for Web) and a timestamp indicating the most recent activity in this session. Sessions in which the most recent activity occurred several hours ago are probably abandoned and can be terminated by selecting Kill Session from their context menu. In Desktop for Web sessions can be terminated using the End session button.
To ensure that abandoned sessions may be freed up if required, VoiceObjects Desktop always provides one additional Server Administrator or User Manager session over and above the number of sessions defined in the license key.
Password Policies
VoiceObjects supports the definition of password policies covering the format of allowed passwords, rules on how and when to change passwords, and security mechanism to prevent unauthorized login attempts.
For a comprehensive discussion of different user management processes, including advanced options for password creation, see the paragraph on User Management Process Options.
Password patterns
To ensure that user-defined passwords meet certain security standards, password patterns can be defined that need to be met by new or changed passwords. This is done by providing one or more regular expressions that are used to validate new or changed passwords.
Patterns can be configured within the <passwordPatterns> element in the file components.xml, which also allows for a descriptive comment that is shown to users when passwords they enter do not meet the requirements. Each pattern is defined within a single <passwordPattern> entry. New or modified passwords must match all of the defined patterns simultaneously.
To also enable the use of negative patterns, the optional attribute match=”false” can be used to define patterns that must not match. An example can be found below for the use of user names or user IDs in passwords.
Examples for frequently used patterns are:
· Password must have a certain length
Mininum and maximum lengths of passwords can be enforced, e.g. the following pattern indicates that the password must have at least 8 and at most 16 characters:
<passwordPattern>^.{8,16}$</passwordPattern>
· Password must contain at least one digit
Passwords can be enforced to contain (or not contain) certain types of characters. The following pattern indicates that the password must start with a letter and contain at least one digit:
<passwordPattern>^[A-Za-z]+.*[0-9]+.*$</passwordPattern>
· Password must contain at least one non-alphanumeric character
Similar to the one above, this pattern indicates that the password must start with a letter and contain at least one non-alphanumeric character:
<passwordPattern>
^[A-Za-z]+.*[#$%\+\&*?]+.*$</passwordPattern>
· Password must contain both upper and lower case characters
The following pattern ensures that the password starts with a letter and then contains both upper and lower case characters:
<passwordPattern>
^[A-Za-z]+.*([A-Z]+.*[a-z]+|[a-z]+.*[A-Z]+).*$</passwordPattern>
· Password must not be derived from user name or user ID
Users often have a tendency to use their user name, user ID, or a slight variation thereof as their password. The following pattern prevents this:
<passwordPattern match="false">
^.*(@USER_NAME@|@USER_ID@).*$</passwordPattern>
Control password change
Administrators and User Managers can define how users need to manage their passwords. There are three alternatives:
· The user is not allowed to change his password (Not allowed)
With this option the user is not able to change his password through any interface (Desktop for Eclipse/Web or Web Service Interface).
· The user is allowed to change his password (Allowed)
With this option, the user may change his password at any time, but is not required to do so.
· The user is required to change his password (Next login)
This is the default option. The next time the users logs in through any interface, he is prompted to change his password and cannot proceed before doing so. After this initial password change, the user is free to change his password at any time.
In addition to this setting on each individual User object, there are two installation-wide settings that control password expiration and password history.
By use of the setting <passwordExpiration> in components.xml it is possible to define the number of days after which a password needs to be changed. The default value is 0, meaning that passwords do not expire.
When a user’s password expires, he is required to change it the next time he logs in. Note that this also holds true when the setting described above indicates that the user is not allowed to change his password (since otherwise he would never be able to log in again).
i8 Note: Password expiration does not apply to the voadmin account.
The setting <passwordHistory> in components.xml enforces the use of different strings when changing a user’s password. A value of n indicates that the new password must not be equal to any of the preceding n passwords (including the current one). The default value is 0, meaning that the same password may be re-used.
Failed login attempts
By default VoiceObjects allows three failed login attempts in a row (with no successful login being performed in between). After the third failed login attempt the respective user account is disabled by the VoiceObjects platform and needs to be enabled by a Server/Site Administrator or User Manager before the corresponding user can login again.
In the case that the voadmin user account has been disabled it cannot be enabled again by any administrator; instead the following steps have to be performed by someone with access to the machine running VoiceObjects Desktop:
1. Shutdown the VoiceObjects Desktop process.
2. Set <enableVoadminAccount> in components.xml to true.
3. Restart the VoiceObjects Desktop process. The voadmin user account is now enabled again.
4. Reset the option <enableVoadminAccount> to false.
i8 Note: The tag <allowedLoginAttempts> within components.xml can be used to specify how many failed login attempts are allowed before the corresponding user account is disabled. The default value is 3.
Audit trail logging tracks all failed login attempts together with information about timestamp, user account, and the IP address the request came from. This allows administrators to analyze in detail whether these problems occur regularly.
User Management Process Options
This paragraph describes different options for structuring the user management process, depending on the need for security and separation of responsibilities.
Integrated user management
In environments with moderate security concerns, user management can be handled in an integrated fashion along with the general administration of the VoiceObjects installation. The appropriate user roles for this are Server Administrators and Site Administrators.
In this scenario, User objects are created and maintained by Server or Site Administrators. They can do this without additional checks or confirmations, and in addition to their development and deployment capabilities.
Starting from a fresh installation, the configuration steps for this process are as follows:
· Log in as voadmin and create a new Server Administrator.
· Log in as the new Server Administrator and create additional users as required.
· On an ongoing basis, use this or additional Server Administrators (except voadmin) to create or modify users.
Use the voadmin account only for emergencies, but make sure to keep its password in a safe place.
· Use either Server/Site Administrators or Server/Site Controllers for deployment tasks.
· Use Designers and Service Controllers for application development tasks and for testing.
Separated user management
In environments with high security concerns it is advisable to separate the management of users from the management of the installation. In this case, the appropriate user roles are User Managers on one side and Server Controllers or Site Controllers on the other side.
In this scenario, User objects are created and maintained by User Managers. This is their only task, and a modification made by one User Manager needs to be cross-checked and validated by a second User Manager. This prevents single User Managers from expanding their capabilities by creating users of other types (e.g. Designers or Server Controllers).
Starting from a fresh installation, the configuration steps for this process are as follows:
· Log in as voadmin and create at least two User Managers.
Do not use the voadmin account afterwards except in emergencies, but make sure to keep its password in a safe place.
· Log in as one of the User Managers and create additional users as required.
· Log in as a different User Manager and activate the newly created users so they can log in.
· On an ongoing basis use a set of User Managers to create or modify user accounts, and to cross-check and validate such modifications made by other User Managers.
· Use Server/Site Controllers for deployment tasks.
· Use Designers and Service Controllers for application development tasks and for testing.
Advanced password management
By default, passwords are assigned or re-set by Site or Server Administrators and User Managers. Users may then afterwards change their own passwords unless explicitly forbidden; see the paragraph on Password Policies.
As a more secure alternative to this process, it is possible to let the VoiceObjects platform generate initial or re-set passwords and deliver them to users by e-mail. These automatically generated passwords then need to be changed the first time a user logs in.
The e-mail connection to be used for sending passwords is configured in the EmailConfigurations.xml file:
<emailPasswordSenders>
<emailPasswordSender id="emailSender" enabled="true">
<from>PasswordAdmin@YourCompany.com</from>
<replyTo/>
<priority>normal</priority>
<smtpServer>SMTPServer.YourCompany.com</smtpServer>
<smtpPort>25</smtpPort>
<user>EmailSender</user>
<password>abc123</password>
</emailPasswordSender>
</emailPasswordSenders>
The entries <user> and <password> are optional depending on the configuration of your SMTP server.
When the e-mail sender connection is enabled (enabled="true") it implicitly switches on the automatic generation of passwords. By disabling it, the default mode of manually defined passwords can be restored.
i8 Note: When using automatically generated passwords, all users must have valid e-mail addresses configured within their User objects.
8 Caution: When upgrading from a previous version of VoiceObjects make sure that before enabling automatically generated passwords you complete the entire upgrade process (including the metadata upgrade of projects) and define valid e-mail addresses for all existing user accounts.
When e-mail sending is activated, e-mails are sent to users in the following situations:
· Account creation
An e-mail containing the automatically created initial password is sent to the user upon creation of the user account. The user needs to change this password upon initial login.
· Account activation
Users are informed when their previously inactive account has been activated, enabling them to log in.
· Account de-activation
Users are informed when their previously active account has been inactivated, preventing them from logging in.
· Password reset
An e-mail containing an automatically created replacement password is sent to the user when the password for the user account is reset (or modified). The user needs to change this password upon next login.
For additional details on passwords, see the paragraph on Password Policies.