Security Permissions Model
Workflow Designer for SQL Server leverages Microsoft® Windows® 2000 and Microsoft® SQL Server™ security for its own security model. You can manage users and groups through the Windows 2000 Active Directory. You can control access to databases through roles you assign and permissions you specify in SQL Server Enterprise Manager. You also can control the permissions a user has by specifying roles and permissions in the Workflow Designer. To make it possible for users to access your application, you must add them as users to the operating system. You can make user management more efficient by specifying groups and controlling users by the group they are in.
When working in SQL Server, the user passes through two stages of security: authentication and permissions validation. The authentication stage identifies the user using a login account and verifies only the ability to connect with SQL Server. If authentication is successful, the user connects to SQL Server. The user then requires permissions to access databases on the server, which is done by using an account in each database, mapped to the user login. The permissions validation stage controls the activities made available for the user to perform in the SQL Server database.
Workflow Designer for SQL Server uses SQL Server role-based security leveraged from Windows 2000 group domain accounts. Users are added and removed or their roles changed when a workflow application administrator deploys the workflow application or when the administrator adds or removes users from the Windows groups mapped to the roles.
Security rules that define what information can be viewed or updated by users belonging to each role are contained in the modSystem database. These rules can be modified using the security features available in SQL Server Enterprise Manager.
Workflow Designer for SQL Server leverages the database-, table-, and column-level security that SQL Server provides. Enabling row-level permissions and workflow event security extends the SQL Server security model. In addition, the workflow application can implement NTFS permissions on the Web site.
Database Role Security
As part of securing a database, you can create roles that you use to assign a common set of permissions to multiple users.
Organizing users by defining roles makes it easier to manage a secure workflow application. With this strategy, rather than assigning permissions to each user for each object in your workflow application, you assign permissions to a few roles and then add users to the appropriate role. When using the workflow application, users are granted permissions based on any roles to which they belong.
For example, in the Issue Tracking sample, the IssueTracking database is secured using an Authors role for users who are creating and modifying issues and a Readers role for users who have read-only permissions in the application. The Authors role has the least restrictive set of permissions, and the Readers role has the most restrictive set of permissions. When you create a user account for a new employee, you add that account to the appropriate role. Then, the employee has the permissions associated with that role.
The use of roles also works well when you create a template based on your application. Rather than having to change permissions for each user, the template contains information about each role and the permissions assigned to these roles. Then, when creating an application based on this template, users of the new workflow application can be assigned to the existing roles.
Workflow Security
Workflow permissions are role based also. When you create a workflow event, you can specify which roles are permitted to execute it. At run time, the engine verifies if the current user is a member of any of the roles with execute permissions for the event.
Role membership information is cached in each workflow application every time users are synchronized. This information is used to resolve mapping between the user Security Accounts Manager (SAM) account name and application roles. In Windows 9x, workflow applications use the SAM account information cached during network login to verify execute permissions.
All workflow code runs under the context of the user account you configure for the workflow engine. The permissions you grant this account on the server depend on the workflow application's requirements and the sensitivity of other data on this computer.
See Also
Planning Workflow Applications for SQL Server | Workflow Application Development Guidelines | Database Tools and Technologies | The Workflow Engine Model | Setting Up Accounts, Logins, Roles, and Users | Controlling Permissions for Events | User Interface Considerations