Posted on

SailPoint IdentityNow to ServiceNow Ticketing Integration

Sailpoint IdentityNow to ServiceNow Ticket Integration

SailPoint IdentityNow comes with many connectors to allow provisioning and lifecycle management of entities in connected systems. However there will always be those systems that require some manual tasks/input. In those instances SailPoint IdentityNow to ServiceNow Ticketing Integration can create a ticket in ServiceNow that can then be tracked whilst those manual steps are fulfilled.

Integration of IdentityNow with ServiceNow doesn’t use a connector in the same sense as the other Sources do in IdentityNow. It uses an Integration Module. The SailPoint ServiceNow Integration Module (SIM) is configured using the SailPoint IdentityNow integration APIs. The Integration Module Configuration Guide on Compass here provides the basis of what is required to List Integrations, Create, Update and Delete Integrations. However I had a few difficulties completing this due to a couple of ambiguous (from the sample documentation) configuration items. This post details how I got it configured so I can find it next time.

All the following API calls leverage authentication using the v3 API AuthN method I detail in this post here.

List Integrations

This call does exactly what it says it does; list any integrations such as IdentityNow to ServiceNow Ticketing Integration. If you haven’t configured any yet, then it will return nothing otherwise you will get the full configuration for each integration. To list integrations the /integration/listSimIntegrations API is called using a GET operation.

$orgName = 'yourIdentityNowOrgName'
$integrationBaseURI = "https://$($orgName).api.identitynow.com/cc/api/integration"
$listIntegrations = Invoke-RestMethod -Method GET -Uri "$($integrationBaseURI)/listSimIntegrations" -Headers @{Authorization = "$($v3Token.token_type) $($v3Token.access_token)"}
The output below is from an integration for an Application from IdentityNow to Service now that also brings through details for the request. More details on that below on Create Integration.

Create an Integration

To create an integration the /integration/createSimIntegration API is called using a POST request with a JSON Body containing the Integration configuration.

$createIntegration = Invoke-RestMethod -Method Post -Uri "https://$($orgName).api.identitynow.com/cc/api/integration/createSimIntegration" -Headers @{Authorization = "$($v3Token.token_type) $($v3Token.access_token)"; "Content-Type" = "application/json"} -Body $createBody

Create ServiceNow Integration Configuration Document

A lot of the configuration is prescriptive as per the IdentityNow documentation. However there are a few items that aren’t always obvious.

The configuration object further below is for integration from IdentityNow to ServiceNow using Basic authentication.

  • Line 4 is the ServiceNow Service Account created for IdentityNow with the permissions detailed in the IdentityNow documentation
  • Line 5 is the password for the Service Account
  • Line 7 is a piece that isn’t (or wasn’t) in the documentation when we configured this.
Important
In order for IdentityNow to pass through all the details for the account the request is for, you need to also have a ServiceNow Source configured. Make sure you have your Correlation Rules setup so that accounts in ServiceNow match/join to IdentityNow. Essentially this will match the ServiceNow Record for who the request is for and populate the Service Request with all their details (from ServiceNow). The Source is required to be able to pass the ServiceNow Account ID associated identity with the IdentityNow request.

The Source Configuration screenshot below shows the basic ServiceNow Source configured using Basic Auth. Make sure you have your Correlation configuration configured to appropriately join Accounts. Take note of the name you give the Source and the Source ID (visible in the Browser URL when configuring the Source).

  • Line 9 is the mapping from the IdentityNow Source (Flat File/Generic) that you will be sending Service Requests through to ServiceNow for, and the ServiceNow Catalog Item. The IdentityNow Source ID is the externalID. You will need to get the Source Configuration via API to get this as detailed in this post.
  • Line 12 is the Virtual Appliance Cluster where the Integration will be configured for. The clusterExternalId can be retrieved via API as detailed in this post. It can be found under Configuration on a VA Cluster object

  • Lines 13 – 23 are what you want to pass to ServiceNow for the Service Request. Modify accordingly but this example will pass through the details of the request from IdentityNow. Create or Update x, y, z etc.
  • Line 26 is the IdentityNow Source ID of the Generic/Flat file source you are configuring for integration with ServiceNow. It’s the same as you used on Line 9 for the IdentityNow to ServiceNow Catalog Item mapping.
  • Lines 29 – 34 are the status mappings for the requests. You can configure how often ServiceNow is polled for status updates through the integration/setStatusCheckDetails API. Send a POST request to the API with the provisioningStatusCheckIntervalMinutes and provisioningMaxStatusCheckDays as shown below for check every 15mins and max days 90 (dev environment type settings).
