ENCANVAS is designed to be extremely safe for data and employs a blend of industry-standard and proprietary mechanisms to help organizations their keep data secure

Why ENCANVAS has been designed to be so secure

We created ENCANVAS to orchestrate business models for large organizations.  The information they process is mission critical to their success.  Storing it instantly becomes a threat.

Apps used to support business-critical processes need to work differently to public facing web pages. For one thing, to be attractive to search engines, pages on websites need to be permanent. ENCANVAS pages are created on the fly, so it’s much more difficult to attack the apps produced on ENCANVAS.


Explore our security architecture

What we do to keep your data safe

The ENCANVAS HPaPaaS ecosystem has been carefully developed to embrace security by design and privacy by design principles.  

It's ideally-suited to enterprises moving into the digital future.

How we protect data

Supports ISO 27001/2

We’ve walked through ISO 20071/2 requirements with a number of agencies and shaped ENCANVAS to meet their applied policy governance frameworks. Tooling in the platform caters for the implementation of ISO 27002.

Discourages creation of shadow data

‘Shadow data’ is so called because it becomes invisible to the functions charged with managing data in the enterprise (normally the IT department). Shadow systems are small scale databases or spreadsheets developed and used by end users outside the direct control of an organization’s IT department.

Typically these systems are developed on an as needed basis by knowledge workers to respond to new situations that demand new information. Rather than being authored as a formal IT project, these systems are not tested, documented or secured with the same rigor as formally engineered software solutions. In consequence, shadow systems have become the biggest single source of data security breaches.

It’s no longer an option for organizations to do nothing to improve the robustness of data security in the office environment. Neither is it a complete solution to assume that employees will encrypt every file that they hold on a memory stick or laptop hard drive. 

ENCANVAS encourages the use of web-database applications where data remains at all time on secure web servers; displacing self-authored applications and the risk of shadow data emerging.

Reduces risk of external breach

Hackers and the risk of external attack through websites is front of mind with security professionals but this threat is surprisingly uncommon as a cause of data breaches. It is actually more likely for data seepage to occur through unknowing or unscrupulous employees or known contacts due to their easier access to data and assumed bond of trust. The quality of web security provisioning has improved immensely over recent years and whilst there is no 100% safeguard against hackers, the probability of risk from external web attack is reduced dramatically through the adoption of a modern Internet Server platform, like Microsoft® Windows/IIS, that embrace the latest innovations in removing hacker threats such as use of Secure Socket Layer (SSL).

ENCANVAS is architected on Microsoft® ASP.NET™ based technologies and fully leverages the security features built into Microsoft® IIS as a Web server deployment platform. Encanvas Web Server does not hold resources on the Microsoft® IIS Server.

Pages are created as they are requested and served to the requestor. This approach ensures that no data relating to the delivered web-page is accessible to hackers.

Furthermore, ENCANVAS includes modules for secure file transfer and storage.  Encanvas Web Server inherits security mechanisms such as SSL and code access security from the Microsoft® .NET Framework.

  • Secure Sockets Layer (SSL) is an industry standard security technology for creating an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browser remains private and integral. SSL is an industry standard and is used by millions of websites in the protection of their online transactions with their customers. In order to be able to generate an SSL link, a web server requires an SSL Certificate.
  • Code access security helps protect computer systems from malicious code, allows code from an unknown source to run safely, and protects trusted code from intentionally or unintentionally compromising security. Encanvas Web Server inherits this mechanism from ASP.NET™ and uses it to control access to protected resources and operations.
Reduces cross-site scripting threats

This is the potential risk of Input forms being used to run malicious script. The solution is to validate user input, making safe the use of special characters and sequences. 

Prevents canonicalization attacks

This refers to the use of malformed URLs to gain access to restricted files. The solution is to not make security decisions based on the filename and to validate all URLs accessed.

ENCANVAS is programmed to produce point and click building blocks that prevent false URLs being used in deployed applications.  For this reason we actively discourage use of self-authoring scripting or coding but do not prohibit this functionality in the event that customers and partners install their own protocols to safeguard against the associated risk.

Prevents impersonation

The ability of unscrupulous individuals to impersonate and take on the identity of another presents far-reaching threats for fraud and theft of company data assets, particularly with the growth in information sharing and collaborating communities where the identity of an individual is qualified only by a user name and a login.  ENCANVAS can recommend various identity authentication methods at the request of customers.

Protects from SQL injection attacks

This is the use of Input forms to execute SQL queries on the database. The solution is to validate all user inputs and avoid dynamic SQL as much as possible. Encanvas Create is programmed to produce point and click building blocks that prevent malicious scripts being used in deployed applications.

Protects from Session-Based Impersonation

Sessions can cause problems because it becomes possible to impersonate another user. ENCANVAS minimizes this risk by carefully marshaling the client-server relationship and interactions. It includes a strong built-in permissions architecture made possible by the inclusion of canvas technology.

Protects End-Points

