As workflow is often the center of your organization, security is a top-most concern with WorkflowFirst. With many years of testing and deployment in governments and some of the largest organizations in the world, WorkflowFirst has a proven foundation in security. In this section we will discuss the various features of WorkflowFirst that help keep your critical data secure.
Many popular software systems today are provided only through a cloud service. WorkflowFirst, however, is far more flexible and provides multiple means of deployment. While we provide a cloud service, we also allow for deployment on a private network within your own organization, on Windows servers. Alternatively WorkflowFirst can be deployed on a private cloud service such as Amazon Web Services or Microsoft Azure. In all cases WorkflowFirst applications can be integrated with Microsoft IIS and its wealth of web-server hardening tools to ensure the highest level of protection.
Every session that access your WorkflowFirst application is verified to ensure it is authenticated. Any session that is not authenticated will automatically be redirected to the login page where they must enter in their user name and password. The information is then relayed to the server where it is authenticated. If the information cannot be verified then the user is not allowed to access any resources and will be redirected back to the login page. Maximum retries can be configured (when used with Active Directory) after which the account will be locked. Internally these sessions are re-authenticated every few minutes, in case credentials change while the session is active.
Because WorfklowFirst easily integrates into Microsoft's Internet Information Server, it is an easy process to enable HTTPS (SSL, also known as TLS, Transport-Layer Security) for the entire application. This means that data can be transferred securely between the client web browser and server using military-grade, asymmetric encryption.
Any request that is received by WorkflowFirst is verified to ensure it does not contain any malicious codes that could result in the user inadvertently exposing data. There are many ways that hackers will attempt to penetrate systems, incuding cross-site scripting, injecting script or database commands - and WorkflowFirst takes many precautions by parsing all incoming requests to ensure all such requests are rejected before any harm can be done.
When used with SSL all passwords sent from the client to the server will be encrypted automatically. However even then it is still possible for a client browser to retain passwords if developer logging is enabled without their knowledge. To protect against this, WorkflowFirst can optionally encrypt all passwords entered by the user before the browser is able to log it, ensuring it cannot be obtained through illicit ways.
WorkflowFirst can optionally be integrated with Microsoft Active Directory, meaning that all users and passwords will be managed centrallly through an Active Directory server. This can be beneficial because Active Directory provides many configurable policy options for enforcing strong passwords, and ensuring they are changed frequently. When Microsoft Active Directory is used, no password information is stored in the database at all.
Because web browsers have no true concept of session management, it can often be difficult to detremine when a user stops using an application if they do not explicitly click the "log out" button. To ensure that secure connections are not inadvertently left open, WorkflowFirst enforces strict lifetimes on sessions. If the session is not used for a certain amount of time, then it will be automatically logged-out. The same can also be configured for browser tabs left open - a window will pop-up asking the user to click a button to continue the session, otherwise it will automatically terminate the session and log the user out.
Another option provided by WorkflowFirst allows the application to be configured to only allow a user to be logged in to one browser window at a time. If the same user logs into a different browser or machine, then it will automatically log out the other sessions for that user. This can be important to ensure no unauthorized access occurs under a particular user account if the user knows they will only be logging in to one machine at a time.
The most common form of authentication is when a user enters in a username and a password. It is also possible to require an additional layer of security through something called two-factor authentication. In this case a secondary medium will be used to contact the user attempting to login. They will be presented with a challenge (such as a PIN) that will be sent to another device, such as their phone. They will then enter in that PIN along with their password, and the PIN will be verified along with their password before they will be allowed to access the system.
The authentication mechanism in WorkfklowFirst is highly customizable, allowing for scripts to be provided that can impose additional security checks - such as time windows (allowing the user only to login during specific times), detecting unusual login behavior, or only allowing logins from a particular IP addresses (or range of IP addresses). It is also possible to send a notification every time a particular user logs in, for example from an unrecognized or unusual machine.
All user logins to the system are logged to an external file that can be used for auditing purposes, should a security breach need to be investigated. These files are retained indefinitely and can be easily archived for information purposes.
Every user can have one or more roles assigned to them. These security roles enforce certain restrictions in their use of the system, such as allowing them to see particuar tabs or other areas of the application, filtering certain screens to only show particualr records, allowing them access to specific actions or reports and so on. Roles can also be set to apply by default, so that they apply to all users. By centrally managing roles in the system, your organization can have a clear record of precisely which users have which roles and what exactly they can access.
Roles in WorkflowFirst can also be applied to individual fields in a form. This means that users with the role will see those fields, but other users will not. The forms dynaimcally change their layout to accommodate any missing fields so the user interface is not compromised in any way.
Any field can be tagged as holding sensitive information in WorkflowFirst, and this field will then be encrypted using AES before it is stored in the database. This can be a critical component of keeping any personally-identifiable information secure.
Any sensitive data related to active sessions in the system will be encrypted in the database. Also, the session key that is passed between the client and server is also encrypted to ensure that sessions cannot easily be hijacked, and is changed frequently to ensure they cannot be stored for use at a later time to compromise a system. In addition these sessions are only maintained for a specific period and will be deleted from the system when they expire.
WorkflowFirst applications use Microsoft SQL Server, and if the organization has SQL Server professional, the database can be configured to use Transparent Database Encryption, which will encrypt all data stored on the hard drive - protecting should access to the server ever be compromised in some way.
WorkflowFirst also provides the means to record checksums of form data that is submitted, using cryptographic hashing algorithms. This checksum can then be used to verify the integrity of the data, to ensure that it has not been tampered with outside of the system. This can be combined with digital signatures (only available in version 9 of Internet Explorer) where, in addition to recording a checksum, forms can be signed by the user using the CAPCOM cryptographic standards for digital signatures. Other means of signing records can also be adopted, such as e-ink signatures (for use on touch devices) and having the user enter in their username and password again before submitting.
WorkflowFirst applications store attachments in the file system, and not in the database. This is done deliberately to allow for server-based anti-virus systems to verify any attachments uploaded into the application are free from any viruses or malware. Should any problem be found with an attachment, upload of that file will be rejected and an error displayed to the user.
Being installed on a private network and using industry-leading Microsoft IIS and SQL Server databases, all of the well-established best practices hardening techniques and software can be applied to these systems to ensure maximum protection of the servers.
An important aspect of security is protecting against denial-of-service attacks and other such attacks that compromise the accessibility of the system. Using IIS, all of the load-balancing features typically used to scale web servers can be deployed to ensure maximum up-time of the application services. Also, secure database mirroring can be deployed to ensure accessibility of the database.
All of these security features of WorkflowFirst are tested on a regular basis by professional security firms through government and other large organizations. Dedicated teams work on these issues to ensure they are resolved in a timely fashion. Any issues that arise during these penetration tests are treated with the highest priority and quickly addressed in hotfixes that are broadcast to all users through support channels.
Next Topic: Deployment
Please post all questions on the support forum. Thank you.