# Application identity - Link: https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/authentication/application-identity/ - Published: 2026-08-24T01:47:17+00:00 - Author: Don Bowman 1. [Home](https://www.agilicus.com/) 2. [Agilicus AnyX Administrative Web Interface](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/) 3. [Authentication](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/authentication/) 4. Application identity ![6a9b694b-featured-anyx-admin-authenticationapplication-identity](https://www.agilicus. com/www/6a9b694b-featured-anyx-admin-authenticationapplication-identity.png) ## Application identity [CONTACT](https://www.agilicus.com/contact-us/) 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. ![Application identity overview](https://www.agilicus.com/www/c580a585-application- identity-overview.png) ## 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](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/resources/applications/). The page shows a _no permissions_ message otherwise. ## How to use it 1. Open **Authentication > Application Identity** from the left navigation. 2. The table lists your application identity providers. Select **ADD PROVIDER** to add one. ![Add provider, step 1: choose provider](https://www.agilicus.com/www/b9651966-application- identity-add-step1.png) 1. The **Choose Provider** step is pre-set to **Application**. Select **Next**. 1. 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. ![Define the provider](https://www.agilicus.com/www/c200c0a8-application-identity- define-provider.png) ![Select an application](https://www.agilicus.com/www/c628fa06-application-identity- app-select.png) 1. 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. 1. Optionally add the **Expected Cookies** the application sets on a successful login, then set the **Auto-create Status**. ![Define the provider, filled](https://www.agilicus.com/www/c2fa12f6-application- identity-define-filled.png) 1. Select **Next** to review, then **Add** on the **Apply** step to save the provider. ![Apply the provider](https://www.agilicus.com/www/c2fa12f6-application-identity- apply.png) 1. The **Done** step confirms the provider was saved. ![Provider saved](https://www.agilicus.com/www/597dfdab-application-identity-done. png) The new provider appears in the table, with its issuer built from the application and login path. ![Provider in the table](https://www.agilicus.com/www/91f66ed5-application-identity- after-add.png) 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](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/resources/applications/) pages, and sign-in attempts are in the [authentication audit](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/organisation/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](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/resources/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](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/application-permissions/). * **Sign-in attempts fail in the audit**: review the [authentication audit](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/organisation/authentication-audit/) for the failure reason and check the application is reachable. ## See also * [Identity and authentication](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/identity-and-authentication/) * [Authentication overview](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/authentication/overview/) * [Shared identity](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/authentication/shared-identity/) * [Custom identity](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/authentication/custom-identity/) * [Onsite identity](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/authentication/onsite-identity/) * [Applications](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/resources/applications/) * [Getting started: identify users](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/getting-started/identify-users/) ## Web guide * [Identity and authentication methods](https://www.agilicus.com/product-guide/identity-and-authentication) * [Authentication Issuer: Custom Identity](https://www.agilicus.com/product-guide/authentication-issuer)