Application identity

The Application Identity page (route /application-identity) uses an existing web application as an identity provider. If an application on your network already has local users and a sign-in form, you can federate those local identities through the platform so they appear as sign-in options at your issuer URL.

Purpose

Some existing web applications keep their own local user accounts and have no OpenID Connect interface. Application identity lets the identity-aware proxy log in to that application’s sign-in form on the user’s behalf (supplying the username, password, and any expected cookies), so the application’s local identities become usable across the platform. This is how, for example, a wiki or an enterprise resource planning system with local accounts can serve as the identity source for your users.

Each application identity provider appears as a row in the table and is tied to one of your configured applications. The page covers adding a provider (bound to an application), editing its properties, and deleting it.

Why use it

Reuse the user database of an application that does not support a modern identity protocol.
Give users a single sign-on experience even when the underlying application only understands form-based logins.
Expose local identities at your issuer URL during the sign-in process without migrating accounts.

When to use it

When an application has local users and you want those identities usable across the platform.
When you cannot change the application itself (for example a legacy system) but still need to federate its users.
When the application’s login page has a predictable form (field names and a success response code).

Prerequisite: permission to administer issuers (an owner or administrator role), plus at least one configured application. The page shows a no permissions message otherwise.

How to use it

Open Authentication > Application Identity from the left navigation.
The table lists your application identity providers. Select ADD PROVIDER to add one.

The Choose Provider step is pre-set to Application. Select Next.

In Define Provider, enter a Name, select the Application that hosts the sign-in form, and enter the Login Path where the login endpoint lives.

Enter the Username Field and Password Field names exactly as they appear in the login form’s HTML (inspect the login page to find them), and the Successful Response Code the application returns on a successful login.

Optionally add the Expected Cookies the application sets on a successful login, then set the Auto-create Status.

Select Next to review, then Add on the Apply step to save the provider.

The Done step confirms the provider was saved.

The new provider appears in the table, with its issuer built from the application and login path.

To delete providers, tick their checkboxes and select DELETE PROVIDERS.

Fields and controls reference

Table columns

Column	Purpose	Editable	Notes
Name	The provider’s display name on the sign-in page	Yes	Required; up to 100 characters
Issuer	The issuer URI, built from the application and login path	Read-only	For example `https://payroll.dbt.agilicus.cloud/login`
Icon	The icon identifier used on the sign-in page	Yes
Auto Create	Whether users are created automatically on first sign-in	Yes	Default, active, pending, or disabled
Username field	The name of the username field in the login form’s HTML	Yes	Find it by inspecting the login page
Password field	The name of the password field in the login form’s HTML	Yes	Find it by inspecting the login page
Successful response code	The HTTP response code a successful login returns	Yes	A number between 100 and 600
Expected cookies	The cookies the application sets on a successful login	Yes	Chip list
Actions	Row menu	n/a

Buttons

Control	Purpose
ADD PROVIDER	Opens the add-provider wizard
DELETE PROVIDERS	Deletes the ticked providers

Dialogs and popups

Upstream provider setup (Add provider)

The Certificates & Secrets dialog has four steps for an application provider: Choose Provider (pre-set to Application), Define Provider, Apply, and Done. The Define Provider step holds the provider name, the application selection, the login path, the form field names, the successful response code, expected cookies, and the auto-create status.

Configuration versus diagnostics versus confirmation

Configuration: adding, editing, and deleting application identity providers.
Diagnostics: the table is an inventory. The application’s own status is on the Applications pages, and sign-in attempts are in the authentication audit.
Confirmation: DELETE PROVIDERS removes the ticked providers immediately. Users who sign in through the provider will lose that sign-in option.

Pagination and async behaviour

The table pages at 25 rows per page. Use the paginator to move through larger lists.
Changes save asynchronously: after creating or deleting a provider, wait a few seconds and reload to confirm.

Troubleshooting

The application list is empty: configure the application under Applications first, then return to this screen.
Users cannot sign in through the provider: confirm the Username Field and Password Field names exactly match the login form’s HTML, and that the Successful Response Code matches what the application actually returns.
The login succeeds but access is wrong: check that the expected cookies (if any) are listed, and verify the user’s permissions under Application permissions.
Sign-in attempts fail in the audit: review the authentication audit for the failure reason and check the application is reachable.