Data Exchange
In this section, we’ll examine how eMagiz manages data exchange between applications and integrations, focusing on security considerations for each method. eMagiz supports three main integration patterns: Messaging, API Gateway, and Event Streaming. We'll explore the security measures associated with each pattern, including options like OpenID Connect, OAuth2.0, and access control lists. By understanding these patterns and their specific security configurations, you'll be better equipped to protect data and ensure secure interactions across your integrations.
Should you have any questions, please get in touch with academy@emagiz.com.
1. Prerequisites
- Expert knowledge of the eMagiz platform
2. Key concepts
This microlearning focuses on security considerations when exchanging data via the platform.
- Each pattern comes with generic and specific checks and balances to ensure security is taken care of when exchanging data.
3. Data Exchange
Because eMagiz provides the integration between two or more applications via the eMagiz platform, the point at which the data is interchanged between application and integration is a critical part of the integration in terms of security.
Within eMagiz, there are three main integration patterns a user can configure to support their business case most optimally. First, this section will look at all three integration types and specify the security measures.
3.1 Messaging
Messaging is the most flexible option of the three; therefore, a wide range of options is available within eMagiz to secure the connections.
eMagiz offers users the tools to set up integrations and end-points securely. eMagiz supports well-known market standards, including:
- OpenID Connect
- WS-Security
- API Keys in combination with HTTPS/SSL
- SOAP Authentication
- OAuth2.0
- Basic Authentication
This way, each connection between the application and the integration (end-point) can be adequately secured and gives the flexibility to confer with the external application which method best suits their needs.
3.2 API Gateway
A structure with roles and rights per role can be specified within the portal or via an external IDP to secure the front end of the API Gateway in eMagiz. Note that for the backend of the API Gateway, the same logic applies as stated above for messaging, which means that eMagiz supports the industry standard. Therefore, you as a user should confer with the external party about the correct method.
3.2.1 Portal
As shown in the picture below, the roles are defined so that the Read role can only access two integrations available for this specific API Gateway. If a client has insufficient rights, they will receive a 401 Unauthorized
3.2.2 (External) IDP
Apart from configuring the roles, users, and rights within the portal itself, it is also possible to hook the API Gateway up to an (external) IDP.
By communicating with this IDP via the OAuth2.0 protocol, a check is done every time a client calls a specific operation to see whether that client has sufficient rights to access the operation.
If the client has sufficient rights, the process continues. For example, if the client has insufficient rights, the client receives a 401 Unauthorized.
3.2.3 Error Handling
To prevent the error message if it occurs is sent straight back to the client, you can configure the front end of the API Gateway so that correct HTTP Status codes are given back to the client, including a descriptive message.
For more information on how this precisely can be configured via the eMagiz platform, please check the following microlearning.
3.3 Event Streaming
Within the Event Streaming solution, eMagiz provides Event Streaming users, and topics can be created.
Access to a topic within a cluster is governed by an Access Control List (ACL). This ACL links users to a topic and defines what the user can do on a topic (consume, produce, both).
Only users with sufficient rights in the Deploy phase of eMagiz can add users, and topics and change the ACL entries specific to the Event Streaming cluster.
Apart from producing or consuming data on specific topics based on the ACL, users also need a valid Keystore (containing the key and cert generated automatically) and a valid truststore (containing the CA certificate of the event streaming cluster) to produce or consume data.
These are all security measures to prevent third parties from unauthorized access to the data stored on the topics.
For more information on how this precisely can be configured via the eMagiz platform, please check the following microlearning.
3.4 General
Regardless of the selected pattern for your solution, it would be best if you always considered that you only exchange relevant information with the external party. This means you should consider both headers as the payload you need to exchange with the external party. This is particularly interesting for any communication via HTTP gateways as they hold functionality to send all message headers as HTTP headers and vice versa.
4. Key takeaways
- Each pattern comes with generic and specific checks and balances to ensure security is taken care of when exchanging data.
- When you are not careful, you might share too much information with external parties.