SailPoint ISC - CyberArk integration

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

@hranjan3 - I think you were working on a similar issue, and I could use your help if you’re still active here.

Web Service Connector response mapping error - Identity Security Cloud (ISC) / ISC Discussion and Questions - SailPoint Developer Community

I’m testing out building a custom SailPoint ISC → CyberArk Privilege Cloud integration using the Web Services SaaS connector. I was able to get authentication working correctly (Test Connection works), but for some reason it is not finding any accounts on aggregation. It says successful, but Objects scanned are always 0.

I am using:

  • Response information → Root path: $.value
  • Response mapping → address:address (same as the link above)

Here is sample output when I call the same endpoint using PowerShell with the same service credentials:

Response
@{value=System.Object[]; count=1}

Response.value
@{categoryModificationTime=1740073553; platformId=XXX; safeName=XXX; id=XXX; name=XXX; address=XXX; userName=XXX; secretType=XXX; platformAccountProperties=; secretManagement=; createdTime=1740073552}

Thanks a lot!

2

The actual json response may help:

{
  "value": [
    {
      "categoryModificationTime": 1740064734,
      "platformId": "XX",
      "safeName": "XX",
      "id": "XX",
      "name": "XX",
      "address": "XX",
      "userName": "XX",
      "secretType": "password",
      "platformAccountProperties": {
        "LogonDomain": "XX"
      }
  ]
}
3

Have you tested hitting the API endpoints in postman using an access token from the account you’re using in sailpoint? I assume so but it wasn’t clear.

Also out of curiosity, what API endpoints are you planning on using? I’m working on a custom SaaS connector for CyberArk and I’m interested in the approaches that others are taking

4

This output is what comes from the API endpoint
https://{{saasSubdomain}}.privilegecloud.cyberark.cloud/passwordvault/api/accounts

which would return accounts that exist within safes in your vault. When building a connector, wouldn’t one typically want to retrieve the users who have access to the safes instead of the accounts that exist within the safes?

5

Thanks Mark. We are already using the out of the box Sailpoint ISC connector for CyberArk identity users. But the ISC connector does not support managing CyberArk EPV accounts via SCIM, so I’m trying to build this custom connector using the REST API.

The JSON output I posted above is from a postman call using the same account I have configured in ISC.

6

I’m curious, if you aggregate a vault account as opposed to a vault user, what do you do with it in sailpoint? There wouldn’t be any entitlements in cyberark associated with a vault account, right?

7

We are managing privileged user accounts for an application that is using Sailpoint for user provisioning. So the flow I’m trying to build is something like:

  • User requests access to sensitive app
  • Sailpoint creates account in app
  • Sailpoint adds the account to Cyberark
  • Sailpoint grants the user access to Cyberark

That way Sailpoint can also off board the account from the app and Cyberark automatically.

1 Like
8

Oh ok, that’s a cool use case! Thanks for sharing. I wish I could be more help on your particular issue, sorry

Do off the shelf saas connectors provide the same logging as the custom ones? For my custom ones I use the sailpoint sdk command sail conn logs tail so I can watch the log messages.

It’s possible for a web service saas connector that it might print the response body to that log, but I’m not sure

9

This is indeed a cool use case.

Once you get this working, please:

-write it up for the Dev community here
-post a ‘buy me a coffee/beer’ link.

:slight_smile:

10

Haha, thanks guys. Unfortunately, I realized this approach will not work, as SailPoint does not allow you to have multiple accounts per source, so I would have to have CyberArk sources for each privileged application a user could have an account in. In addition to the normal (non-CyberArk source).

What I am pursuing now is a workflow to simply sync the accounts to CyberArk. Something like:

  1. Account created in source

  2. Onboard account into CyberArk

  3. Account deactivated in source

  4. Remove account from CyberArk

That should be doable, but SailPoint workflows seems a bit lacking. There is a “Source account created” trigger, but it’s still in early access, so I’m not sure I’d want to rely on it for a critical workflow.

1 Like
11

Since we’re a Servicenow shop and I was a servicenow developer before being a sailpoint engineer then I’d be doing this work using servicenow workflows, but that’s just me

1 Like
12

I’m not certain if this is even relevant anymore given the turn this conversation has taken, but you should be able to parse the data if you change your Response information Root path to: $.value[*]

13

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