Can we use CyberArk external credential integration to store basic authentication credentials
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi all,
Can we use the CyberArk External Credential Integration to store Basic Authentication credentials for integrations?
We opened a ticket with ServiceNow Support, and they confirmed that the following credential types are supported:
- GCP
- Azure
- CIM
- JMS
- SNMP Community
- SNMPv3
- Basic Authentication
- SSH Key Pair
- SSH Private Key (with key and password)
However, based on our understanding, this support appears to be limited to the Discovery context.
We would like to validate the following use case:
We have a third-party REST-based integration that connects to an external system using either Basic Authentication or OAuth. This is not a Discovery integration. The integration will use REST methods (GET, POST, etc.) to retrieve data from the third-party system and store it in ServiceNow.
Can the CyberArk CCP integration be leveraged to securely retrieve and use credentials for this type of non-Discovery integration?
Thanks,
Ravish
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @RavishShett
Yes, you can use CyberArk external credential storage for a non-Discovery integration, but there is an important detail: the REST call needs to use a MID Server so that the MID can resolve the credential from CyberArk.
ServiceNow’s current documentation explicitly lists REST as a supported protocol for credentials stored in CyberArk, including the REST Step in Workflow Studio and REST activities using Basic Authentication. So the CyberArk integration is not restricted to Discovery/Service Mapping.
https://www.servicenow.com/docs/r/platform-security/connections-and-credentials/c_CyberArkCredStorag...
For Basic Authentication, you can create a Basic Auth credential in ServiceNow, select External credential store, and provide the CyberArk Credential ID instead of storing the username/password in ServiceNow. The MID Server resolves that ID against CyberArk when the connection is executed.
https://www.servicenow.com/docs/r/platform-security/connections-and-credentials/r_BasicAuthCredentia...?
So conceptually:
ServiceNow → MID Server → CyberArk CCP → retrieve credential → REST call to third party
I would avoid retrieving the username/password yourself with a custom script and then storing or passing it around ServiceNow. The external credential framework is designed specifically so ServiceNow only keeps the credential identifier while the actual secret remains in CyberArk.
https://www.servicenow.com/docs/r/platform-security/connections-and-credentials/c_ExternalCredential...
For OAuth, there is also an OOB option now. ServiceNow supports storing the Client ID and Client Secret in CyberArk and having the MID Server retrieve them when requesting the OAuth token. One limitation to be aware of is that the documented external-vault OAuth implementation currently supports the Client Credentials grant type.
https://www.servicenow.com/docs/r/platform-security/connections-and-credentials/oauth-2-0-support-in...
The configuration even exposes an External Credential Store option when configuring the OAuth connection through a specific MID cluster.
https://www.servicenow.com/docs/r/platform-security/connections-and-credentials/configure-oauth-2-0-...?
So I would say the answer is yes, provided the integration is designed to execute through the MID Server. If you are making a REST call directly from the ServiceNow instance without a MID Server, I would not expect the CyberArk external credential resolver to be involved.
Also, since you specifically mentioned CCP, ServiceNow added REST API support for CyberArk CCP to the External Credential Storage and Management application, so CCP is now an OOB supported approach alongside the older AIM SDK model.
https://www.servicenow.com/docs/r/store-release-notes/store-rn-itom-external-credential-storage-mgmt...
Also, take a look at the ServiceNow (documentation links below), as they provide some additional context on the configuration and supported behavior.
Hope this helps. If it does, please mark the response as Helpful and Accept as Solution.
