Provider and Protocol

Provider

The Provider options are: Local, AWS.

Local

If the application is hosted onsite - for example, at the corporate premises - select this option.

AWS

If the application is hosted in the cloud on Amazon Web Services (AWS), there is an option to manage assets based on labels. select this option. If AWS is selected, the protocols available for configuration are: RDP, VNC, SSH, and TELNET.

Protocols per Application Type

Each application type is associated with a protocol and its default port. See linked articles for configuration details:

Web Applications — HTTP, HTTPS, SaaS, Link
Networks — TCP, SSH Tunnel, Network
Servers — RDP, SSH, VNC, TELNET
Databases — PSQL
Files — SMB

Application Parameters - Overview

Note that the set of Application Parameters vary by application type.
See parameter descriptions below.

Visible

Enabled by default. When enabled, the application is displayed in the end-user Applications Portal.
If disabled, the application remains published and accessible but is hidden from the portal.

Use case: An example of the use of the Visible parameter would be when an application redirects traffic to a different URL, the redirected traffic must also pass through the Cyolo tunnel. Example:

Published app points to www.cnn.com.
After launch, traffic redirects to edition.cnn.com, which is not secured.
To secure this, publish a second application for edition.cnn.com with Visible disabled. Both URLs are then routed securely through Cyolo.

Internal Address/URL

Enter the internal IP address or URL of the server hosting the application. This must be accessible from the IDAC.

Site

Sites represent logical segments of the organization. Each site has at least one IDAC that publishes resources.

When creating a site, configure a DNS suffix (e.g., example.com) and/or a network address in CIDR notation.
The site is auto-selected based on the Internal Address/URL.
By default, All sites is selected. You may:
- Select a specific site to publish only from its IDAC.
- Select All sites to publish across all current and future IDACs.

Recommendation: Assign multiple sites for high availability. If a new IDAC is added to a site already hosting this application, that IDAC will also publish it.

Subdomain

Enter a subdomain (prefix) to form the public URL that users connect to.

Example:

Subdomain: web
Domain: domain.cyolo.io
Resulting URL: web.domain.cyolo.io

Domain

Domains defined under Applications > Domains appear here.

Typically a single domain is used, but multiple domains may be configured.
The first domain is displayed by default. Use the dropdown to select another domain if required.

Domains added under Applications > Domains page are listed here. Generally, only a single domain is configured on the portal; however, multiple domains can be added as per network requirement. By default, the first domain is displayed in this field. Click the drop-down to select the domain of your choice.

Icon

Upload an image file to be displayed as the icon for the application on the Application Portal.

To know more about options particular to each application, refer to the sections linked above.

Authentication Method - Sign-in Settings

Authentication method here refers to the authentication parameters set within the application. To sign in to applications, users must either enter the credentials or the sign-in must be done on their behalf. This section allows the portal admin to configure the authentication method before accessing a resource from the Applications Portal.

The options are detailed below.

None

Selecting this option means the user will be prompted for authentication before signing in to the application. If the application or resource requires authentication, it must be entered manually. This option is available on all applications.

Basic

Use Basic authentication for username and password credentials. This method is available for HTTP, HTTPS, RDP, SSH, VNC, TELNET, PSQL, and SMB applications selected in the Protocols section. Choose from these credential options:

Personal Secret

Use the user’s own logon credentials, or define a different secret name to prompt the user and store it in their personal vault.

Select an existing name to share the same secret across multiple applications.
Or create a new name to generate a dedicated secret specific to this application.

Shared Secret

Use a vault-stored secret that applies to all users. The secret is automatically injected when users access the application, so no credential prompt is shown.

Windows

The credentials used to log in to the Applications Portal are used to access the application - using the Kerberos flow.

Forms

This option is for web applications working with web forms. Forms-based SSO depends on the specific SSO implementation for each web application. Cyolo provides options for different SSO designs, including one-time tokens and CSRF tokens, inserting authentication parameters as headers, and using different pre-login and login URLs. Forms-based authentication is available when web applications (HTTP/HTTPS), are selected under the Protocols section.

SamlSP

SAML SP SSO solution adds an added layer of protection. It acts as a proxy that monitors users' activities within a service provider. SamlSP-based authentication is available when web applications (HTTP/HTTPS), are selected under the Protocols section.

Private Key

Private key is used when the credentials are a private key and, optionally, a username. Private key authentication is available when SSH is selected under the Protocols section. These are the options available for private key authentication:

User logon credentials - The credentials used to log in to the Applications Portal are used to access the application. The user will not be prompted for a username and password.
Prompt user and store in personal vault - The user will be prompted for a username and private key when connecting for the first time. The credentials will be stored in the user's personal vault and automatically used for every subsequent sign-in attempt, so the user will not be prompted for credentials thereafter.
Assign secret from vault - The portal admin stores the application's username and private key in the system vault. When users connect to the application, they are not prompted for credentials; instead, the stored credentials are used in the background to sign in the user.