How many times have users and systems accessed sensitive customer data this month? Which data sources are applications farming for data? How much of this data has been risk assessed? If IT and data security professionals can’t answer these questions, their corporate information assets probably aren’t safe. The web services revolution energizes growth and harnesses talent pools across and beyond the physical boundaries of the enterprise – but there’s always the risk that small-scale innovation can ultimately lead to large-scale risks. ENCANVAS introduces a comprehensive set of administrative tools to govern data across all ENCANVAS authored applications serving data to users. It gives data security managers the control they need over user and data consumption behaviors. Better still, ENCANVAS enables organizations to devolve responsibility for operational data to departmental managers who are made more accountable for their data usage behaviors (and who are best placed to see potential security threats). This is made possible by giving department heads the tools they need to specify security levels on specific data assets and to understand user behavior through rich data visualization.

Endpoint authentication

A service’s endpoint identity is a value generated from the service Web Services Description Language (WSDL). This value, propagated to any client, is used to authenticate the service. After the client initiates a communication to an endpoint and the service authenticates itself to the client, the client compares the endpoint identity value with the actual value the endpoint authentication process returned. If they match, the client is assured it has contacted the expected service endpoint. This functions as a protection against phishing by preventing a client from being redirected to an endpoint hosted by a malicious service. The endpoint address for a service can be specified either imperatively using code or declaratively through configuration. Defining endpoints in code is usually not practical because the bindings and addresses for a deployed service are typically different from those used while the service is being developed. Generally, it is more practical to define service endpoints using configuration rather than code. Keeping the binding and addressing information out of the code allows them to change without having to recompile or redeploy the application.

Protects Data In Transit (Encryption)

ENCANVAS makes extensive use of encryption to protect data in transport from being intercepted.  Unless specific preferences are requested by the customer we leverage the standard encryption technologies installed in Microsoft® ASP.NET™.  Using ASP.NET™ it is possible to configure keys to use for encryption and decryption of forms authentication cookie data and view-state data, and for verification of out-of-process session state identification.

Validation Key

It is possible to specify the key used to validate encrypted data. Validation Key is used when enable View State MAC is true in order to create a message authentication code (MAC) to ensure that view state has not been tampered with. Validation Key is also used to generate out-of-process, application-specific session IDs to ensure that session state variables are isolated between sessions. The Isolate Apps modifier of the validation Key value indicates that ASP.NET™ generates a unique encrypted key for each application, using the application’s ID. Isolate Apps is included within the default value.

Security Features


As Encanvas DX is deployed on the Microsoft® Web Platform (and specifically the .NET Framework), it adopts use of Kerberos. All the authentication protocols are exposed via SSPI (Security Support Provider Interface).

Since Microsoft® released its Windows Server 2003, the company has adopted Kerberos 5 as the default protocol for its network authentication.  Active Directory is merely the directory that holds of the information.  Kerberos protocol implementation is used to protect it and make it function.  

The .NET Framework has a model of managing user or automated agent based on the notion of an Identity.  The identity object encapsulates information about the user or entity being validated. Basic identity objects contain a name and an authentication type.  The name can either be a user’s name or the name of a Windows account, while the authentication type can be either a supported logo protocol, Such as Kerberos VS, or a custom value.  The .NET Framework defines a Generic Identity object that can be used for most custom logon scenarios and a more specialized Windows Identity object that can be used when application relies on Windows authentication. Additionally, own identity class can be defined that encapsulates customer user information. 

ASP.NET™ implements authentication via authentication providers. Providers are basically Classes that contact Public Static Methods to help in authenticating requests from Clients. An ASP.NET™ Application can be configured to use one of the following Authentication Providers (these are exposed to Encanvas systems administrators either within the IIS management application, or via the Web Server Manager administrative cockpit).

1. Windows Authentication

The Windows Authentication Module provider relies on IIS to provide authenticated users. The provider module constructs a Windows Identity object.  The default implementation constructs a Windows Principal object and attaches it to the application context.  One of the major advantages of Windows Authentication is to allow implementation of an impersonation scheme.

2. Forms Authentication

Forms authentication is recommended if the application needs to collect its own user credentials at logon time through HTML forms.  All other unauthorized requests are redirected to the logon page using HTTP client-side redirection. Forms authentication provider may implement custom logic for validating username and password against identity store.  If the application authenticates the request, the system issues a ticket that contains a key for reestablishing the identity for subsequent requests.

ENCANVAS makes use of the versatility of these options to provide organizations with the ability to produce federated identity management structures that may consume standard services such as Active Directory, merge them with other directory services or create completely new identity management structures using the tooling provided by Encanvas DX that leverages optimal value from the authentication methods the .NET Framework provides.  Encanvas deployed applications will normally adopt the Forms authentication approach as outlined above to create personalizable logon forms.  However, given that the platform resides on the Microsoft® Web Platform, it has the option to use Windows Authentication when required.

Federated Security and SSO

Our Approach to SSO