# Schedule for Status Checks
$schConfig = '{"provisioningStatusCheckIntervalMinutes":15,"provisioningMaxStatusCheckDays":90}'

$scheduleIntegration = Invoke-RestMethod -Method Post -Uri "https://$($orgName).identitynow.com/cc/api/integration/setStatusCheckDetails" -Headers @{Authorization = "$($v3Token.token_type) $($v3Token.access_token)"; "Content-Type" = "application/json"} -Body $schConfig

ServiceNow Integration Configuration Document

Below is a sample IdentityNow to ServiceNow integration configuration.

Example Request in ServiceNow

With all that detail and how to, this is what you actually get. Here is an example of a request that has been generated in ServiceNow from IdentityNow via ServiceNow Integration.

Get an Integration

If you know the ID of an integration you can get it directly using the /getSimIntegration/{ID} Get API call. The ID can be retrieved using List Integrations as detailed at the beginning of this post.

# Get Integration
$getIntegration = Invoke-RestMethod -Method Get -Uri "https://$($orgName).api.identitynow.com/cc/api/integration/getSimIntegration/2c9180846a6a22c8016a75adafake" -Headers @{Authorization = "$($v3Token.token_type) $($v3Token.access_token)"; "Content-Type" = "application/json"}

Delete an Integration

To delete an integration is similar to the Get Integration call except the API endpoint is /deleteSimIntegration/{ID} and the operation is a Delete rather than a GET.

# Delete Integration
$deleteIntegration = Invoke-RestMethod -Method Delete -Uri "https://$($orgName).api.identitynow.com/cc/api/integration/deleteSimIntegration/2c9180856a6a22d0016a6ec2a3fake" -Headers @{Authorization = "$($v3Token.token_type) $($v3Token.access_token)"; "Content-Type" = "application/json"}

Summary

Rather a long post, but hopefully it will give anyone else trying to do this integration the leg up on how to get it operational a lot quicker than it took us.

Posted on

Get/Update SailPoint IdentityNow Global Reminders and Escalation Policies

SailPoint IdentityNow Access Requests for Roles or Applications usually require approvals which are configured on the associated Role or Application. The Approval could be by the Role/Application Owner, a Governance Group or the Requestor’s Manager. However for reminders and escalation policies the configuration is only available to be retrieved and set via the API. The SailPoint Identity Now api/v2/org API is used to configure these Global Reminders and Escalation Policies.

This post details how to get the configuration of your IdentityNow Org along with updating the the Global Reminders and Escalation Policies.

The PowerShell script below uses the v3 API Authentication process detailed here.

Update the script below for;

  • line 2 for your IdentityNow Orgname
  • line 5 for your IdentityNow Admin ID
  • line 6 for your IdentityNow Admin Password
  • line 16 for your Org v3 ClientID (obtained from SailPoint)
  • line 17 for your Org v3 ClientSecret (obtained from SailPoint)

Executing the script Line 35 will return the current configuration for your SailPoint IdentityNow Org.

