Authentications
Connection details and credentials live in a separate object that ports reference by name, one Authentication type per Adapter type, application-scoped, encrypted at rest, optionally included when you snapshot the application.
An Authentication in Art2link ESB is the object that holds whatever a port's adapter needs to reach its endpoint, for a SQL Adapter that is the connection string, and every other adapter declares the shapes it accepts. The shape is determined by the Definition picked when the Authentication is created; the storage and lifecycle are the same in every case.
Authentications are deliberately separated from port and adapter configuration so the connection details can be defined once and referenced from every port that needs them. Each port carries the Authentication's name, not its value, editing the port's other properties does not require seeing or re-entering the secret, and rotating the secret in one place updates every port that uses it.
The same separation is what makes Snapshots safe to share, configuration moves between environments as plain JSON, and Authentications travel only when the operator opts in and supplies a password.
The pairing between Adapters and Authentications is one-to-one at the type level. Every Adapter type defines exactly one Authentication shape; an adapter cannot consume an Authentication that belongs to a different adapter type.
Take SQL as the worked example. A SQL Adapter on a port reaches its database through a SQL Authentication built on the SQL Server Connection Definition, whose Database Config holds the connection string. The pattern is the same throughout: pick the adapter and Definition, and the fields the Authentication exposes follow.
Authentications are scoped to an Application, owned by it alongside the other artifacts the Application carries, see the catalogue in the Applications article for the full inventory. From the application menu, the Authentications list shows every Authentication that belongs to that application. Each row has these columns:
| Column | Description |
|---|---|
| Name | How the Authentication is referenced from a port. Names are unique within the application; they are how a port's adapter configuration points back at this object. |
| Definition | The credential shape this Authentication is built on, picked from the catalog the chosen Adapter offers: SQL Server Connection for a SQL Caller, API Listener Token for an API Listener, API Bearer Token or API Basic Authentication for an API Caller. The Definition pins the field shape and dictates which adapters are allowed to reference this Authentication. |
| Application | The application this Authentication belongs to. Authentications never cross application boundaries; this column appears only when no Application is selected, see Selected Application. |
The list view follows the platform's Selected Application behavior, with an Application selected, the list filters to it and the Application column is hidden; with no selection, the list spans every Application you have access to and the column is shown. Creating a new Authentication uses the same flow: with an Application selected, the form opens with that Application preemptively chosen; without one, the form exposes an Application picker.
In the editor, the identity fields (Name, Adapter, Definition, Application) are followed by a Definition-specific config section holding the secret fields themselves; its heading follows the Definition, Partner Config with a Token for an API Listener Token, Database Config with a connection string for a SQL Server Connection, and so on. Ports reference the finished object statically by name; on the send side a port can instead resolve the Authentication name dynamically through a {{ }} binding per message. That choice is made on the port, in the adapter configuration’s Auth Config Type field, not here. Receive ports always reference statically; they cannot use a dynamic binding.
The Definition catalog today, growing as adapters gain shapes. Direction sets who decides: calling out, the remote endpoint dictates the shape you need; listening, you dictate what callers must present. Field-level detail lives in each adapter’s own article.
| Adapter | Definitions |
|---|---|
| API Listener | API Listener Token |
| API Caller | API Bearer Token, API Basic Authentication |
| SQL Caller | SQL Server Connection |
| O365 Mail Sender | Microsoft Graph |
| SFTP Caller | SFTP Password Authentication |
A single Authentication can be referenced by any number of ports inside the application, as long as each of those ports uses an adapter of the matching type. Five ports all reaching the same endpoint share one Authentication; its values live in one place and one place only.
This is the practical reason the object exists. The alternative, embedding the values inside each port's adapter configuration, would mean as many copies of the secret as there are ports, as many places to update when something changes, and as many chances for the copies to drift.
Authentications are always encrypted at rest under a platform-managed key. Their values are written encrypted at save time and decrypted only when an adapter resolves the reference at execution time.
This is the default and there is no opt-out. The only place encryption changes shape is when an Authentication is exported as part of a Snapshot, where a second layer kicks in, see below.
Authentications are one of the two parts of an application's configuration that Snapshots include only on request (the other is Constants values). Taking or exporting a snapshot exposes an Include authentications option:
- Leave it unchecked and the snapshot captures everything except Authentications. Configuration travels as plain JSON; secrets stay behind.
- Check it and every Authentication owned by the application is included, with the snapshot password-encrypted under a passphrase the operator supplies at creation or export time. The same passphrase is required to decrypt the file on import.
The platform-managed encryption that protects an Authentication at rest is replaced for the snapshot by this user-supplied password, that is what makes a snapshot file portable across environments without exposing the platform key. The full take / export / import flow, including what happens when the password is missing or forgotten, is documented in the Snapshots article.
That is the whole shape
Pick an adapter type, define a name, fill in the fields the adapter requires, save. Reference the Authentication by name from every port that needs the same connection. Encrypted at rest by default, included in a snapshot only when you ask, and password-protected when you do.