Access Workflow Designer leverages Windows NT and SQL Server security for its own security model.
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.
Access Workflow Designer uses SQL role-based security leveraged from Windows NT group domain accounts. Roles are defined using the Access 2000 security tools, but the developer is not required to be concerned with who belongs to each role. Users are added and removed or their roles changed when a team solution administrator deploys the team solution or when the administrator adds or removes users from the Windows NT 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 Access Workflow Designer modSystem database. These rules can be modified using the security features available in Access 2000 or the SQL Server Enterprise Manager.
Access Workflow Designer leverages the database-, table-, and column-level security that SQL Server provides and Access 2000 supports. Enabling row-level permissions and workflow action security extends the SQL Server security model. In addition, the team solution can implement NTFS permissions on the Web site. For details, see "Web Security Considerations" in the User Interface Considerations topic.
Access Workflow Designer also preserves information about users and roles when the solution is taken offline.
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 team solution. With this strategy, rather than assigning permissions to each user for each object in your team solution, you assign permissions to a few roles and then add users to the appropriate role. When using the team solution, users are granted permissions based on any roles to which they belong.
For example, in the Issue Tracking solution, the IssueTracking database is secured using an Authors roles for users who are creating and modifying issues and a Readers role for users who have read-only permissions in the solution. 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 solution. 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 a solution based on this template, users of the new team solution can be assigned to the existing roles.
For information about Access project security, search for "security" in the Access 2000 Answer Wizard. For details on creating roles for a team solution, see Creating Database Roles.
Workflow permissions are role based. When a workflow action is created, you can indicate which roles are permitted to execute it. At run time, the engine verifies if the current user is member of any of the roles with execute permissions for the action.
Role membership information is cached in each team solution every time users are synchronized. This information is used to resolve mapping between the user Security Accounts Manager (SAM) account name and solution roles. This mechanism of enforcing workflow permissions works the same both online and offline on both Windows NT and Microsoft Windows 9x platforms. In Windows 9x, team solutions use the SAM account information cached during network login to verify execute permissions.
A second level of security is implemented on workflow action by specifying whether the action can be performed offline. You can enable a workflow for offline use on the Design tab in the Workflow Process pane. If this option is disabled, the action is not available to offline users. This option should be used in addition to regular workflow permissions for sensitive actions that should not be replicated on less secure offline computers.
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 team solution's requirements and the sensitivity of other data on this computer.
For details about managing workflow permissions, see Controlling Permissions for an Action.
In order to secure your data during replication over the Internet or to reduce the chance that a malicious user or third party can intercept sensitive replicated data, you should use encrypted connections. You can find out more about using encrypted connections by searching for "Multiprotocol Net-Library" in the SQL Server Books Online.
You should consider the offline client as a non-secure environment, because the offline user is often the database owner (DBO) on that local computer. Access Workflow Designer replication ensures only data available to that user while online is replicated offline. The local user should have the same permissions offline as online.
Security for the online database is enforced when the user attempts to synchronize offline changes. To make any changes to the online database, the user must have appropriate permissions.
The Access Workflow Designer provides the Offline Boolean property as a master switch for taking workflow actions offline. For details, see Allowing Actions to Occur Offline. This mechanism is independent of execute permissions. For example, a user may not have execute permissions on a given action, but if the action is identified as an action that can be performed offline, the user can take it offline and see the associated script code. Therefore, be careful to ensure that sensitive actions are marked for online use only.
Note Web security is only available on NTFS (not FAT or FAT32). For more information, see "Web Security Considerations" in the User Interface Considerations topic.