$listOrgConfig = Invoke-RestMethod -Method GET -Uri "https://$($orgName).identitynow.com/api/v2/org" -Headers @{Authorization = "$($v3Token.token_type) $($v3Token.access_token)"}
  • lines 39-43 specify the configuration values for
    • daysBetweenReminders – Number of days between reminders or escalations
    • daysTillEscalation – Number of days from when the request is created to when the reminder/escalation process begins
    • maxReminders – Maximum number of reminders sent before starting the escalation process
    • fallbackApprover – The alias of the identity that wlll review the request if no one else reviews it
  • lines 46-50 build the configuration to write back to IdentityNow

and finally Line 53 updates the configuration in IdentityNow

$updateOrgConfig = Invoke-RestMethod -Method Patch -Uri "https://$($orgName).identitynow.com/api/v2/org" -Headers @{Authorization = "$($v3Token.token_type) $($v3Token.access_token)"; 'Content-Type' = 'application/json'} -Body ($approvalConfigBody | convertto-json)

The updated configuration is returned in the $updateOrgConfig variable. The following snippet shows the written config for Reminders and Escalations.

SailPoint IdentityNow Global Reminders and Escalation Policies
SailPoint IdentityNow Global Reminders and Escalation Policies

The Script

Will all the details described above, here is the script.

Summary

Using PowerShell with the v3 Authentication method and the v2 IdentityNow Org API  we can quickly get the Organisation configuration. We can then quickly update the Global Reminders and Escalation Policies. With a few changes other customer configurable (the majority are read/only) configuration options on the Org can also be updated. 

Posted on

Querying SailPoint IdentityNow Virtual Appliance Clusters with PowerShell

Today I was configuring an Integration Module for SailPoint IdentityNow. As part of that integration I needed the ID of an IdentityNow Virtual Appliance Cluster. It seemed I hadn’t previously documented doing this and I couldn’t find my previous script. So here’s a quick post for the next time I need to get info about the SailPoint Identity Now Virtual Appliance Clusters in my environment.

The following script uses v3 Authentication as detailed in this post.

Update;

  • line 2 with your IdentityNow Orgname
  • line 5 with your Admin Account Name
  • line 6 with your Admin Password
  • line 16 with your IdentityNow v3 API Client ID
  • line 17 with your IdentityNow v3 API Client Secret

 

 

Posted on

Indexing a SailPoint IdentityNow Attribute in an Identity Cube for use in Correlation Rules

Joining/Matching rules in any Identity and Access Management Solution can make or break an Identity Lifecycle Management implementation. Out of the box SailPoint IdentityNow provides a number of common Identity Attributes that can be used for Correlation rules (joining/matching) from Identity Sources (connected systems).

Often though you want to add additional attributes to the list of Identity Attributes that can be used for correlation. The IdentityNow Portal does not provide this functionality, but it is possible via the IdentityNow API. However the documentation and guidance around this is a little sparse. This post details how to use the API to enable additional attributes for use with correlation rules.

NOTE: The guidance is to be pragmatic with the number of additional attributes that you add as Identity Attributes for Correlation. The guidance is a maximum of 7 additional attributes 

Prerequisites

  1. Authentication. I using the v3 method that I detail here
  2. On an Identity Profile you’ll need to map the attribute from a Source to an attribute in the Identity Profile.
    • In the IdentityNow Portal go to Admin => Identities => Identity Profiles => Your Identity Profile => Mappings => Add Attribute

Process

I’m using PowerShell, but the process can be transposed to any language that you can use to make Web Requests. The high-level process is;

  1. Get the list of Identity Attributes
  2. Locate the attribute you want to be available for Correlation rules
    • this is required as addressing the attribute to make it available is case-sensitive
  3. Update the object to make it Searchable
    • making the attribute Searchable promotes it to being available for Correlation Rules

The Script

The steps in the script below assume you are authenticated to the IdentityNow API as detailed in the prerequisites. You should only need to then update line 12 for the attribute name you want to make searchable and available for correlation rules.