Encanvas DX can be configured to provide Single Sign-On (SSO). This is implemented in one of two ways:

1. The Intranet Solution

The user will click on the application he wants to run and a unique, one-time use token is generated. This token and the user’s identity will be stored in another database table. The token is then passed to a special page (via the query line) in the Web application the user wants to run. This special page will read this token from the query line and verify the token exists in the database table. If the token exists, it will retrieve the login id from the database and delete the record where this token was stored. This prohibits anyone else from reusing this token and sends the login id back to the Web application. Now that you have the user’s identity within this Web application, you need to generate an ASP.NET™ forms authentication ticket since all Web applications in your intranet will use forms-based authentication. This ticket will then be used by the user who is navigating through all of the secure pages on this site.

2. The Extranet Solution

External users (people not in your domain) who want to come into your Web application are directed to a different start page than internal users. The Web application that both internal and external users are directing to is secured with forms-based authentication. When an external user attempts to navigate to any page within this Web application they will be automatically redirected to a login page. This login page is a different page from the page the internal users are authenticated by. The user must enter their credentials and a call to the same database will be made to determine if the user is valid for this application. If they are then the normal forms-based authentication cookie will be generated for this user’s session.

Identity Management

As organizations extend their collaborations and processes beyond the boundaries of their enterprise, an identity management approach that’s able to flex and take into account differing needs becomes essential. Encanvas DX works with and protects existing technology investments. It allows enterprises to manage the end-to-end lifecycle of user identities across all enterprise resources consumed by ENCANVAS users both within and beyond the firewall.  The system does not attempt to ‘lock-out’ users or take privileges away from users. Instead, it enables security managers to specify security for each and every work space, work group, role and user without creating an administrative burden on managers.

A role defines a set of permissions (Read, Write, Delete, Admin). You can think of a role as a hat that a user wears to define their level of access and authority to use Encanvas software modules. ENCANVAS identifies 4 main privilege levels of user role. These are:

Level 1.  Administrator – Describes the role responsible for installing and administering ENCANVAS Administrators (normally an individual responsible for ICT or network infrastructure) determine user privileges and the level of access to ENCANVAS modules appropriate for users. Administrators can configure the operation of ENCANVAS modules to harmonize the operation of ENCANVAS to suit organizational procedures (e.g. Having the ability to pre-determine levels of access to organizational databases etc.).

Level 2. Author – Describes the role of users that are able to author, read and edit Canvases. Authors have access to Encanvas Create unlike Contributors who do not.

Level 3.  Contributor – Describes the role of users that are able to read and use canvases. A Contributor is responsible for contributing information for processes using canvases on web-browser, personal computer, laptop, tablet or smart phone device platforms.

Level 4.  Viewer – Describes the role of users that only have authority to read canvases but not enter data into them. Each user is assigned a set of permissions. This set of permissions identifies portal access, views and the actions a user can perform. User permissions may be inherited from Microsoft® Active Directory and controlled by ENCANVAS. The users are added and assigned to a role at one web page or web page group within the portal for all sub-pages. Therefore, a user will have the same permissions on all the sub-pages. Administrators can modify the web page creation process so that each individual web page uses unique permissions. Unique permissions enable the management of users and groups separately from the top-level portal.


A table of groups is created in SQL

A table of users is created in SQL or can be inherited from Active Directory (or other data sources).

As canvases are created, they are assigned to a Group. This data is also held in SQL.


Authorization determines whether an identity should be granted access to a specific resource. In ASP.NET™, there are two ways to authorize access to a given resource:

File authorization – File authorization is performed by the File Authorization Module. It checks the access control list (ACL) of the .aspx or .asmx handler file to determine whether a user should have access to the file. ACL permissions are verified for the user’s Windows identity (if Windows authentication is enabled) or for the Windows identity of the ASP.NET™ process. For more information, see ASP.NET™ Impersonation.

URL authorization – URL authorization is performed by the URL Authorization Module, which maps users and roles to URLs in ASP.NET™ applications. This module can be used to selectively allow or deny access to arbitrary parts of an application (typically directories) for specific users or roles.


ENCANVAS has been designed to deliver human readable log files covering all aspects of systems operations including the recording of:

  • Web Server uptime and availability
  • Web Service events
  • Microsoft® Web Platform service continuity (ASP.NET™, IIS, SQL Server)
  • User login and behaviors
  • Deployed Remote[Space] site events
  • Data read/write errors
  • Data source errors
  • Click tracking and site visitor behaviors

It is possible for customer to create reports and log files for their own applications using the self-service report design tools provided. From a systems administrator perspective, logs are captured on the Web Server and is reported via an encrypted TCP/IP service; presented through the Remote(Spaces) Client module.

Using the fine-grained recording and reporting possibilities of ENCANVAS, organizations have been able to develop full user behavior traceability.  This functionality is being used in various industries to formalize process and policy, manage productivity, prevent systems, monitor compliance and expose corruption.