Changes for page eMagiz Security Guide

Last modified by Erik Bakker on 2023/01/02 10:25
From version 25.1
edited by Erik Bakker
on 2022/06/13 14:11
Change comment: There is no comment for this version
To version 26.1
edited by Erik Bakker
on 2022/07/26 14:13
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -174,7 +174,7 @@
174 174  
175 175  ==== 3.5.2 API Gateway ====
176 176  
177 -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.
177 +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. 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.
178 178  
179 179  ===== 3.5.2.1 Portal =====
180 180  
... ... @@ -182,14 +182,14 @@
182 182  
183 183  [[image:Main.Images.Fundamental.WebHome@fundamental-emagiz-security-guide--api-gateway-portal-feedback.png]]
184 184  
185 -===== 3.5.2.2 External IDP =====
185 +===== 3.5.2.2 (External) IDP =====
186 186  
187 -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.
187 +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.
188 188  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.
189 189  If the client has sufficient rights, the process continues. For example, if the client has insufficient rights, the client receives a 401 Unauthorized.
190 190  
191 -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.
192 192  
192 +
193 193  ===== 3.5.2.3 Error handling =====
194 194  
195 195  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.