The script steps (that you will want to manually step through);

  •  Get the list of Identity Attributes
    • The attribute you want to promote to be searchable should be present, as you’ve mapped it in an Identity Profile as detailed in the prerequisites
  • Get the attribute to modify
  • Modify the attribute object to make it searchable
    • modify other aspects of the Identity Attribute to allow the attribute changes to be written back to IdentityNow
  • Update the attribute in IdentityNow

Summary

As the script above shows, the process to update an attribute to make it searchable and available for correlation rules is a little more involved that just flipping an attribute value, but once you know how reasonably trivial.

Posted on

Building SailPoint IdentityNow Azure AD Source Filters

When you have a large Azure AD tenant it is likely that you want to scope your SailPoint IdentityNow Source based on the different type of identities it contains. Using the Filtering and Scoping section of the Azure AD Source Configuration Guide from Compass I first started constructing queries as I normally would with Azure AD against the Microsoft Graph API.

However the queries/filters I was using against Microsoft Graph were not working for the Azure AD IdentityNow Source. On aggregation the Source Connector would throw errors such as;

….java.lang.RuntimeException – sailpoint.connector.ConnectorException: Exception occurred. Error message – Exception occurred in processReadRequest. Error – Response Code – 400 Error – Bad Request Property ‘msGraphAADAttribute’ does not exist as a declared property or extension property…..

Following some discussions with the IdentityNow Professional Services guys I learned that the IdentityNow Azure AD Source Connector uses the Azure AD v1 Graph API endpoint.

With this information I was then able to use the Azure Active Directory v1 Graph API Explorer to develop queries that would then work for ‘User Filters’.  This is extremely quick and useful. For guidance on using Azure AD Filters this Microsoft document will get you started.

Azure AD v1 Graph Filter Tester.PNG

Configuring Azure AD Source Filters

To configure Source Filters for the IdentityNow Azure AD Source I use PowerShell as per the many IdentityNow Configuration and Automation posts I’ve previous written.

SailPoint IdentityNow Authentication

The script snippets below just show the commands to create three different Azure AD Source Filters (if you need all three like me you will need to configure three separate Sources with a different filter on each). In order to utilise these you will need to be authenticated to the SailPoint IdentityNow API. This post details connecting to the SailPoint IdentityNow v3 API endpoint using PowerShell.

Below shows three snippets for scoping the Azure AD Source down to specific User Types;

  • AAD Guest Accounts (B2B)
  • AAD Hybrid Accounts (On Premise AD and Azure AD)
  • AAD Cloud Only Accounts

To update a source you send a POST request to the Update Source API where yourOrg is your Tenant Org Name and SourceNumber is the number of the Source to update (e.g. 12345). The body is the connector_userFilters attribute with the value for the filter.

https://yourOrg.api.identitynow.com/cc/api/source/update/SOURCENumber

Hybrid Accounts

The following shows the tail of the output from the returned object after updating the Source for a filter for Azure AD Hybrid Accounts;

dirSyncEnabled eq true and userType eq 'member'

Hybrid Users.PNG

Azure AD Cloud Only Accounts

The following shows the tail of the output from the returned object after updating the Source for a filter for Azure AD Cloud Only Accounts;

dirSyncEnabled eq false and userType eq 'member'

Cloud Only Users.PNG

Azure AD Guest (B2B) Accounts

The following shows the tail of the output from the returned object after updating the Source for a filter for Azure AD Cloud Only Accounts;

userType eq 'guest'

B2B Guests.PNG

Summary

Knowing the API the IdentityNow Azure AD Source is using allows us to construct filters to scope the Azure AD Source to the specific users for an implementation.

Posted on

Changing SailPoint IdentityNow Identity Profiles Priorities using PowerShell

In SailPoint IdentityNow a single user is highly likely to be represented on multiple Sources, that in turn are likely to be authoritative for differing SailPoint IdentityNow Identity Profiles. Often the first or last Identity Profile you create isn’t the one you wish to have the highest or lowest profile and you therefore need to change an Identity Profiles precedence so that the correct Identity Profile is associated with your identities.

