- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
In ServiceNow, integration users are often given broad roles to ensure API calls (REST, SOAP, or scripted) function smoothly e.g. ITIL role to external integration account. However, such excessive permissions could expose sensitive data if it’s not properly configured.
To mitigate such risks, integration accounts should follow the principle of least privilege, with role-based access tailored only to required tables and operations. This is where the Zurich release introduces Machine Identity Access Controls (MIAC), empowering administrators to precisely define table access as well as access type per integration user.
This will not only centralize all your integration accounts in one place but also control their privilege across the ServiceNow instance.
It’s a simple and straightforward setup based on SN docs where you define three key things.
API Access policy - This defines the type of access the integration account will get from ServiceNow. If your integration account is going to use REST endpoint, you can primarily define API Access policy based on REST method type – GET, POST, PUT, PATCH, DELETE. This is a powerful feature as you can now easily control that the integration account can only retrieve records from ServiceNow but not update or create them.If you plan to use SOAP web services, you can choose SOAP access policy and associate an authorization profile with it.
Tables – This allows to select multiple tables for which you want to provide access to integration account. No brainer, you can further select if you want to allow access to child tables as well.
User – Here, you select the integration user account itself! No brainer.
I then tried it with several combinations to see how it works in conjunction with ACLs.
Read Access to Incident table without user role account - I created a REST API access policy with GET method only in this case, selected table as incident and create a new user – ‘Incident read guest’. Bear in mind that I did not give any roles to this new user.
When I tried calling the incident table API from postman, I was able to receive a success message however there was no data returned.
This suggests that merely adding a user account to the MIAC form would not provide access of incident data to the integration account. The User account needs to be also provided with privileged access using roles which I tried in next combination.
This is continued in next blog.
- 270 Views
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.