# Applications
- Link: https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/resources/applications/
- Published: 2026-08-24T01:47:02+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. [Resources](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/resources/)
4. Applications
## Applications
[CONTACT](https://www.agilicus.com/contact-us/)
The **Applications** pages (routes `/application-overview`, `/application-new`, `/
application-define`, `/application-diagnose`, and `/application-authentication-clients`)
manage web applications exposed through the Agilicus AnyX identity-aware proxy.
Applications are the most common resource type: a web application, an application
programming interface, or anything that uses HTTP as its transport.
## Purpose
An application is a web service you expose to users, reached through the identity-
aware proxy. The Applications pages let you list every application and its status,
walk through a guided wizard to create one, refine its definition across Common,
Hosting, Security, and Proxy tabs, view diagnostic logs, and manage the OAuth and
OpenID Connect clients that back single sign-on. See [Resources (concepts)](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/resources/)
for where applications fit in the platform.
## Why use it
* Expose an internal web application (behind an onsite connector) with no inbound
ports, with authentication and authorisation applied by the platform. See [Zero trust architecture](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/zero-trust-architecture/).
* Publish an internet-facing service and let the platform authenticate users for
it.
* Host an application directly in the Agilicus cloud from a container image or
an uploaded bundle.
* Give users single sign-on into applications and define roles and rules for fine-
grained authorisation.
* Diagnose a misbehaving application by reading its request logs, and manage the
authentication clients used for single sign-on.
## When to use it
* During initial setup, when you first expose a web application (see [Getting started: expose a resource](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/getting-started/expose-resource/)).
* Whenever you add, change, or remove a web application, or change how users authenticate
to it.
* When you need to grant role-based access inside an application (see [Application permissions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/application-permissions/)).
* When an application fails to behave as expected and you need its request-level
diagnostics.
**Prerequisite**: permission to administer applications (an owner or administrator
role). Without it, the pages show a _no permissions_ message.
## How to use it
### Applications overview
1. Open **Resources > Applications > Overview** from the left navigation.
The table lists every application with its owned indicator, assigned indicator,
launch link, name, status, and administrative state. The columns are described in
[Fields and controls reference](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/resources/applications/#fields-and-controls-reference).
1. To open an application’s definition, select **Configure Application** from the
row’s actions menu, or use the row menu’s **Search in Audits** to jump to the audits
filtered to that application, or **Configure Policies** to attach policies.
1. Use the toolbar **DELETE APPLICATIONS** button (after ticking rows) to delete applications.
Enabling and disabling applications is also available from the toolbar. The row’s
_owned_ icon indicates an application owned by your organisation.
### Creating an application with the wizard
1. Open **Resources > Applications > New**. The wizard has five steps: **New application**,**
Access**, **Authentication**, **Apply**, and **Done**. The Access and Authentication
steps contain their own sub-steps that depend on the choices you make.
```wp-block-agilicus-mermaid
%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
flowchart TD
S1["1. New application
name and description"]
S1 --> S2["2. Access
how users reach the application"]
S2 --> A1["Onsite connector
select connector, upstream services"]
S2 --> A2["Public internet
third-party SaaS"]
S2 --> A3["Point-to-point VPN
upstream services with IP address"]
S2 --> A4["Agilicus Secure Cloud
container runtime or bundle"]
A1 --> S3["3. Authentication
how the application authenticates"]
A2 --> S3
A3 --> S3
A4 --> S3
S3 --> F1["None
public, no authentication"]
S3 --> F2["Own authentication
SAML or OpenID Connect"]
S3 --> F3["Proxy authentication
Agilicus AnyX signs the user in"]
F2 --> U["Authenticate users
roles and rules"]
F1 --> S4["4. Apply
review summary, apply"]
F3 --> S4
U --> S4
S4 --> S5["5. Done
launch, assign permissions"]
```
#### Step 1: New application
1. Enter the **application name**. The tooltip explains that this becomes the hostname
in the URL users see. Enter a **description**, which end users see when asking
for permission to use the application. Both are required.
#### Step 2: Access
1. Choose how the application is accessed. The available options depend on your organisation’s
licence and features; in the demo organisation the options are:
* **from my site via an onsite connector (on-prem)** for applications inside your
private network;
* **over the public Internet (e.g. 3rd-party SaaS)** for externally hosted services;
* **from my site via a point-to-point VPN** for applications reachable through
an IPsec VPN.
The cloud hosting option (_from the Agilicus Secure Cloud_) appears when your organisation
can create hosted applications.
For the onsite connector option, the sub-steps are:
1. **Select connector**: choose the connector that fronts the application. If you
have not created one, use **Resources > Connectors > New** first, then return and
select it.
1. **Enter the upstream service(s)**: give the local hostname or IP address and the
local port of the service you are exposing, select the TLS type (_No TLS_, _Service
is accessed via TLS_, or _Service is accessed via TLS and verify_), and the service
type (_application_ for the first service). Select **+ Add more services** to expose
more than one. For a point-to-point VPN option you also enter the IP address.
Optionally, toggle **My application uses custom web application firewall settings**
to show the web application firewall sub-step, where you set a common path prefix,
internal hostname rewriting, cross-origin resource sharing (CORS) for application
programming interfaces, HTTP/2 support, full web application firewall, and manual
fully-qualified domain name (FQDN) aliases (each alias must be a CNAME pointing
to the platform).
For applications hosted in the Agilicus Secure Cloud, the sub-steps instead ask
whether you will use your **own container** or an **Agilicus container**, then the
image runtime, port, and version tag (own container) or the runtime image and an
uploaded bundle (Agilicus container).
#### Step 3: Authentication
1. Choose how the application authenticates:
* **does not require authentication**: the application is public;
* **participates in authentication (integrates with OpenID Connect natively)**:
the application performs its own single sign-on;
* **is authenticated by Agilicus AnyX proxy**: the platform signs users in on behalf
of the application.
For the _proxy_ flow you can optionally set a logout URL, a redirect path after
sign-in, and enable client-side processing (used for password injection and websocket
issues), with an automatic username and password if required. Tick **My application
is also launched from the desktop** if the application launches through a desktop
launcher.
For the _own_ flow, the sub-steps ask:
1. **Authentication method**: choose **SAML** or **OpenID Connect**. For SAML, paste
the SAML service provider metadata (or upload it). For OpenID Connect, enter the
redirect URI.
1. **Authenticate users**: choose who may use the application, from _has no named
users (anyone on public internet)_, _is used by all users in my organisation_,
_has named users with a single role_, _has named users with distinct roles_, or
_is used by all users in my organisation, but some users have distinct roles_.
The options that use roles reveal the **Enter roles** sub-step, where you add role
names (for example _Owner_, _Administrator_, _Editor_), mark a default role, and
add comments.
The **Enter rules** sub-step explains that fine-grained rules are configured later
on the Define screen.
#### Step 4: Apply
1. Review the summary, which restates the name, description, category, access method,
upstream services, authentication flow and method, user authorisation, and roles.
1. Select **DOWNLOAD TEMPLATE** to save the configuration as a reusable template,
then select **APPLY** to create the application. Creation runs asynchronously;
the wizard advances to Done automatically when it succeeds.
#### Step 5: Done
1. The Done step shows the launch instructions, the application’s current status,
and options to add the application to resource groups or policies now.
Select the link to launch the application (it may take two to three minutes to become
available). Use the configuration options to assign permissions and add the application
to resource groups or policies.
### Defining an application
1. Open **Resources > Applications > Define** and select an application, or choose**
Configure Application** from its row on the overview. The Define screen has four
tabs: **Common**, **Hosting**, **Security**, and **Proxy**.
* **Common**: configuration present on all instances and configurations: name,
category, description, contact email, port, publish state, and the end-user logo.
* **Hosting**: for applications running inside the Agilicus platform only. It lists
the application instances (separate running copies, for example Production and
Staging), their status, container image, and bundle configuration. Most applications
that use a connector do not use this tab.
* **Security**: the application roles table (add and delete roles, set a default
role), firewall rules that allow or deny access, and web application security
settings such as content security policy.
* **Proxy**: how the proxy presents the application to clients. It includes HTTP
rewrites (user context headers, common path prefix, recursive replacement, media
type rewriting), rewrite rules, response and request header overrides, and proxied
service configuration for external hosts.
### Diagnosing an application
1. Open **Resources > Applications > Diagnose**. This screen reads the diagnostic
logs for applications hosted on the Agilicus platform.
1. Set the filter: a time frame (with custom start and end dates), sort order (newest
or oldest first), the maximum number of results, the application name (with autocomplete),
and the environment (_Development_ or _Production_). Select **VIEW LOGS** to populate
the table or **DOWNLOAD LOGS** to export them as a file.
The results table shows Timestamp, App, Stream, and Log. Applications that are proxied
through a connector rather than hosted on the platform have no platform logs to
show, so the table stays empty for them.
### Managing authentication clients
1. Open **Resources > Applications > Authentication Clients**. Each card is an OAuth
2.0 or OpenID Connect client used for single sign-on and diagnostics. These are
usually created automatically when an application is created, but you can create
them manually for external applications.
The cards show the client name, the application it belongs to (or _All_), the secret,
allowed organisations, multi-factor and single sign-on behaviour, and counts for
redirects, authentication attributes, and identity provider aliases. Select **more**
on a card to edit or delete the client, **ADD CLIENT** to create one, and **SAML
METADATA** to download the identity provider metadata.
## Fields and controls reference
| Control | Purpose | Required | Default | Valid values | Notes |
| Name | The application’s hostname | Yes | n/a | A valid hostname, no spaces | Becomes part of the URL users see |
| Description | What the application is | Yes | n/a | Any text | Shown to users requesting access |
| Category | Application grouping | No | default | Any text | For example ‘fire’, ‘water’, ‘police’ |
| Access option | How users reach the application | Yes | Onsite connector | On-prem, internet, VPN, cloud | Options vary by licence |
| Connector | The connector fronting the application | Yes (on-prem/VPN) | n/a | A configured connector | |
| Upstream services | Local hostname/IP and port | Yes (on-prem/VPN) | n/a | Hostname or IP plus port | Add more for multiple services |
| TLS type | Whether the service uses TLS | No | No TLS | No TLS, TLS, TLS and verify | TLS and verify checks certificates |
| Authentication flow | How the application authenticates | Yes | Proxy | None, own, proxy | |
| Authentication method | The single sign-on method (own flow) | When own | SAML | SAML, OpenID Connect | |
| Redirect URI | OpenID Connect redirect | When own + OpenID Connect | n/a | A valid URI | |
| Authenticate users | Who may use the application | Yes | n/a | Five options from public to distinct roles | |
| Roles | Intrinsic security groupings | When distinct roles | n/a | Role names, one default | For example Owner, Administrator |
| Published | Whether users may request access | No | Unchecked | Checked or unchecked | On the Define Common tab |
| App status | Running state of the application | Read-only | n/a | Active, Down, and intermediate states | Shown on overview and Done |
| Admin state | Whether the application is enabled | n/a | Active | Active, disabled | Use ENABLE/DISABLE on overview |
## Dialogs and popups
* **Add/Edit authentication client dialog**: opened from **ADD CLIENT** or the **
Edit** action on a client card. It collects the client ID, application, secret,
allowed organisations, multi-factor behaviour (_User preference_ or enforced),
single sign-on behaviour, redirects, authentication attributes (name and field),
and identity provider aliases, with **ADD** and **CANCEL**.
* **Confirmation dialogs**: deleting an application, or deleting an authentication
client, confirms before acting.
* **Resource labels and logo dialogs**: applications appear on the [Resources overview](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/resources/overview/),
where you attach labels and change their icon.
## Configuration versus diagnostics versus confirmation
* **Configuration**: the wizard, the Define tabs (Common, Hosting, Security, Proxy),
authentication clients, roles, firewall rules, and header overrides are persistent
configuration.
* **Diagnostics**: the Diagnose screen reads request and stream logs; the status
column on the overview reflects the current runtime state.
* **Confirmation**: deleting an application is permanent and removes its launch
URL; disabling an application immediately stops user access, so confirm before
applying.
## Pagination and async behaviour
* The Applications overview pages at **25 rows per page**; the paginator shows
the current page and totals. The demo organisation has 3 applications, all on
one page.
* Application creation runs asynchronously. After selecting **APPLY**, wait a few
seconds; the wizard advances to Done automatically. New applications may take
a few seconds to appear on the overview after creation, and the launch URL may
take two to three minutes to serve traffic. After enabling, disabling, or deleting
applications, reload or navigate away and back to confirm.
* The Diagnose screen reloads its results only when you select **VIEW LOGS** again;
changes to the filters do not re-run the query until you apply them.
## Troubleshooting
* **The application will not create**: check the name is a valid hostname, the
description is present, a connector is selected for on-prem access, and the authentication
flow is complete. Validation errors appear on the relevant step.
* **Users cannot reach the application**: check the connector status on the [Connectors](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/resources/connectors/)
overview, confirm the application’s admin state is _active_, and wait for the
launch URL to propagate.
* **The application shows Down**: the underlying service or the connector is unreachable.
Check the upstream host and port, then use **Search in Audits** from the overview
row menu to see recent access attempts.
* **The Diagnose table is empty**: the screen shows logs for applications hosted
on the platform. A proxied application has no platform logs, so an empty table
is expected.
* **A user is asked to authenticate again**: check the application’s authentication
flow and the [authentication policy](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/authentication/authentication-policy/).
## See also
* [Resources (concepts)](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/resources/)
* [Zero trust architecture](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/zero-trust-architecture/)
* [Identity and authentication](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/concepts/identity-and-authentication/)
* [Application permissions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/application-permissions/)
* [Resource permissions](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/resource-permissions/)
* [Policies](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/policies/)
* [Audits](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/audits/)
* [Resource groups](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/access/resource-groups/)
* [Authentication clients (authentication concepts)](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/authentication/application-identity/)
* [Connectors](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/resources/connectors/)
* [Getting started: expose a resource](https://www.agilicus.com/anyx-guide/agilicus-anyx-administrative-web-interface/getting-started/expose-resource/)
## Web guide
* [Hosted applications](https://www.agilicus.com/product-guide/product-guide-hosted-applications)
* [Define Application: Proxy](https://www.agilicus.com/product-guide/proxy)
* [Application request access](https://www.agilicus.com/product-guide/application-request-access)
* [Authentication clients](https://www.agilicus.com/product-guide/authentication-clients)