The priority of IdentityNow Identity Profiles cannot be changed through the Portal, but it is possible to perform the change via the API as detailed in this Compass document.

Rather than following the Postman path described in that document, knowing I’m going to need to do this irregularly but relatively quickly I’ve written a little PowerShell script to make the changes.

By default an Identity Profile when created is added to the bottom of the list and their priority increased by 10 from the last Identity Profiles’ priority. The script will by default make the Identity Profile you choose 5 higher that the Identity Profile you’re moving it above.

The following screenshot shows 5 Identity Profiles in their priority order. Let’s say we wanted to move the System Accounts Identity Profile from the bottom priority to between Cloud Identities and Badged Identities.

IdentityNow Priority List.PNG

Using the script (at the bottom of this post) we can authenticate to IdentityNow and retrieve the IdentityNow Profiles with their Priorities. It will ask which IdentityNow Profile you wish to increase the priority of. By default it defaults to the one at the lowest priority.

Identity Profile Priority Changer 1.PNG

You are then prompted for where you would like to move it. Type the name of the Identity Profile you want to move it above.

Identity Profile Priority Changer 2a.PNG

Confirm your selections by typing ‘y’. Anything else will cancel the operation.

Identity Profile Priority Changer 3.PNG

The update will be made in IdentityNow and the output will indicate the updated priority given to the Identity Profile that was moved.

Identity Profile Priority Changer 4.PNG

Checking in the IdentityNow Portal we can see that they Identity Profile was moved from the bottom to between Cloud Identities and Badged Identities.

IdentityNow Priority List Updated.PNG

The Script

Below is the script that performs the changes to Identity Profiles priorities. Update the following script for;

  • Line 2 for your Client ID
  • Line 4 for your Client Secret
  • Line 8 for your Org name
  • Line 10 for your Admin Account name
  • Line 11 for your Admin Account password

Summary

Using this script is a quick way to change the priority of Identity Profiles in SailPoint IdentityNow.

Posted on

SailPoint IdentityNow Identity Profiles Mapping Report

Last year I wrote this post here that detailed using the SailPoint IdentityNow API to generate an IdentityNow Sources HTML Report using PowerShell.
In a similar vein here is a post that does a similar function, but for the IdentityNow Identity Profiles. The example script below will connect to IdentityNow and extract all the Identity Profiles and pull out the details for the Mappings and create an HTML Report with a section for each Identity Profile.

SailPoint IdentityNow Identity Profiles Report.PNG

Report Script

Update the script below for;

  • Line 2 for your v1 API ClientID
  • Line 4 for your v1 API Client Secret
  • Line 8 for your Org Name
  • Line 10 for your Admin Name
  • Line 11 for your Admin Password
  • Line 22 for an image path for the report
  • Line 27 for the output path for the report

The Report

The resulting report that will be located in the output path you specified, will let you expand each of your Identity Profiles and see the attributes mapping configuration associated with it. A snippet of an Identity Profile is shown below.

SailPoint IdentityNow Identity Profiles Report Details.PNG

Summary

The ability to report on the attribute mappings for Identity Profiles gives a quick way to document or report on the attribute mappings. If you’re so inclined the script can be easily extended to report on all other aspects of the configuration items of an IdentityNow Identity Profile.

The image I’m using in the report is from this page and sized at 240 x 82 px.

Posted on

Aggregating SailPoint IdentityNow Sources via API with PowerShell

Aggregating an IdentityNow Source can be achieved in a number of ways, but when you are in a development environment there will be times where you need to add additional attributes for a Source to load. If the additional attribute(s) is/are used for Correlation, it’s at this time you will need to perform a full aggregation from a Source to re-evaluate each object with the new Correlation rules and to bring in the additional attributes for each identity on the Source.

The LoadAccounts API briefly mentions this in this SailPoint IdentityNow Compass document. It also details the option that needs to be disabled disableOptimization so that each identity is imported and re-evaluated.

