If there isnt a powershell command does the powershell SDK have a bearer token helper command? (something to use the existing credential config that will generate a bearer token to make it easy to call http requests that are not yet powershell commands)
I did not see that endpoint in the SDK, but you should be able to call that without it. First get your access token via your personal access token and then call the aggregation endpoint. I pulled the PowerShell example from the docs but made adjustments to the headers.
I was using the PowerShell module to avoid having to manage a bearer token.
I already have clientSecret, clientID, and baseURL setup to make the PowerShell module work, and now I either need to put these credentials/config in a second place or parse the powershell module’s config.json manually.
Overall, I was hoping that SailPoint was providing a cmdlet for aggregation.
Or at a minimum a catchall helper cmdlet that helped us when SailPoint didn’t provide a direct cmdlet.
For example, here’s another powershell module for IDN from ~3 years ago that has such a helper.
Invoke-IdentityNowRequest -API Private -path "identityAttribute/list" -method Get -headers HeadersV3
That sort of rest helper is fairly common (MS graph has it also etc)…
It allows you to use the module already configured auth, and rest client to easily call api’s without having to duplicate config or rest client code.
SailPoint needs to add that sort of helper to their PowerShell module.
For the time being you can call the cmdlet Get-DefaultConfiguration. This will load your configuration through environment variables or through the config.json.
Then to get an access token you can call Get-IDNAccessToken.
With that being said, I will work on releasing a new version of the SDK that has a cmdlet for the new entitlement aggregation.
You also make a good point with the default web request where the authentication header is taken care of for you. Would you be willing to create a feature request here:
No problem! We are working to improve our release cycles to keep the SDKs update to date.
I do have a follow up question. If the SDKs stayed up to date with the latest API releases consistently and a cmdlet is available for every API call. Would you still want/wish there was another method like in Darren’s module for a free-form API caller?
I do think the value of a free-form Api caller decreases if the SDK is able to keep pace, but from the outside looking in, it looks like APIs deprecate/change at a frequency that is independent of SDK releases.
(But maybe you guys are considering using some sort of generative code tool that works off the swagger, and are more confident about keeping this lockstep? IDK)
With the commands provided previously my immediate concern around the extra handling of the auth is covered, so I’m good.
It’s important to note that I would consider us light / simple users of the APIs. Other than that on-demand entitlement aggregation call, we haven’t found gaps in the SDK — You’re probably better off finding a larger/more robust ISC customer TBH that has more complex use cases.