Restricting which SWIS endpoints can be called

Hi Thwacksters

I am currently working on a project to expose the SolarWinds Orion SWIS API to our users with tightly controlled access. Our goal is to restrict which specific SWIS API endpoints (e.g., specific verbs) each customer can invoke.

We initially attempted to restrict access using responder policies on our load balancer, essentially intercepting SWIS traffic and blocking requests to specific endpoints. However, I would love to hear your take on this.

For example:
Prevent customer accounts from invoking /SolarWinds/InformationService/v3/Json/Invoke/Orion.Nodes/Delete

Find more posts tagged with

swis

PowerShell

sdk

API

Accepted answers

All comments

mesverrum

The API respects their user permissions, so if the user doesnt have node management they can't delete.

Now if you want to get to a situation where they only have a subset of the admin permissions you are probably just going to want to stand up a reverse proxy with rules restricting the endpoints and lock down the actual servers so they will only be open to requests from the proxy. I'm more familiar with nginx, but it sounds like you are using the netscaler equivalent capability.

www.f5.com/.../deploying-nginx-plus-as-an-api-gateway-part-2-protecting-backend-services

admin_nsn

Hi Mesverrum

Thank you for the answer!

Our organization is a bit special in the way that, we want to allow the node management permissions for our engineers in the GUI, but we're a bit worried about opening up for the API, in the sense the programmatically you can easily do "Delete *". Really, it's just some company politics I've to follow.

You're right that we've already looked in the reverse proxy direction using the Netscaler in front of our webservers, but this wasn't a possibility anyway.

I do think your suggestion using an nginx might be the way to go, but really I just wanted to know if there was any native way to support this within the Orion product itself.

Thank you again