Security

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

The ability to view or change certain pieces of information often must be restricted based on a user's role. For example, in a payroll application, an employee and manager both might be permitted to view the employee's salary, but only the payroll clerk has the permissions to change the salary in the application.

Permissions specify what kind of access a user has to information. For example, if a user has read permissions, the user can view or retrieve but not edit the data. Roles are groups of users. Assigning permissions to roles rather than directly to users is the preferred method for setting up security. It is easier to maintain and scale applications using role-based security.

There are several possible tiers to the security model for a workflow application. Server security, back-end business process logic security, and front-end security in the application user interface are all recommended points for controlling access to information.

Server Security

Setting up and maintaining a secure server is the job of the server administrator and includes installing applications or objects, adding users on the server, and managing the permissions for these users. Typically, managing user permissions involves creating roles, adding users to roles, and assigning role permission to applications or objects on the server.

Back-End Business Process Logic Security

Using the Workflow Designer, developers can assign role-based permissions on workflow actions. The server administrator or folder owner, using the SQL Server or Exchange 2000 security tools, defines these roles and permissions.

By default, all roles are granted permissions to perform all workflow actions. Limiting actions based on a user's role can make sure only appropriate people are making changes to items in a folder or database. For example, in an order-entry scenario, order clerks might be the only employees with permissions to create a new order, while the shipping clerks might be the only employees with permissions to close an order or to mark it as filled.

Front-End Security

The security model you follow for the user interface of your application will depend on the type of application you are creating and the security requirements of your team or company. For example, you might want to require users to log in with a password to access certain functionality or specific areas of your application.

The workflow application can implement NTFS access on the Web site. This provides an additional layer of security. See the Windows NT documentation for more details.

SQL Server and Row-Level Permissions

You can set row-level permissions on tables in SQL Server to make it possible for users to control access to individual rows in a table. Only main tables can have row-level permissions set. When you define permissions for a main table, those permissions are enforced on related rows in any detail tables.

Row-level permissions are enforced for write operations using triggers on the table. Read permissions are enforced by requiring all access to the table to be performed through a base view that Workflow Designer for SQL Server creates and by locking the base table. For more information about enabling row-level permissions, see Defining Table Security.

The permissions and roles you define for your application are preserved when you create a template based on it. The Workflow Template Creation wizard provides the option of removing existing database users before creating the template. When you create the template, make sure to include only role-based permissions rather than users, because the specific users of an application might change from instance to instance.

See Also

Which Technologies Should You Use? | Workflow: Technology Backgrounder | Workflow | Workflow Data Stores | Security Checklist