External Credential Store - Multiple Credential Stores

Fabian Kunzke · ‎01-04-2022

ECS (External Credential Store) plugin - An overview

First, let's introduce the topic of this article. The ECS plugin is - strictly simplified - a plugin extension to the credential management on ServiceNow in regards to discovery, service mapping and ITOM orchestration. Usually, credentials (e.g. access credentials for the discovery of SNMP devices) are stored in the credential table. However, some customers may encounter issues with their security guidelines, when it comes to putting credentials onto a public cloud environment. In most cases this problem arises with discovery or service mapping projects and the main question of:

"Do we really need to put our credentials on the service now cloud?"

Now, before answering this question, please keep in mind, that ServiceNow has been proven to be capable of managing and securing credentials on the platform. This article won't be an analysis of the credential- or security topic itself. So let's focus on the question at hand:

No, this is what the ECS plugin is for.

What is it for?

A small and simplified overview based on the documentation from ServiceNow.

First, we have to understand how the Mid-Servers interact when using credentials (Note: this is an insight from the ITOM side of things and does not resemble the side of "normal" API integrations, which can differ in behaviour). The most important fact you should be aware of is, that the ServiceNow instance never pushes any credential information. The Mid-Server must request credentials from the instance.

In simple steps:

1) The instance pushes a "Todo" (e.g. an SNMP command, probe or pattern execution) into the ECC queue and marks it "Ready"

2) The Mid-Server requests a "Todo" from the ECC queue

3) The Mid-Server starts to execute the "Todo"

4) A credential is needed for the "Todo"

5) The Mid-Server uses the credential API to request a credential from the instance

6) The Mid-Server resolves the credential

7) The Mid-Server executes the "Todo" with the resolved credential

😎 The Mid-Server pushes the result of the "Todo" into the ECC queue

Now here is the key part: No matter where the credential is located, this behaviour is not changed. Instead we extend it and allow the Mid-Server to access any given Credential Store. This can be useful in case of mainly one of these two:

- Security Restrictions
- Ease of integration into the company (e.g. if the Linux team already uses an appropriate credential store)

Up until the latest release however, the ECS plugin was restricted to only support one credential store. This would only solve the first of the use cases (except if your organization only works with Linux teams).

How did it work?

As stated above, the main functionality stays the same. With the installation of the ECS plugin however, credentials are allowed to be flagged as "external credential". When flagged, instead of containing the actual credential, a credential record would only contain a name and the appropriate ID. All that is needed now, is the implementation of a Mid-Server extension, which allows the Mid-Server to access the credential store. This is what is usually related to as a "Credential Resolver". The change on the side of the Mid-Server then results to this:

1) The instance pushes a "Todo" (e.g. an SNMP command, probe or pattern execution) into the ECC queue and marks it "Ready"

2) The Mid-Server requests a "Todo" from the ECC queue

3) The Mid-Server starts to execute the "Todo"

4) A credential is needed for the "Todo"

5) The Mid-Server uses the credential API to request a credential from the instance

6) The Mid-Server resolves the credential

6.1) Credential Resolver is executed (this contains the interface definition for the credential store)

6.2) Credential Store API is triggered (with the ID of the credential)

6.3) Retrieved credential is resolved by the Credential Resolver

7) The Mid-Server executes the "Todo" with the resolved credential

😎 The Mid-Server pushes the result of the "Todo" into the ECC queue

Now with that, one key issue arose: Since there is only one Credential Resolver (which is a .jar file distributed across the Mid-Servers) containing the API definition to the credential store, one may only use one single credential store (or create a beefy Credential Resolver).

What changed?

With Rome, ServiceNow introduced a very slight change to the overall functionality of the plugin. In addition to the credential ID a credential flagged as an external credential can now also reference a record called "Credential Storage Vault". This new record is now where the Credential Resolver .jar files are uploaded to. This means, that you can create a record for "CyberArk" with its respective Credential Resolver as well as another one for "Thycotic". A credential can then either reference the "CyberArk" or "Thycotic" vault. On the Mid-Server this change is then linked to step 6.1:

Instead of being restricted to "the one" Credential Resolver, the referenced .jar file is used. If your credential record on the instance relates to "Thycotic", the Thycotic Credential Resolver .jar will be used. If it references "CyberArk", the respective CyberArk Credential Resolver .jar is used. Everything else stays the same.

Why you should care!

Now, this may seem like a minor change. However, as this functionality is not only used for Discovery and ServiceMapping, but also for the ITOM Orchestration, this is truly a step forward when it comes to adaptability. Sections of an organization are no longer restricted to using one single credential store. With the increase of predefined CredentialResolvers and store based plugins the discussion of using a credential store is opened up to the second main business case: Ease of integration into the company.
You don't have to move to one credential store anymore when using ITOM. This little update gives you one very powerful tool to increase the reach and adaptation of your ServiceNow instance - especially in the ITOM part:

Choice.

You now have a choice. You can present teams with options. You have your own credential store already setup? Great, let's use that one. You use a different one than the Windows colleagues? Great! You don't want to replicate all credentials on the ServiceNow platform? Awesome. Why? Because you don't have to anymore. You now have a choice.

VaranAwesomenow · ‎05-14-2023

@Fabian Kunzke Thanks for sharing this article.

I looking for some help on how to achieve following usecase.

Implement basic authentication to authenticate against a REST API, credentials are stored in external credential store.

Can you offer any insight on how to achieve basic auth setup using external credential store, I tried the steps in this KB article but it didnt help

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0714680

VaranAwesomenow · ‎05-17-2023

I figured it out, It was the properties file having incorrect credential format.

I made a recording of the solution.

https://youtu.be/7E23wu5J6rs

Fabian Kunzke · ‎06-07-2023

@VaranAwesomenow for some reason i cannot reply to you directly…

I was on vacation over the last 4 weeks. Great to see you found a solution! I will take a look at it.

William50 · ‎12-09-2023

@Fabian Kunzke can you please give me some help on my discussion topic CredentialResolver.class - What happens?