Service Catalog API - how can I control which catalog items an API can submit?

Jeff316 · ‎11-12-2018

We have an internal IT group that wants to submit catalog requests (for existing catalog items) using the API. We want to be able to control which catalog items they can submit. Ideally we would like to do that per the User ID we give them so maybe it can follow the User Criteria applied to each catalog item? Such as SC_API_USER has access to 7 of 10 catalog items. If that's not possible how to we control what they do with that Service Catalog API at the record level to what they can see with it?

jacob_benker · ‎11-12-2018

I actually just finished doing this recently. In the end I decided to create a new Service Catalog API so that we had full control over it without modifying the baseline version. However, the baseline Service Catalog API is in a scoped application and you could add an ACL to it so that only accounts you specify can submit via the API. This only limits which account(s) can submit via the API but does not limit what they can submit. For that you can use User Criteria and Available For/Not Available For at the catalog item level. If you go with modifying the baseline version, you should create a role, like u_sc_api, and create a User Criteria for users with that role. Then create your service account and grant it that role. Next you should set the User Criteria in the Not Available For for all catalog items that you do not want this account to be able to submit. (Note: doing it with the Not Available For does cause you to touch more catalog items but it limits the possibility of the catalog no longer being available to users in the catalog. If you use the Available For then it is only available for the User Criteria defined users.) Next, create REST execution ACL granting access to your new role. Call it some meaning full like “Custom Service Catalog Access” Finally, associate that ACL with the Service Catalog API. Now only accounts with that role can use the Service Catalogue API and that role only has acces to a limited number of catalog items. I would recommend updating your update to allow the API to be updated from upgrades. Don’t want to miss out on future enhancements to it. You’ll just have to add it to you post upgrade\patch steps to re-apply the ACL and reset that upgrade flag. Creating our own version of the API didn’t save any steps but we have full control over it and don’t have to worry about upgrades. We’ve even created custom methods with in it and have ACL control at the over all API and at the method level.

Jeff316 · ‎11-13-2018

Jacob,

I cannot thank you enough for helping me. I am going to work on this today.

I might have some additional questions if you are available. I owe you a cup of coffee.

When this other internal IT group came to me and asked for access to use the ServiceNow APIs, at first it was just for incidents then to query CIs. I created a user record and added the web_service_admin role and set the flag "Web service access only" =True.

When I gave them that user ID/PW with the role of web_service_admin is that what gave them access to all the APIs?
Should I have been more selective in the roles I gave them?
If I create a new custom ACL just for the Service Catalog API, is that the only role they need or will they need others such as 'catalog' or 'ITIL'?
Can I take away the web_service_admin role?
Do I need to and how would I inactivate the oob Rest API? The fields are all protected.
How can I assign a custom ACL to the oob Rest API (if I didn't want to create a custom API)?
Can I disable the oob Rest API and create a copy?
How can I tell what is being done through Rest API access? I don't have a good handle on what this group is doing with the access I've given them?
Is there a finite list of API that are available and open to web_service_admin?

jacob_benker · ‎11-15-2018

Most of the answers can be found on the ServiceNow Docs site.

The first thing I would recommend, if you don't already have it, is that you download Postman. You can use it to test the APIs and credentials before giving them to other teams.

They don't need the web_service_admin role. That role gives access to create new scripted web services. They just need a local account, APIs use basic authentication or OAuth. If you don't give them any role they function as a requester and can log tickets and do some updates.

Usage can me tracked under System Web Service > REST & SOAP Analytics. You can also use some reports like Tasks 'opened_by' the service account.

Unfortunately, you are correct. The baseline API is protected. Only ServiceNow could modify it. However, keep in mind that the APIs honor ACLs and other security controls. So for the account logging incidents and pulling CI data you can make sure, in the system, that account can only create Incidents and has read-only access to CI data. You might create a role and ACLs to set that up. Same with the catalog. You would set the 'Available for' and/or 'Not Available for' on your catalog items so that the service account can only access the catalog items you want it to.

Jeff316 · ‎11-15-2018

Thanks again.

So I should think of this user like any other user, they just happen to be using API to do things.

If I give this "service account" itil role, its just like they are using the GUI and follow all ACL.

So what would keep all users from using APIs?

Do I create a custom ACL with type = Rest_Endpoint and declare a "special role" is required?

What in the ACL record would identify the API I want to restrict? The Name of the ACL should be the path of the API?

I get now, that I can just use the "service account" i gave them in the "user criteria" of the catalog items I don't want them to see. Although, I would need to ensure they just don't use their own ID for the API which can see all catalog items. Anyone using a catalog API is to be limited more than what any itil or regular user can see.

I will install postman on my personal PC. Can't install anything on work PC. Thanks for the Postman tip.