Data Accessibility and Security

Last update: Edit

1 Introduction

When sharing data in an organization, access to and security of the data is a primary concern.

Security for an app can be defined at the app project-level, module-level, and entity-level. Further authentication methods can also be specified to control access to the data associated with published entities.

This security level determines which end-users of the apps will have access to the data represented by the entity. For example, an app developer in Mendix Studio Pro working in an HR department can use the Employees entity in the Data Hub Catalog in their application. The developer must have access to representative test datasets that are made available in a test or acceptance environment to properly develop the app. However, at runtime, they may not be able to see all the actual employee data if they do not have the correct access permissions. Similarly, end-users of the consuming app will only be able to see the data for which they have clearance. HR managers using this app will be able to see more data from the same employee entity database according to their access clearance.

For further information, see the Security section in Published OData Services.

Security is determined by the identification protocols of the organization and applied to all access to the data via Mendix apps. This page shows an example of applying custom HTTP header validation.

2 OData Security for Shared Data Entities

For Mendix apps that publish entities and those that consume shared entities in their apps as external entities, the following details apply:

  • The security for the OData-based service is defined in the publishing app – at the project, module, and entity level
  • The security that is defined at the module level will apply to the OData services that are published from the module and enforced when the entities from the service are used in a consuming app when end-users try to access the data

  • Classification of the data associated with the entities is defined in the service metadata and shown in the Service Metadata panel of the Search Details screen. This is further discussed below.

  • Through the identification protocols used for establishing the user identity, the security rules for the user in the publishing app are applied

    • On the Mendix Platform, this is Mendix SSO, but it can also be the organization’s identification protocol
  • In the publishing app in Studio Pro, access can be defined at the entity level as follows:

    • None
    • Basic authentication on the user name and password
    • Customized where the publisher builds their own microflow which gets the header from the request to determine the user and what the user wants to do

For further details, see the Entity Access section of Module Security.

3 Classification of Registered OData Services

OData services registered in the Data Hub Catalog have the following classifications that apply to the data associated to the exposed entities:

  • Public – data is available to all internal and external users
  • Internal – data is restricted to the members of the organization

The classification of the asset indicates the runtime security on the data and defines what users are allowed to see and use when running their application.

The classification for a registered OData service is shown in the Service Metadata panel in the Data Hub Catalog. This classification applies to access to the data associated with the service or entity by end-users of the app that consumes the entity.

4 Using Custom HTTP Header Validation for Published Entities

For an example of how to implement authentication using security assertion markup language (SAML) and Active Directory Federation Services (ADFS), the following procedure illustrates how to use a custom HTTP headers microflow and a custom HTTP validation microflow to generate, set, and validate authentication tokens.

The following steps describe how the security proposal is set with ADFS and the SAML Mendix App Store module:

  1. The app end-user logs into an app that uses external entities.
  2. The end-user is not yet authenticated, so the SAML module forwards the user to ADFS for authentication.
  3. If the correct credentials are provided, ADFS returns a cookie for SSO.

  4. When the end-user performs a query on a external entity, the JSON web tokens (JWTs) are set on the API call (and are validated with a microflow in the consumed OData service):

  5. The publishing app receives the request and uses the custom microflow specified in the settings of the published OData document to validate the tokens. If the tokens are not known, it calls ADFS to validate the user.

  6. ADFS returns the user validation.

  7. The customer authentication microflow on the OData service document returns the appropriate user which is used for retrieving the data. The entity access rules will use this user for authorization.