Wiki source code of API User Management
Last modified by Waria on 2026/07/23 09:31
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{container}}{{container layoutStyle="columns"}}((( | ||
| 2 | |||
| 3 | {{info}}Note: This microlearning is written for models that use MAM (Multiple Authentication Methods). The content does not apply to models that are still on the legacy API Gateway security.{{/info}} | ||
| 4 | |||
| 5 | In this microlearning, you'll learn how eMagiz supports the configuration and management of API users and their permissions. | ||
| 6 | |||
| 7 | If you have any questions along the way, feel free to reach out to us at [[academy@emagiz.com>>mailto:academy@emagiz.com]]. | ||
| 8 | |||
| 9 | == 1. Prerequisites == | ||
| 10 | |||
| 11 | * Basic knowledge of the eMagiz platform | ||
| 12 | * Basic understanding of creating an API Gateway in eMagiz | ||
| 13 | |||
| 14 | == 2. Key concepts == | ||
| 15 | |||
| 16 | * User: Any system or user that is granted access to operations of your API Gateway | ||
| 17 | * Permission: Read and/or write access that can be granted to any operation of your API Gateway | ||
| 18 | * API Gateway: A collection of REST API operations that can be exposed externally to provide controlled access to applications and business processes. | ||
| 19 | |||
| 20 | == 3. Manage users and permissions == | ||
| 21 | A crucial part of setting up your API Gateway with the help of RESTful services is defining which client has access to which operation. In Capture, you have defined your system users. In Design you can choose which operations these users have access to. | ||
| 22 | |||
| 23 | The Deploy phase allows you to actualize these changes, extract and share user credentials, and offers some advanced options for user management. | ||
| 24 | |||
| 25 | === 3.1 Design === | ||
| 26 | |||
| 27 | When clicking on an API integration in the Design overview a list of available operations expands. With the checkboxes, you're configuring that this system (and all underlying users) has permission to access the operation. This is the only way to adjust the permissions of your system users. | ||
| 28 | |||
| 29 | In the example below, it means that both clients can GET and POST sales orders and the ACTE OMS can POST credit check requests to the API Gateway. None of the clients have access to the PUT sales orders operation to update their orders since this operation is still in development in the backend system. | ||
| 30 | |||
| 31 | [[image:Main.Images.Microlearning.WebHome@crashcourse-api-gateway-user-management--add-permissions-in-design.png]] | ||
| 32 | |||
| 33 | === 3.2 Deploy === | ||
| 34 | |||
| 35 | The deploy phase has a tab User management that shows all API Gateway users (and EVS users if applicable). The users and permissions shown are the ones that are currently running on your environment. | ||
| 36 | |||
| 37 | [[image:Main.Images.Microlearning.WebHome@crashcourse-api-gateway-user-management--overview.png]] | ||
| 38 | |||
| 39 | ==== 3.2.1 Apply to environment ==== | ||
| 40 | Any changes made in Design can be transferred and applied by using Apply to environment. Here you see a list of pending changes that can be applied individually or all together. The pending changes are generated based on your configuration in Design. These can be new users, changed permissions and deleted users. | ||
| 41 | |||
| 42 | [[image:Main.Images.Microlearning.WebHome@crashcourse-api-gateway-user-management--pending-changes.png]] | ||
| 43 | |||
| 44 | ==== 3.2.2 Adjust authentication methods ==== | ||
| 45 | As you have learned in the API Security microlearning, you can set multiple authentication methods to be active for your model in Design. Here in User Management, you can adjust which of those methods each of your users is allowed to use. You can navigate to this screen by clicking the edit icon on a user on the left side. OAuth 2.0 is activated by default. | ||
| 46 | |||
| 47 | [[image:Main.Images.Microlearning.WebHome@crashcourse-api-gateway-user-management--edit-user.png]] | ||
| 48 | |||
| 49 | Any changes you do in this screen, will be applied immediately without needing to deploy a release or click the ‘Apply to environment’ button. The new credentials will become available immediately after saving. Similarly, existing credentials will be deactivated immediately when saving after toggling off an authentication method. | ||
| 50 | |||
| 51 | ==== 3.2.3 Communicate Credentials ==== | ||
| 52 | When you simply click on a user on the left side, a panel will open on the right. Here you will find the credentials of your user for each of the activated authentication methods. You can share the relevant authentication information per user by copying all required fields to your clipboard and sending them to the relevant external parties in a secure manner. | ||
| 53 | |||
| 54 | [[image:Main.Images.Microlearning.WebHome@crashcourse-api-gateway-user-management--view-credentials.png]] | ||
| 55 | |||
| 56 | In this screen you are also reminded of the operations you have given this user access to. | ||
| 57 | |||
| 58 | ==== 3.2.4 Manual users ==== | ||
| 59 | You can give external systems access to your API Gateway even if they are not part of your eMagiz model by creating manual users. A manual user will get credentials in the same way normal users do but for manual users you manage permissions only in User Management. When clicking on the manual user, the operation permissions are editable. | ||
| 60 | |||
| 61 | [[image:Main.Images.Microlearning.WebHome@crashcourse-api-gateway-user-management--manual-user-create.png]] | ||
| 62 | [[image:Main.Images.Microlearning.WebHome@crashcourse-api-gateway-user-management--manual-user-permissions.png]] | ||
| 63 | |||
| 64 | Any changes made to manual users are applied to your running environment immediately. | ||
| 65 | |||
| 66 | ==== 3.2.5 Test the API as portal user ==== | ||
| 67 | Suppose you want to test the API operations yourself including the applied eMagiz security settings, you can create an API user based on your portal user. This can be done via the Import button. | ||
| 68 | |||
| 69 | Here you can select for which portal user you want to create a User. You can only choose those portal users that have access to this model. | ||
| 70 | Then, you must edit the user and add the API Gateway integration pattern. | ||
| 71 | |||
| 72 | [[image:Main.Images.Microlearning.WebHome@crashcourse-api-gateway-user-management--import-portal-user.png]] | ||
| 73 | |||
| 74 | Now, the permissions of the portal user can be managed just as for any other manual user. You can test your integrations with this user via the eMagiz generated Swagger page. | ||
| 75 | |||
| 76 | [[image:Main.Images.Microlearning.WebHome@crashcourse-api-gateway-user-management--edit-portal-user.png]] | ||
| 77 | |||
| 78 | == 4. Key takeaways == | ||
| 79 | |||
| 80 | * In Design, you can determine which operations your API users have access to | ||
| 81 | * You apply permissions in User Management in Deploy | ||
| 82 | * You can do advanced security configurations in User management in Deploy | ||
| 83 | * You can create portal users to easily test your API including testing the security settings | ||
| 84 | |||
| 85 | == 5. Suggested Additional Readings == | ||
| 86 | |||
| 87 | If you are interested in this topic and want more information, please read the help text provided by eMagiz and the following link. | ||
| 88 | |||
| 89 | * [[Crash Course (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]] | ||
| 90 | ** [[Crash Course API Gateway (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]] | ||
| 91 | *** [[Swagger UI (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.crashcourse-api-gateway-swagger-ui||target="blank"]] | ||
| 92 | * [[Intermediate Level (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.WebHome||target="blank"]] | ||
| 93 | ** [[Solution Architecture (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Solution Architecture.WebHome||target="blank"]] | ||
| 94 | *** [[System vs Multi-tenant System (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Solution Architecture.intermediate-solution-architecture-system-vs-multi-tenant-system||target="blank"]] | ||
| 95 | * [[Advanced Level (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.WebHome||target="blank"]] | ||
| 96 | ** [[Solution Architecture (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.Solution Architecture.WebHome||target="blank"]] | ||
| 97 | *** [[Key differences Design & Deploy Architecture (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.Solution Architecture.advanced-solution-architecture-diffs-design-deploy.WebHome||target="blank"]] | ||
| 98 | * [[Expert Level (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.WebHome||target="blank"]] | ||
| 99 | ** [[Securing Data Traffic (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.Securing Data Traffic.WebHome||target="blank"]] | ||
| 100 | *** [[Data Exchange (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.Securing Data Traffic.expert-securing-data-traffic-data-exchange||target="blank"]] | ||
| 101 | )))((({{toc/}}))){{/container}}{{/container}} |