Adapter authentication overview

The primary purpose of an adapter is to communicate with an external system, perform actions, and return results to Itential Automation Platform (IAP). To do that, the adapter must be able to authenticate with the external system.

Authentication methods vary across systems and can change over time — for example, a system may move a token to a different header. There is no single standard approach.

Before you configure authentication

Before configuring an adapter to communicate with an external system, determine the following:

Username and password

• Is a username and password required? If so, is it needed on every call, or only to retrieve a token?
• Are you authenticating with system credentials or user credentials?
• Do you need to log in dynamically with different user credentials?
• Does the system or user account have the permissions needed for the actions you intend to take?
• How often do these credentials change, and what impact does a credential change have on the adapter?

Token-based authentication

• Can you use a static token with a long or indefinite lifespan?
• How many steps are required to acquire a token?
• If the token expires, how long is it valid?
• What does the token request require — specific headers, a body, or other data?
• Do you need to authenticate dynamically against different environments or domains based on some criteria?

Test authentication before configuring the adapter

Test authentication using an API tool such as Postman before configuring the adapter. This gives you concrete information about what the external system expects, which you can then compare against the adapter’s debug-level logs with auth logging enabled. That comparison helps you identify what changes are needed in theItential Platform service instance configuration or the adapter’s endpoint configuration.

Authentication methods