f4181a45 featured anyx admin conceptsend user

End-user experience

CONTACT

The portal is the administrator’s view of Agilicus AnyX. This page explains the other side: what users experience when they connect. Understanding this helps you configure resources correctly and answer support questions.

Signing in

Users sign in at a URL served from your domain (through your CNAME). They see your organisation’s sign-in page, themed to match your brand (see Sign-in theming). They authenticate with their existing identity provider, and complete multi-factor authentication if your authentication policy requires it.

There is nothing to install for browser-based access: a user just opens the URL and signs in.

Browser access

For web applications and file shares, users work in the browser:

  • applications open in the browser through the identity-aware proxy (see Applications);
  • shares are exposed over HTTPS and WebDAV, so users can browse files in the browser or mount them in a file manager (see Shares); and
  • templates can be requested or downloaded (see Templates).

The launcher

For resources that do not fit in a browser, users install the Agilicus launcher on their desktop. The launcher gives access to:

  • SSH services (see SSH);
  • databases (see Databases);
  • desktops through a remote desktop client (see Desktops); and
  • other TCP-based resources.

The launcher signs the user in once, and then each resource is one click away. Installation instructions and troubleshooting are in the web guide’s Launcher (desktop) and Launchers pages.

Requesting access

If the request flow is enabled, a user who does not yet have access can request it from the portal. The request is sent to administrators for approval. Until approved, the user cannot access the resource.

What users never see

With zero trust access:

  • users never need a VPN;
  • users never connect to a public IP of your resources;
  • users never see your internal network topology beyond what you deliberately expose; and
  • when a user leaves the organisation, their identity is removed and their access stops.

Troubleshooting from the user’s side

If a user reports a problem, the usual questions are:

  1. Can they sign in? (Check the authentication audit.)
  2. Are they allowed? (Check permissions and policies.)
  3. Is the resource reachable? (Check connector diagnostics.)
  4. What did the request look like? (Use application diagnose.)

See also

Web guide