Clarification on ACL rules for Inbound Rest api
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago
Dear all,
I need to build an Inbound Rest API in order to be able to update the short description of an incident.
For that I need to be sure at 100% that only a particular user will be able to hot that endpoint and beeing able to update the incident. I will need some clarification on the different place where ACL is mention as explain below . Thanks for your clarification on each question.
Please no need to send me the link of the documention because I go throuh it already and it is simply not clear to me
For that I have created first a kind of user account dedicated for Rest call with setting below :
Then I have added that user to a new rôle named "incident_api_update"
Then for the next step I have created my inbound REST APi as bellow :
As you can see from above , the base endpoint is set to "/api/iter/incident_update"
Then automtically the default ACLS as been set to "Scripted REST External Default"
Q1 : What is exaclty the purpose of the default ACL at this level and what it is protecting ?
The define resource for the endpoint has been done as below in the case of an Update
Ressource path : "/api/iter/incident_update/incident/{sys_id}"
Then from the REST endpoint resssource configuration there is 2 aspects which has been set as seen below, relative to security
Q2 : What is the effect of the ACL at this configuration stage vs the default we have seen at the Base path definition and do we need to place something ? For my case I did not place any ACL here but instead I have define the ACL at the role level show next
From the ACL configuration I have setup the following :
So the ACL is apply the the specify role where , the only define user is a member
Q3 : So compare to other place related to question 1 and 3 where there is a potential ACL to be define, what is then the difference of applying the ACL at the role level
Thanks for the clarification on this.
I understand it so that you can define the ACL at the root of the endpoint first and then having an other ACL at the ressource level for better granularity. I do not know if I made it and understand it correctly.
The goal is to be sure at 100% that no one except the autorise user can call the endpoint and make incident update through the PUT ressource
Thnaks for all
regards
