Evaluation Guide

Security

Secure your data first, then your functionality! 

We believe that security and access control should encourage smart application design rather than just being a necessity. Therefore, Genus comes with the most comprehensive security functionality of any no-code platform and provides full flexibility in the design of the security model. 

The security model is sophisticated and developed over decades with feedback from highly security-aware industries including public safety, banking and finance, and insurance. As a metadata-interpreting no-code platform without code generation and possibilities for code injection, the security model is designed to cover the entire application and cannot be compromised by custom code errors.

The dynamic security model in Genus allows for access control down to Object Class and Property level, removing the risk of unintentional data exposure. Combined with options of conditional security based on your data, Genus puts you in charge to facilitate a smart and dynamic setup for data access.

  • The application model contains users that are mapped to one or more ID providers. This setup provides multiple ways to authenticate a user. You can manage the available identity providers in Genus Studio. Two-factor authentication is also available for the identity providers that offer this.

    Genus supports multiple identity providers.

  • Account profiles describe the account policies for users, and optionally a description of how to associate a user with a business object, such as an employee or a customer.

    When an account profile is mapped to an Object Class, it is possible to use this information in conditions in the application. For instance, a user’s access to a specific object can be granted or denied based on whether she is assigned to this object in the data.

  • Security groups are used to grant permissions and privileges to users. A security group can also be a member of another security group and inherit permissions and privileges from it. Genus supports both role-based and level-based security group setups.

  • Data sets are used to separate the data storage between different business entities or “tenants” (e.g. companies within an enterprise) using the same application model, preventing access to each other’s data. Data set access is granted to security groups.

    Data sets share the same data model, but the underlying data is separated either physically, through separate databases or schemas, or by unique identifiers for each data set. However, it is also possible to design object classes with data shared across data sets (e.g. to share master data).

  • Privileges define the type of operations and actions members of a security group can perform in the Genus platform. Examples of privileges that can be granted include Sign in as a Desktop user, Open Genus Studio, and Manage users.

  • Permissions regulate the user’s access to an object. These are granted on a CRUD basis to either individual users or security groups. Permissions can be granted to all objects of a given type, to individual objects, and to object properties.

  • API keys can be generated for users to allow other systems and applications to access APIs defined in Genus. A user can have multiple API keys. The goal of API keys is to provide an access key that can be used to consume model-exposed APIs such as a REST or SOAP service.

    API keys cannot be used to log in to the Genus Desktop or Genus Web client.

  • Grant matrix is a tool to check the security settings for users or security groups. Through the grant matrix, you can check and verify permissions and privileges for users and security groups.

  • The application model is secured from the bottom up, starting with the data model. This means that no user or interface can access or modify any data without authorization. When designing the data model, the Business Engineer must decide who should be able to access the information:

    • No security: The object class is open for anyone with access to the application

    • Inherited permissions: Access to the object class is based on access to a referenced object

    • Granted permissions: Access to the object class is granted explicitly

    • Grant with conditions: Access to the object class is granted conditionally

    Access can further be granted on several layers, according to what the different users should be able to do or see. The levels of permission are:

    • Find And List: The user can see the entry in search results or listings.

    • Read And Execute: The user can open the object in a form and view the content (properties)

    • Create: The user can create new objects of this object class

    • Modify: The user can modify an object of this object class

    • Delete: The user can delete an object of this object class

    • Read Event History: The user can see the history of this object and what has changed over time

    • Read Permissions: The user can see who has the different types of permissions to objects

    • Set Search Criteria: The user can search based on the properties of objects of this object class

  • For advanced applications, access to information must often be assigned dynamically. For instance, a case management solution should immediately grant a certain level of access to information about a case to new team members. In Genus, this type of dynamic grant of access is handled through Conditional Security.

    Conditional Security allows the granting of permissions to be based on the data in the application, in contrast to for example which security group you are a member of. For instance, access to an activity can be based on whether you are assigned to that specific activity. Or, it can be based on that you are the manager of someone assigned to the activity.

    The entire data model can be used to define the security model best suited for your specific application. This type of security is especially important in applications containing sensitive or confidential information, which should only be visible to specific, and often dynamic, groups of people.

  • Genus can be used with multiple ID providers supporting OAuth2 (e.g. Azure AD, Google, or Facebook) or Open ID Connect (e.g. ADFS or BankID). Additionally, Genus comes with a native ID provider.

  • Audit trail

    • The audit trail is an integral part of the Genus platform, where all CRUD operations on data and actions can be logged. Even search actions can be logged, ensuring full visibility into who has seen or modified the data in your application.

    Data integrity and data constraints

    • Genus builds on the functionality of underlying databases, but also enriches and extends the functionality to ensure full portability of your data. The data model of your Genus application is set up to support data integrity and data constraints, which again reduces the risks of erroneous or malicious data in your applications.

    OWASP top 10

    • Genus is hardened against the top 10 Web Application Security Risks defined by the Open Web Application Security Project® (OWASP).

    HTTPS as default

    • Genus always uses Hypertext Transfer Protocol Secure (HTTPS) as the standard communication protocol, and the communication can be encrypted with your own digital certificates.