How do I perform an entitlement aggregation using the Powershell SDK?

We have a ‘project template’ that makes a bunch of folders and uses PowerShell to make AD Groups.

I’d like to hook Access profile creation on this process.

The PowerShell SDK seems like the way to go for this:

PowerShell SDK | SailPoint Developer Community

I believe the steps are:

  1. Create AD Groups/folders/link them together/etc.
  2. Aggregate New AD Groups into SailPoint
  3. Create access profiles using powershell SDK

#3 seems easy enough using the powershell SDK.

However, I can’t wait for scheduled aggregation (an hour) between Steps 1 and Steps 3…

I want to do a quick aggregation and move on.

I know there is a web api to do an on-demand entitlement aggregation.

  1. Is there an equivalent powershell SDK Command?
  2. 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.

$tenant = "devrel-ga-5699"
$domain = "identitynow-demo"
$clientID = ''
$clientSecret = ''
$id = '942b267aaf3d467ca509865a937e211a'

$oAuthURI = "https://$tenant.api.$domain.com/oauth/token"
$token = Invoke-RestMethod -Method Post -Uri "$($oAuthURI)?grant_type=client_credentials&client_id=$($clientID)&client_secret=$($clientSecret)"

$url = "https://$tenant.api.$domain.com/beta/entitlements/aggregate/sources/$id"
$response = Invoke-RestMethod $url -Method 'POST' -Headers @{Authorization = "Bearer $token" }
$response | ConvertTo-Json
1 Like

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

darrenjrobinson/powershell_module_identitynow: SailPoint IdentityNow PowerShell Module (github.com)

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.

Hey @ccarlton,

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:

I was not aware of that sequence of commands. Thats pretty darn helpful now (I don’t have to repeat secrets).

I put in an enhancement ticket in the GitHub for eventually having a cmdlet that ties it all together a little more cleanly.

Thanks!

1 Like

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.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.