SWIS REST/JSON API Authentication alternatives

Hey guys,

Currently trying to work all my PS based scripts that were using SWIS Snapin to use REST Api instead, so I don't need to worry about the snapin being installed on workstations.

Is there any plan to have alternative authentication method to the API? Current basic schema requires me to type user/password to authenticate. This is not an issue for automated systems where credentials can be save in a secured place. However, when it comes to create small functions for admins to use on daily basis (aka unmanage/remanage), that would require to have either creds hard-coded in the PS script or locally (ugly) or to have the user 'repeating' his current credentials to query Orion. At least OAuth with tokens, for example for a local account, would be a plus.

Not sure if this is the best place to ask about future features though

Thanks!

Find more posts tagged with

basic_authentication

rest api

PowerShell

oauth

Accepted answers

All comments

tdanner

This is a fine place to ask about features. Another good place is here: Network Performance Monitor Feature Requests . There isn't a feature request section for the Orion platform, so these kinds of platform-level feature request land on NPM since it is the flagship product. That includes API-related requests (for example: ).

Since you are here, let's talk more about what you looking for. If you are staying in PowerShell (even if using the REST API instead of the normal Connect-Swis, Get-SwisData, etc.) you can use PowerShell's support for storing encrypted credential objects and using them with Invoke-WebRequest's -Credential switch. If you have standard file system path for storing this encrypted credential object, then you could share scripts with your admins. No credentials in the script, no unencrypted credentials on the disk, and no repeated prompting of Orion credentials. Would that work for you?

OAuth tokens could bring some other benefits like giving you the option to mint separate tokens for different tasks and revoke them without locking out an admin, allowing an admin to change their password without breaking scripts, etc. OAuth is more technically challenging for the primary IT admin audience of Orion's API, but it doesn't have to be an all or nothing thing. I think it would be a nice enhancement as long as it went with a good system for managing the tokens and good documentation and samples.

Another authentication feature the REST API could benefit from would be support for Kerberos (negotiate). Many Orion shops (especially the larger shops that tend to be heavier API users) use Active Directory for much of their Orion authentication, so it makes sense to support this in the REST API, not just through the PowerShell snapin.

FormerMember

Hey,

So what I'm looking for is to reduce as much as possible the requirements for every scripts going to our Solarwinds instance. At the same time, I'd like to keep tracking on who's doing what for reporting purposes.

When it comes to automated systems, it is fine, I have a set of specific service accounts for each of them, so I still have a proper level of follow up. But when it comes to users, I'd like them to be able to use without typing credentials, and I'd like to be able to track that down, like we do today with the SWIS snapin. But if I want to do that, it requires me either to use a shared account (I loose the tracking) or to have people entering credentials of some kind (I loose flexibility). Being able to use Kerberos like we do with the PS snapin would be the best! Typical use case here is to be able to unmanage/remanage servers on the fly : Get-ADComputer -Filter {name -like "*jbleh*"} | ForEach-Object {unmanage-node -servername $_.name -Hours 1}

I guess for now I can only stick to the SWIS snapin for users.

Thanks for your answer!