Applications

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) 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.
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).
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).
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

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.

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.

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

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.

%%{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<br/>name and description"]
    S1 --> S2["2. Access<br/>how users reach the application"]
    S2 --> A1["Onsite connector<br/>select connector, upstream services"]
    S2 --> A2["Public internet<br/>third-party SaaS"]
    S2 --> A3["Point-to-point VPN<br/>upstream services with IP address"]
    S2 --> A4["Agilicus Secure Cloud<br/>container runtime or bundle"]
    A1 --> S3["3. Authentication<br/>how the application authenticates"]
    A2 --> S3
    A3 --> S3
    A4 --> S3
    S3 --> F1["None<br/>public, no authentication"]
    S3 --> F2["Own authentication<br/>SAML or OpenID Connect"]
    S3 --> F3["Proxy authentication<br/>Agilicus AnyX signs the user in"]
    F2 --> U["Authenticate users<br/>roles and rules"]
    F1 --> S4["4. Apply<br/>review summary, apply"]
    F3 --> S4
    U --> S4
    S4 --> S5["5. Done<br/>launch, assign permissions"]

#### Step 1: New application

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

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:

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.

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

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:

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.

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

Review the summary, which restates the name, description, category, access method, upstream services, authentication flow and method, user authorisation, and roles.

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

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

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

Open Resources > Applications > Diagnose. This screen reads the diagnostic logs for applications hosted on the Agilicus platform.

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

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, 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 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.