Identity & access
Two questions decide most access reviews: who can get in, and what can they touch once they are in. Art2link ESB answers the first with your own directory and the second with four roles, one scoped to the whole deployment and three scoped per Application.
How operators reach the portal depends on the edition:
| Edition | Sign-in | What that gives you |
|---|---|---|
| Starter | A single built-in account, local login and password | The simplest possible setup, one account, no directory. The person who installs and licenses the instance sets the password at deployment, and can reset it or recover it later. The password is stored hashed on the instance. |
| Grow & Enterprise | Microsoft Entra ID, against your tenant’s directory | MFA, conditional access, device policies, guest / B2B access, and joiner-leaver lifecycle are inherited from the policies you already run. Disable the person in Entra ID and their Art2link access is gone with it. |
On Grow and Enterprise the deployment is bound to your directory at install time with your Entra tenant ID, and the person who runs the install becomes the first System Administrator. From there, users are added by email address, searchable and selectable inside the tool, and each is given a role per Application or made a System Administrator for the whole deployment.
Because Grow and Enterprise federate to your directory, there is no separate Art2link credential to phish, rotate, or forget, and sign-in events appear in your Entra ID logs alongside every other application you govern, as well as in the platform’s own audit stream. Editions do not migrate in place: moving up from Starter is a fresh install, so the Starter local account is not carried into Entra.
Grow and Enterprise editions carry four roles: one that spans the whole deployment, and three scoped to a single Application, the same unit that owns ports, maps, schemas, and the rest of an integration’s artifacts. The three Application roles are additive, Reader is the smallest and Owner the largest, and a user gets one of them per Application.
| Role | Scope | Can |
|---|---|---|
| System Administrator | The whole deployment | Every Application, plus system settings, user and role assignment, Application creation, platform configuration, and environment-scope snapshots. If a user has this role, all per-Application roles are ignored. Only a System Administrator can grant it. |
| Application Owner | One Application | Full control of the Application: every artifact, deleting the Application, snapshots (create, restore, delete), and assigning Owner, Contributor, or Reader on it. Cannot create Applications or grant System Administrator. The last Owner of an Application cannot be removed. |
| Application Contributor | One Application | Everything an Owner can, except: cannot delete the Application, and can create snapshots but cannot restore or delete them. |
| Application Reader | One Application | View configurations and Tracking, including message payloads. Cannot see Authentications or Constants. |
On Starter, the single built-in account is effectively the System Administrator; role separation begins at Grow.
Access control says who may act; the audit stream records who did. Every sign-in, every port create / change / delete, every credential rotation, every role assignment, every snapshot restore is written to the append-only, hash-chained audit stream, including denied attempts, so a Reader probing a port they cannot edit is distinguishable from a benign mis-click. The full treatment, retention, immutability, exports, and framework mappings, is in Logs.