This post details how to call the LoadAccounts API using PowerShell and disable optimization.

Prerequisites

The LoadAccounts API is a Private API that has a different authentication process that the v2 and v3. In this post I detail accessing the v1 Private API’s using PowerShell.  That post gives some more detail around the v1 Private API’s.

The following script will aggregate a SailPoint IdentityNow Source disabling optimisation.

Update;

  • Line 2 with your API ClientID
  • Line 4 with your API Client Secret
  • Line 8 with your IdentityNow Org Name
  • Line 10 with your IdentityNow Admin Account Name
  • Line 11 with your IdentityNow Admin Account Password
  • Line 25 with the SourceID (5 digit number) for the Source to Aggregate

Line 29 contains the Web Request Post Body “disableOptimization=true” that disables optimisation for the aggregation. If you just require an aggregation of a source omit the body.

Executing the script with valid credentials and a Source will result in the aggregate variable returning a summary for the trigger of the aggregation. You will notice in the attributes that optimizedAggregation is disabled.

Returned Object when initiating IdentityNow Aggregation via API with optimisation disabled.PNG

This is also reflected in the Aggregation Summary from the Portal when completed.

IdentityNow Aggregation via API with optimisation disabled.PNG

Summary

Using the above script it is possible to quickly perform a full aggregation and re-evaluation of correlation rules for an IdentityNow Source.

 

Posted on

Creating SailPoint IdentityNow Access Profiles via API and PowerShell

Managing SailPoint IdentityNow Access Profiles is easy enough to do using the SailPoint IdentityNow Portal. But what if you have the requirement to update, report on, or create numerous Access Profiles? That’s where the SailPoint IdentityNow API comes into play. The Access Profiles API is documented here but doesn’t go into a lot of detail. In this post I’ll detail interfacing with it using PowerShell primarily to create and update Access Profiles.

Prerequisites

You will need to Authenticate to the IdentityNow API. Both v2 and v3 authentication methods work. I detail the v2 method here and the v3 method here. Personally I’m using the v3 method. Just make sure you change your Headers for the requests to whatever method you use and the naming of your variables.

For reference my v3token variable is $v3Token so my Authentication Header is then @{Authorization = “$($v3Token.token_type) $($v3Token.access_token)”}

Getting Access Profiles

The Access Profiles API URI is

https://$($yourOrgName).api.identitynow.com/v2/access-profiles

If you know the ID of the Access Profile you can return just that Access Profile via it’s ID (where $accessProfileID is the ID that looks like 2c91808466a64e330112a96902ff1f69)

https://$($yourOrgName).api.identitynow.com/v2/access-profiles/$($accessProfileID)

The following script will return Access Profiles from your SailPoint IdentityNow Tenant. Update;

  • Line 2 for your IdentityNow Org name

Updating Access Profiles

To update an Access Profile the API URI is;

https://$($orgName).api.identitynow.com/v2/access-profiles/$($accessProfileID)

The following will update an existing Access Profile to make Request Comments Required and Denied Comments Required equal False.

Update;

  • Line 2 for your IdentityNow Org name
  • Lines 6 for the ID of the Access Profile you want to update
  • Lines 9,10 for the settings to update

Preparing to create an Access Profile

In order to create an Access Profile, there are a number of configuration items that you will need to provide. The key items are;

  • SourceID is the (currently) five digit ID of a source that you can get from the IdentityNow Portal when looking at the properties of a Source. Or via API as I detailed in this post.
  • OwnerID is the Identity ID for the user you will make the owner. To do that you will need to query IdentityNow for the user (see below for an example)
  • Entitlements
    • In order to get the Entitlements ID(s) to assign to the Access Profile you will need to query the Source. This post here details querying Sources to get Entitlements whereby you can get the ExternalID of Entitlements.

Search for Owner ID Request Object

Here is an example Search Request JSON Object required for the Search User call. Update it for a unique attribute for an Identity to query and return.

Update for your criteria. e.g if you copy the JSON below;

  • create a variable name
    • $requestFilter = ‘JSON snippet content from below’
  • Update the search criteria for your search
    • $newRequestFilter = $requestFilter .Replace(“darren.robinson@customer.com.au”,”yourUser@mydomain.com”)
  • Then search for the user and get the ID of the identity
  • Update
    • Line 2 for your Orgname
    • Line 8 for the user to search for that matches the JSON object from above

Creating an Access Profile

Finally, now that we have the prerequisite information to create an Access Profile we can create it. Modify for your environment based off information retrieved from the processes above. Namely;

  • Line 1 for your Orgname
  • Line 2 for the SourceID associated with the Access Profile
  • Line 3 for the Access Profile Owner’s ID
  • Lines 7-10 for your Access Profile Details
  • Line 14 for the Entitlements
  • Line 19 for the Approver (see below for more details)

Access Profile Approvers

For Approvers you can provide the order for approval. For the approval by the Access Profile Owner and then the Manager use the following when creating the Access Profile in Line 19 above.

  • $accessProfile.add(“approvalSchemes”,”accessProfileOwner, manager”)

Other options are:

  • SourceOwner
  • appOwner
  • Governance Group. See managing Governance Groups here to get the Governance Group ID (GUID format)
    • workgroup: 86929844-3391-4ce2-80ef-760127e15813

Summary

Whilst the creation of an Access Profile via API does require some configuration, if you have multiple to create and you know the criteria it is possible to automate the task. I hope this helps others.

 

Posted on

Searching and Returning SailPoint IdentityNow Entitlements using the API and PowerShell

Entitlements on IdentityNow Sources can be leveraged for many purposes within IdentityNow. Recently I’ve been looking to automate some Access Profiles that will in-turn have entitlements associated with them.

This post details how to query for Entitlements in IdentityNow using the v3 API and PowerShell.

Prerequisites

You will need to Authenticate to the IdentityNow API. The v3 authentication method is required. I detail the v3 method here. The Headers for the requests detailed in this post use the following variables for the JWT oAuth Token.

My v3token variable is $v3Token so my Authentication Header is then
@{Authorization = “$($v3Token.token_type) $($v3Token.access_token)”; “Content-Type” = “application/json”}

Searching for Entitlements

The Base API URI to search for entitlements is;

https://$($org).api.identitynow.com/cc/api/entitlement/list

You will also need to provide a timestamp and a source for which you want to retrieve entitlements for.

Generating the Timestamp

The timestamp is in Unix format which can be generated in PowerShell like this;

$utime = [int][double]::Parse((Get-Date -UFormat %s))

Getting a list of Sources

I’ve previously described listing IdentityNow Sources in this post and this post. Essentially though you can return a list of all sources by performing a GET request to

https://$($orgName).api.identitynow.com/cc/api/source/list

Obtain the Source ExternalID from the source of  your choice that you then wish to return entitlements for.

Entitlement Results

You can limit the number of entitlements returned by using the limit option. The following will return the first 1000 entitlements for a source starting at 0

&start=0&limit=1000

If the source has more than 1000 then you will need to page the results to return the next 1000 results. Continue until you’ve returned all.

&start=1000&limit=1000

Of course you can just not provide a limit and all entitlements will be returned in a single call.

Finding an Entitlement on a Source

Using the power of PowerShell it is quick to find the Entitlement you want if you know some of the information about it. For referencing an Entitlement when creating an Access Profile via the API you will need the Entitlement ID  e.g

$myEntitlement = $sourceEntitlements.items | Select-Object | Where-Object {$_.displayName -like "*Sydney*"}
$myEntitlement.id

Summary

Using the IdentityNow API and the v3 endpoints we can retrieve entitlements for a Source and quickly locate the entitlement and the entitlement ID for use during automation of IdentityNow tasks such as Access Profile creation.