Billing is managed directly in the Agilicus Platform and you can setup automatic payments from the Billing Tab. Payments are managed and processed through Stripe, no financial information is stored within the Agilicus platform.
Billing is managed directly in the Agilicus Platform and you can setup automatic payments from the Billing Tab. Payments are managed and processed through Stripe, no financial information is stored within the Agilicus platform.
Your billing cycle will be 30 days in duration, and will be a function of when you first started using the platform. You may control automatic payment versus invoicing, and the email-address the invoice would go to. Here you may also see previous invoices.
Within the ‘View/Update Payment Information’ screen (hosted by Stripe) you can see current payment method, add a payment method, and view existing invoices.
Overall usage metrics (which drive the billing) are shown in the table at the bottom. These are instantaneous values, the invoice is based on the peak within the 30-day time interval.
Stripe is a 3rd-party payment processor. You can learn more about Stripe by visiting their website.
Auto-Create Users From Specific Domain With Google Workplace
The Agilicus Managed Upstream Providers option of ‘Google’ allows users to sign in with GMail and Google Workplace (G Suite) with zero-configuration. In some circumstances (for example, to enable the use of auto-create locked to a specific domain) you may wish to create your own Google Identity Provider setup.
Auto-Create Users From Specific Domain With Google Workplace
The Agilicus Managed Upstream Providers option of ‘Google’ allows users to sign in with GMail and Google Workplace (G Suite) with zero-configuration. In some circumstances (for example, to enable the use of auto-create locked to a specific domain) you may wish to create your own Google Identity Provider setup.
To do so, we will use the Google Console, create a Credential, OAUth2, Web application, and from there obtain a client-id and client-secret.
We will then configure the list of acceptable domains which may use it, and cross-configure this information into the Agilicus admin portal.
There is no general requirement to create your own Credentials in Google: do so if you wish finer-grained control by e.g. restricting source domain, or if you have specific audit requirements.
Create a new OAUTH2 client of type Web Application.
Give this “credential” a name. Add a redirect URI of https://auth.ca-1.agilicus.ca/callback
At this stage you will be given two facts (client ID, client secret). You will now enter these into the Agilicus Admin portal.
In the Agilicus Admin portal, add a new Identity Provider of type ‘Other’ (this is a generic OpenID Connect Identity Provider).
Enter a name (your users’ will see this, so e.g. “Agilicus Google Workplace”), the Issuer url (https://accounts.google.com), the Client ID (from above) and the Secret (from above).
You may wish to enable auto-create on this Identity Provider, in which case authenticated users will be automatically provisioned.
At this stage, you may wish to enable “Authorized Domains” in your Google Workplace settings.
Users may now sign in to the system via this Identity Provider.
Authentication is how a user “proves” their Identity
Authorisation is “what” a user is allowed to do. In the AnyX platform this is implemented via a set of firewall rules. For web applications, these have many options (method, path, body, who, etc).
The firewall rules are access via “Resources/Applications/Overview”, and then selecting the individual application, and navigating to the “Security” tab.
HTTP Rules
For web applications, HTTP rules allow matching on a set of conditions, and then performing a set of actions.
The conditions include:
Priority. Rules are evaluated in order until a match occurs
HTTP Path (the part after the host name in e.g. https://hostname/path).
Method (e.g. GET, PUT, POST, DELETE, HEAD, …)
Scope. One of “Assigned to User”, “Anyone”, “Any Known User”, “Any App User” (see Scopes below)
Methods are as defined in the HTTP standard (GET, PUT, POST, …). For most applications GET/HEAD will mean ‘read’, PUT will mean ‘create’, POST will mean ‘update’, and DELETE will mean remove a record.
Actions are Allow, Deny (and None, which can be used to disable a rule temporarily, or for debugging with logging).
Application Roles are defined per application, but often include ‘Self’ (my own records), ‘Owner’ (all, admin), ‘Editor’ (can change but not create/delete), ‘Viewer’ (can read).
Negated (the rule is inverted in sense, so whatever does *NOT* match).
Scopes
The scopes control what ‘type’ of user is matched by this rule. The scopes are:
Assigned to User. The user must have a valid role within this application, and, that role is assigned (see Access/Application Permissions in admin)
Anyone. Literally anyone on the Internet, regardless of who they are (e.g. Anonymous)
Any Known User. Any user who exists in your org as a valid user.
Any App User. Any user who was authenticated by this application (see Authentication/Application Identity. Note this is a rare case).
GeoIP Firewall
In some cases you may want to include only, or exclude only, specific countries from using a resource. You may do this by selecting the ISO 3166 country code for each locale, and then selecting IN/NOT_IN and action. The most common action (ALLOW, DENY) would fall-through to the other authorisation rules (ALLOW), or block entirely (DENY) regardless of user.
The Identity-Aware Web Application Firewall acts as an HTTP-proxy. In doing to, it can inject an identity-flow (authentication on behalf of) as well as rewrite/rework various HTTP constructs to make them accurate relative to an external environment.
The Identity-Aware Web Application Firewall acts as an HTTP-proxy. In doing to, it can inject an identity-flow (authentication on behalf of) as well as rewrite/rework various HTTP constructs to make them accurate relative to an external environment.
Typically there is no configuration required in this section, however, you may use it to tweak for individual applications as needed.
Include User Context Headers
If the ‘Include User Context Headers’ is set, several headers are added to the request, allowing the upstream web server to infer user and role. these include:
It is common for certain body documents to have embedded components linking to the internal name of the host. This could include a JSON search result, showing http://internal instead of https://external.example.com, it could include XML, HTML, CSV, etc.
In this section, we can add specific Media (MIME) types. If they are set, the contents will be rewritten to match the external coordinates.
HTTP (Host) Names Rewrite
The internal host may have multiple names. This can occur with e.g. virtual machines (‘intranet’ is also ‘vweb01’) and these names internally might be used interchangeably. In this section we add a set of hosts that, if present, will be rewritten to the external name.
HTTP Response Header Overrides
Set Header
This allows setting an arbitrary header to an arbitrary value.
Append Header
This allows appending a value to an existing response header.
Remove Header
This will remove a header from the response. It may be used to e.g. remove private internal information or version leakage.
Remove Match
This feature allows removing entire header lines matching some criteria. If your response included:
Host: foobar
Host: foo
Then, if we put in ‘Name’: ‘Host’ and value ‘foo’, both lines are removed. If we put in value ‘bar’ only the first line is removed. A regex is allowed here, so we could put in e.g. ‘fo.*’.
Parameter Rewrite Filter
This feature allows overwriting specific GET parameters. E.g. if the URL is https://www?foo=bar, you can rewrite this to foo=baz. It also allows deflate (e.g. decompress) and base64-encoded.
HTTP Request Header Overrides
The Request Overrides operate in the same fashion as the Response Overrides.
Proxied Service Configuration
This field should not be used in normal circumstances. It allows proxying to an external host (e.g. for demonstration purposes).
Authentication: users presenting credentials to obtain an access token
Authorisation: individual transactions with an access token that are checked for allow/deny
Access logs: individual transaction detail information
API access: changes to the state of the system via API
By default, all records except for those generated by an Agilicus Connector are stored inside the Agilicus cloud. In addition, you may send logs to a webhook (or, in the case of the Connector, a file).
You may enable records from the Connector to come back to the Agilicus Cloud by enabling ‘Access’ and ‘Authorisation’ check marks in the Audit Destinations screen.
For each webhook destination, optional authentication information may be passed.
The intent of the audit destinations to a webhook is to allow the use of an external SIEM or log collector. Messages are sent in JSON format, an example is shown below:
During the new organisation Signup flow you may find an error as below. This is caused by a corporate network filter (e.g. Palo Alto) which blocks certain encrypted flows.
During the new organisation Signup flow you may find an error as below. This is caused by a corporate network filter (e.g. Palo Alto) which blocks certain encrypted flows.
You may have firewalls in two locations: between your browser and the Internet (e.g. if you run endpoint protection software, or are using a device not currently on your corporate network), and, between the Agilicus Connector and the Internet.
Firewall Configuration: End-User Browser to Internet
In order to use your browser with the Agilicus AnyX platform, whether for signup purposes, or for ongoing usage, you need to be able to navigate to these host names:
*.YOURDOMAIN (each of yoru resources will appear hre)
(where YOURDOMAIN is the domain name you will choose during the signup process).. You will know you need these rules if you see errors like below image.
In addition, your name server (DNS) must be able to resolve:
ca-1.agilicus.ca
api.agilicus.com
www.agilicus.com
The most common problem observed is that if you navigate to https://auth.agilicus.cloud you get an error implying the connection was RESET. This is typically done by a content-filtering firewall such as Palo Alto blocking “auth.*” as a domain name.
To resolve, work with your outbound firewall filtering vendor to allow:
*.agilicus.com
*.agilicus.ca
*.agilicus.cloud
Firewall configuraton: Agilicus Connector to Internet
The Agilicus Connector makes outbound connections only, on port 443 HTTPS only. It will have 2 outbound TCP connections (for resilience) as well as periodic ones to its API and update server.
Configure your outbound firewall to allow:
www.agilicus.com (upgrades)
api.agilicus.com (configuration)
agent-server.ca-1.agilicus.ca
*.YOURDOMAIN (authentication via auth.YOURDOMAIN)
If you prefer to use IP (and port) – based rules, you may use as below. Note: it is possible this list will change in the future.
The VNC Desktop feature allows browser-based use of remote graphical-oriented resources. This can include traditional operating systems like Windows, Linux, MacOS, but, also, includes embedded devices such as HMI.
VNC has very weak intrinsic security (a read-only password, a read-write password, but no username). These passwords are in turn very weakly encrypted (3DES), and, must be 8 characters. As a consequence, it is not safe to use by itself with e.g. port-forwarding.
Agilicus AnyX adds a Zero Trust layer, with strong identity and modern encryption, making these safe to use remotely.
Setup
Assuming you have the VNC Server already running and available, you can create and access a VNC Desktop by:
In the Agilicus Admin interace, ‘Resources/Desktops/New’, select ‘a new VNC remote desktop
Select the connector which is adjacent to the VNC Server
Give this VNC Desktop a name. You will use this in the Profile to select the machine
Select the address (as the connector would see) it of the VNC server. E.g. on the machine running the connector, you should be able to ‘ping’ this hostname. NOTE: if the connector is on the same machine as the VNC server, you may need to ‘enable loopback connections’ in the VNC Server configuration.
Optional. If you wish to have the Profile VNC Web interface auto-sign-in (after you have presented your single-sign-on-credentials) you may enter the read-write (and/or read-only) password of the VNC server. If these are set, users may be forced into a read-only role by permissions later.
Assign permissions to who may use this desktop. If ‘viewer’ is selected, and the read-only password was given above, the user will be auto-signed-in as a read-only user.
At this stage, you can open https://profile.MYDOMAIN and you should see this VNC resource on Desktops.
In some circumstances, a local, on-premise identity provider is the best source available. The Agilicus Connector facilities, providing a bridge between a local machine acting as an authentication proxy, and a proper OpenID Connect web public interface. The user credentials are encrypted end-to-end, from the user’s browser to the backend.
Care must be taken when using Onsite Identity. If the connector facilitating is removed, any user with this as a sole identity source will be unable to sign in.
Once installed, you can remotely connect to the Moxa UC-8200, or, resources on adjacent networks through the Agilicus AnyX platform, regardless of network configuration or firewall settings.
From the Agilicus Admin web interface, select Resources/Connectors/New. Give the connector a name, and then select the “Linux” tab, paste the resulting command line into a root shell and it will automatically setup and configure.
Each application will be provisioned with a URL of https://<appname>.<domainname>, and, be available to any user from any browser. A valid certificate will be automatically created (and rotated approximately every 50 days).
Application can have various methods of authentication (sign-in):
To create a new application, select Resources/Applications/New. This will start a guided setup (a ‘stepper’).
In this first step, you will provide two items:
application name. This must be a valid hostname (a-z, 0-9 and -). Please use all lower-case. Underscores and spaces are not allowed. This will become the URL (https://appname.domain).
A general description. This is free form, it will show to the end users.
Throughout the steps you will normally see a ‘Next’ or an item in light-grey to open for the next configuration.
None. Open to anyone on the public Internet. This can be suitable for cases where the application has its own internal user management which is sufficiently strong.
Participating. The web application has built in support for OpenID Connect (or SAML), and, initiates the sign-in flow. This is suitable for cases where the application needs valid users that are distinct.
By proxy. The Agilicus AnyX platform becomes an Identity-Aware-Proxy, forcing users to sign-in prior to any access. In this model, no traffic arrives at the web application unless the user is authenticated and has permission. This is a very strong security model.
New Application (Create/Setup)
Step 1: Name
Step 2: Hostname (or Alias)
In this step we decide how to reach this application. In some cases there is a specific, well-defined, already setup name (which DNS points to this cluster).
Most users will select the first option, in which case there is no additional config.
If you wish to have a manual hostname, set your DNS server up and point it to the same location as the CNAME you did during the initial system setup.
Step 3: Data Plane Network Access
“My application is accessed…”. This governs the data path of how the users reach the application. Most users will select ‘from my site via an onsite connector’, meaning there application is in some private network.
In some cases, when the application participates with the authentication, you may wish to entirely manage the data network and certificates manually, select ‘over the public Internet’.
There is now an ‘advanced configuration’ option, “My application uses custom web application firewall settings”. In most cases this is not needed. These options are described below.
Step 4: Upstream (internal host) Data Plane Network Access
In this step, we configure the internal (in your network) coordinates of the web application. We refer to these as ‘upstream services’.
“Local hostname/ip”. From the machine running the connector, what would you enter in a browser to reach the internal web site? This could be ‘localhost’ if the connector were running on the web server.
“Local port”. What port is your web server running on? (typically 80 or 443, could be 8080, 8088).
“TLS Type”. Is your internal web server setup with SSL/TLS? If so, you might select ‘accessed via TLS”. If it is, and, the certificate is publicly trusted (e.g. issued via Let’s Encrypt or another public certificate provider), select ‘via TLS and verify”.
In rare cases, an application has multiple components on multiple ports, select ‘add more services’
Step 5: Authentication
Applications fall into three classes:
No authentication (rare), no user checking is done
Participates. Application supports OpenID Connect or SAML and is configured to work with Agilicus AnyX specifically.
Authenticated by Proxy. This is the typical case.
For “Authenticated by Proxy”, we can optionally set a ‘redirect after signin’, this is used to give the user an initial subpath (e.g. /Profile).
For the proxy authentication, we now have a initial preset (we can configure later in Define or Access), of how users will use this.
No named users. (any valid random user)
All users in my org. The ‘All-users’ group is given permission.
Named users, single role (this is the most common). A group is created which has access.
Named users, distinct roles. In this mode, there are distinct classes of user (e.g. Editor, Viewer, Manager).
At this stage, you can ‘Apply’. The application will start to configure, this takes 30-45 seconds. You may now need to assign permissions (see Access/Application Permissions). Otherwise, open Profile (see left menu, bottom), hit refresh, and you will see a link to the URL.
(Optional) Custom Web Application Firewall Settings
In some cases manual overrides are needed to parts of the web application firewall. These may be performed during the setup, or, later, tuned with the Define step. The options listed are:
“common path prefix”. If your application is internally served on a shared web server with other web apps, (e.g. intranet/HR, intranet/Wiki), then you may wish to use the prefix option, rehoming it to root. (e.g. /HR here will mean the user will see http://HR/, and automatically sign in).
“Is an API”. If the HTTP endpoint is normally used via external web applications, this will setup CORS automatically. You may also fine tune this in the Define.
“Does not support http/2”. Some applications break when presented with HTTP/2, which is otherwise supported by the Agilicus AnyX proxy. Setting this option will prevent advertising HTTP/2 support.
“Requires full web application firewall”. This is rarely used, we recommend discussing with Agilicus first. This causes a 2-hop encryption path to be used, with an intervening filter.
Application hosted on subpath of domain (e.g. https://host/path)
You may have an application hosted under a subfolder/path on your web server, possibly because it is better than having another server for it. For example: localhost:port/subpath, localhost:port/support etc.
To enable the subpath hosting for your application,
1. Go to Resources > Applications > Define and select the application from the drop down at the top of the page 2. Then in Security (tab) > Firewall Rules > HTTP Rules, change the / entry under path to your custom subpath (For example, /subpath) 3. Under Proxy (tab) > HTTP Rewrites, inside the Common Path Prefix field, enter your custom subpath again (For example, /subpath)
Users, Resources may have an arbitrary set of text-based labels.
These labels can be used for a variety of purposes, including showing alternate hierarchy in Profile, viewing filters in alarms, setting downtime, etc.
Labels may be used to create arbitrary grouping of resources in Profile. For example, you can create ‘admin’, ‘site-1’, ‘printers’, etc. And then assign ‘site-1’ and ‘printers’ to a printer in site-1. Thus this printer would be in both label-folders ‘site-1’ and ‘printers’, allowing arbitrary tagged grouping.
To assign a label, add it in the Resources/Overview screen. Labels may be arbitrary in name.
An additional column ‘Published’ may be used to hide the resource from the label folder in Profile. This may be used if the label is solely for a policy usage.
In the example image above (‘folders’ is applied to 3 Shares), we can see in profile a new icon, ‘folders’. Inside this folder are 2 items (since we did not select ‘Publish’ for cube-tmp).
Labels to Match Policies
Labels, in addition to driving navigation structures, can be used to attach policies such as Multi-Factor Authorisation (distinct of Multi-Factor Authentication). This can allow grouping a set of like resources and attaching policies to them.
Applications generate a valid certificate. You can export this certificate for integration with other systems whenever it is issued or rotated. For example, VTScada requires a valid certificate for the server to be enabled with SSL.
Requirements
The connector associated with the application invokes a script when it learns about a new certificate. – The script must be accessible by the connector (e.g. on the same machine) – The script must be executable by the connector – You are responsible for ensuring the execution environment for the script
For example, for the connector to execute a Python script, Python must be installed on the machine, and the machine must be configured to associate .py files with the Python interpreter. You are also responsible for installing any supporting packages used by your script.
Once Python is installed, the connector will look for a script in the directory: C:\Program Files\agilicus\agent\plugins\certificate-exporter.py
If there is no script found, no export will occur.
Windows Example Script
An example script is shown below, which will import the script as a .p12 file and store it into the Local Machine certificates storage.
import sys
import json
import base64
import tempfile
import subprocess
import os
# load the certificate export json from stdin
# see https://agilicus.com/www/api/certificate-export.schema.json
cert_obj = json.loads(sys.stdin.readline())
def import_certificate(obj):
# create a temporary file. It must be closed
# after write before calling certutil.
tmp = tempfile.NamedTemporaryFile(delete=False)
try:
# retrieve the pkcs12 and base64 decode it
pkcs12 = base64.b64decode(obj.get("pkcs12_b64"))
# write the pkcs12 to the temporary file
tmp.write(pkcs12)
# close the file
tmp.close()
# now import the pkcs12 file into the local machine account
subprocess.run(
["certutil",
"-f",
"-p",
obj.get("pkcs12_password"),
"-importpfx",
tmp.name,
]
)
except Exception as exc:
print(exc)
raise exc
finally:
# after completion, delete the pkcs12 file
os.unlink(tmp.name)
import_certificate(cert_obj)
Programming Interface Details
The json document includes the PKCS #12-encoded certificate bundle and private key, as well as the pem-encoded certificate and private key, and various pieces of supporting data. To view the full details, consult the json definition for the json schema.
The Cisco IOx family provides an excellent platform to run the Agilicus Connector. In this example we are working with the Cisco IR1101, suitable for rugged, embedded environments.
The instructions below were tested on
Cisco IR1101-K9 17.11.1a
Cisco IOx Zero Trust: Cisco Router Setup
Follow the Cisco instructions on enabling IOx, enabling applications and routing. Some sample config is shown here, but this varies by platform. Key items required:
Clock sync (ntp, GPS)
Ability to reach https://www.agilicus.com/
Ability to reach https://api.agilicus.com/
Below we have achieved this with NAT but you can also use a bridge.
interface VirtualPortGroup0
ip address 192.168.100.1 255.255.255.0
ip nat inside
interface Vlan1
ip address 192.168.2.2 255.255.255.0
ip nat outside
ntp server 0.pool.ntp.org
ip dhcp pool vg0
network 192.168.100.0 255.255.255.0
default-router 192.168.100.1
dns-server 1.1.1.1
interface VirtualPortGroup0
ip address 192.168.100.1 255.255.255.0
ip nat inside
interface Vlan1
ip address 192.168.2.2 255.255.255.0
ip nat outside
ntp server 0.pool.ntp.org
ip dhcp pool vg0
network 192.168.100.0 255.255.255.0
default-router 192.168.100.1
dns-server 1.1.1.1
ip name-server 1.1.1.1
iox
ip default-gateway 192.168.2.1
ip access-list standard IOX_NAT
10 permit 192.168.100.0 0.0.0.255
ip nat inside source list IOX_NAT interface Vlan1 overload
ip route 0.0.0.0 0.0.0.0 192.168.2.1
Cisco IOx Zero Trust: Install
On this platorm we will use a container-based install. This platform does not support standard container registries, so we will install the layers manually.
First, download to your local computer the appropriate file for your platform (amd64 or arm64). The IR1101 in our example is arm64.
Second, navigate to the IOx web admin, Configuration/Services/IOx.
From here we will:
Create Application
Upload image (from above)
Set Profile (ram/disk/cpu)
Set networking
Set environment variables (from Agilicus Admin)
Set configuration volume
Activate application
Start application
at which point the Agilicus connector will be running
Cisco IOx Zero Trust: Detailed Steps
Start Application
Select the Agilicus Connnector and start it.
(Optional) Diagnose Application
You can examine the output logs, if needed, via ‘Manage’ and then ‘Log’ and ‘Download’
(Optional) Diagnose Application Log
You can examine the output logs, if needed, via ‘Manage’ and then ‘Log’ and ‘Download’
Check Connector Status
Within approximately 90 seconds you should see the Connector come online in the Agilicus admin UI.
Add New Application
In the Cisco IOx web admin, select ‘Add New’ application.
Upload Image
Download to your local computer the appropriate file for your platform (amd64 or arm64). The IR1101 in our example is arm64.
Upload this image to the IOx device.
Name the Application ‘agilicus’.
Activate
Select ‘Activate’
Copy Setup Configuration
In the Agilicus Admin UI, create a connector. Install. use the ‘Docker’ instructions.
NOTE: the code times out after 10 minutes. If you copy this, and do not start the container within this time, you can generate a new one by closing and re-open the install dialog.
Configure Application
You may optionally configure the resource limits. The Agilicus Connector will typically consume < 256MiB memory, ~150MiB storage, and < 25% of 1 CPU.
Configure the network to match your overall setup (bridge vs NAT).
Uncheck ‘auto delete’, paste the command line from the previous step., Select Activate.
At this stage you have successfully configured the Agilicus Connector on your Cisco IOx device. You may now configure individual services via the Agilicus admin interface.
Sample things to consider would be SSH to the IOx device, the Web Admin of the IOx device, as well as other onwards resources.
In our example router, the SSH management interface is 192.168.2.2. I added a SSH resource, named irr1101-ssh, with that as the IP. I was then able to sign in via Agilicus Profile and see the Router CLI.
The Agilicus Connector is available as a multi-arch snap (X86_64 and AARCH64/ARM64). It is not currently published to Snapcraft, so it must be side-loaded.
Set 2 snap parameters (code, id) as given from the Agilicus Admin
At this stage the Agilicus Connector should be running and should stay up to date.
Details
Download the snap from the Agilicus website (https://www.agilicus.com/www/releases/secure-agent/stable/agilicus-connector_multi.snap). Install it with sudo snap install agilicus-connector_multi.snap --devmode --dangerous. This will make it unconstrained. NOTE: work is underway to restrict and publish.
In the Agilicus Admin, use Resources/New to create your connector (or Resources/Overview to re-install if you are debugging and iterating). NOTE: if you do uninstall and re-install, remember to delete the stale instance.
On the Install screen, use the ‘Manual’ instructions. You will copy the challenge-id parameter, and then run sudo snap set agilicus-connector setup.id=XXXXX of it. You will then copy the challenge-code, and run sudo snap set agilicus-connector setup.code=XXXX of it. See the below image.
At this stage, the Agilicus connector should start automatically. You may see its logs as sudo snap logs -f agilicus-connector
You should see your Connector transition to ‘Good’. You may also check the statistics on the action menu. A good first service to try is a ‘share’ since it will run entirely within the Snap. You might then try reaching a service on the host running the Agilicus Connector – Snap.
Notes:
Ensure that the time is synced via NTP on the device running the snap. The cryptography has a ‘not-before’ time that requires proper time sync.
Ensure the device is able to reach www.agilicus.com (34.95.12.47), api.agilicus.com (35.203.36.11) on HTTPS port 443. You may test this with: curl https://www.agilicus.com/ and https://api.agilicus.com/v1/resolve/?name=www.agilicus.com.
If you use your own domain, and run split-horizon DNS, ensure it properly resolves the CNAME.
You can now create an issuer for a suborganisation from a parent organisation. Doing so will bring up a new admin/profile endpoint for the suborganisation, at the suborganisation’s subdomain. E.g. admin.suborg.myorg.cloud.
You can now create an issuer for a suborganisation from a parent organisation. Doing so will bring up a new admin/profile endpoint for the suborganisation, at the suborganisation’s subdomain. E.g. admin.suborg.myorg.cloud.
You do this from the suborganisations screen:
By default, the new suborganisation will inherit the authentication policy of its parent, as well as any Managed or Custom identity sources you have configured in the issuer being used for the parent. You will likely want to verify the customer identity sources to ensure that they have added your new issuer to their list of redirects.
As long as you had permission to configure the suborganisation prior to enabling the new issuer on it, you can switch to it via the org choose as always. However, now that there is an issuer on that suborganisation, you will be able to customize it like you would its parent: you can create new sources of identity, customize the theme, set a new policy and so on.
To create a policy distinct from the parent organisation’s, simply choose one of the preset policy options from the Authentication Policy menu.
The GL-MT3000 (Beryl AX) has 1 x Gigabit Ethernet, 1 x 2.5 Gigabit Ethernet, 512MiB of RAM, and 256MiB of eMMC storage as well as WiFi 802.11AX. It is an excellent portable platform for demonstrations and field service to run the Agilicus Connector, supporting Cellular (via LTE), WiFI, Ethernet at a low cost point and small form factor.
Installing Stock OpenWRT
You may choose to run the Agilicus Connector on the GL-MT3000 (by using the advanced interface, and running the same commands as below to install ‘curl’, ‘ttyd’, and then the Agilicus Connector. Agilicus recommends replacing GL-iNet custom OpenWRT with the stock one, both for security, as well as compatibility and support.
Connect your laptop to the ‘LAN’ port (or WiFi if you prefer). Sign in to the web interface at http://192.168.8.1/. Navigate to the ‘Advanced settings’, which will log you in to Luci. Download the stock firmware (https://openwrt.org/toh/gl.inet/gl-mt3000), specifically the ‘Firmware OpenWRT Upgrade’ target , and then install via the ‘Backup/Flash Firmware’.
At this stage you are running Stock OpenWRT with its enormous ecosystem of tools, and its very simple to use web interface. You may open http://192.168.1.1/ and do any initial setup.
Agilicus Connector Install
To install the Agilicus connector, first we install the pre-requisite curl. we will also install a web terminal (ttyd).
At this stage, we can install the Agilicus connector. From the Agilicus admin web interface, select ‘Resources/New/Connector’. Copy the Linux command line, paste it into the Services/Terminal on the GL-MT3000. It will complete automatically, no further configuration is needed.
(Optional) Sample Configuration: Connect to Local HTTP (OpenWRT LuCI)
This walk through shows an example of how, once the connector is installed (as per above), configuration of an HTTP interface. Once these are configured you could use the firewall to disable all external access. The high level steps are:
Create Web Resource (Agilicus Admin)
Assign Web Resource Permission (Agilicus Admin)
Open Web Interface to NanoPi (Agilicus Profile or direct)
OK, let’s get started. This will take approximately 2 minutes.
Create a new application. Give it a name (which must be valid as a hostname in format). You will later be accessing this as https://NAME.DOMAIN/. You might consider ‘gl-mt3000’ as a name.
You may, if you wish, have a well-known alias to this new web interface. This is more commonly done with very public ones (e.g. a Wiki or Timesheet system). Leave it as default and the Agilicus AnyX will create the hostname for you.
Select the connector from the previous step.
The connector has to know where to send the request (it is a proxy). The ‘upstream’ in this case is the GL-MT3000 itself, e.g. localhost port 80.
For a bit of additional security we can tie the ‘logout’ URL of the GL-MT3000 web interface to the Agilicus AnyX logout by copying in the URL of the logout. This is optional.
We also suggest that named users with a single role, configured later, for this sample. Normally you would create a group, e.g. ‘Web Admins’ and assign users to it.
At this stage we are done, select ‘Apply’.
Now we will assign ourselves permission to use this new web resource.
To make the profile a bit more ‘fun’ we can now assign a logo (an icon) to the launch of this web interface. In this ‘define’ section we could also refine the Web Application Firewall rules etc.
Any image file (we suggest about 512×512) is suitable for a logo.
At this stage we are done. We have:
created and installed a connector on this GL-MT3000
created a Web resource (to the NanoPi itself)
We can now test our work. Open https://profile.YOURDOMAIN/
Once you have signed in, you will see an icon for the new web resource, if you click it, a new browser tab will open. Observe the URL (https://NAME.DOMAIN). You can use this directly without profile if you wish. If you sign in, you will see the GL-MT3000 web interface directly. Now try it from a different network (e.g. your mobile phone, disable WiFi). Observe you can still connect. Now try with an unprivileged user (e.g. a different Gmail account), observe you cannot sign in.
The ‘profile’ interface acts as a launch pad for the end-user. It will act as a Progressive Web Application (e.g. ‘add to homescreen’ on your mobile), giving you a single launch icon.
You may also use the resources it points to directly: it is your choice.
We can test the SSH access. From profile, select the resource we created earlier.
We will see a ‘login’ dialog appear, enter the username (root) and password to the GL-MT3000.
At this stage, we should see an SSH terminal.
From here, consider using the ‘Launcher’ install feature of profile, add the Browser Extension. You will now see an entry on your start menu for this SSH, opening the native client (e.g. if you have Putty or OpenSSH installed).
Similarly to the Web Resource, only users with permission are able to sign in. You may also choose to enable multi-factor authentication on your user and observe how this functions with the Web..
Agilicus AnyX is designed to be nested multi-tenant, meaning Organisations can have Organisations that can have Organisations.
This in turn allows one company to support other companies.
New Setup
You can setup your customer using Organisation/New. You will need a DNS wildcard CNAME setup (*.theirdomain). See CNAME + DOMAIN: Theory of Operation for more information.
Pick any name you wish for your customer. You will see this in the invoice information.
Now enter the DNS name you have chosen. This should be setup as a wildcard CNAME pointing to Agilicus (e.g. *.THISDOMAIN -> ca-1.agilicus.ca).
At this stage hit ‘Apply’ and the new organisation should be setup in about 60-90 seconds.
Billing, Trial Management
By default, each new setup has a 25-day trial. You can see the trial dates and usage volumes on the Organisation/Billing page. There will be one row per customer.
The Agilicus Connector can be installed in a high-availability mode. In this mode, multiple copies of the connector will concurrently run. Each connector which is up and healthy will share in some of the network traffic. Encryption keys are shared across the connectors in such a way that they are still in the customer’s sole custody.
NOTE
The Agilicus Connector does not support High Availability if a Share is present. As a work-around, either create a Connector managing all resources other than Shares, or, use the Windows Cluster approach which does support a Share.
The installation instructions for the first connector in a High Availability set are the same, and, for each subsequent one, similar.
Installation
Installation is simple.
Create and install the first instance on a machine
Install subsequent instances (up to 4) on other machines
Pre-requisites:
One connector must be up for a new one to be added
All connectors must be able to reach the same network resources.
Initial (First) Connector in High Availability Set
The installation instructions for the first connector in a high availability set are the same as for non high-availability.
At this stage, the first connector is installed. Ensure it transitions to “GOOD” since it must be up and running to join the other connectors to the cluster.
Adding High Availability Peers (Subsequent Connectors)
To add additional high-availability peers, simply use the ‘Actions/Install Connector’ option on the first instance we created above.
At this stage we are done, and there are two connectors running in High Availability mode. Note the slight difference in the output of the installation at the end (“Joining existing cluster. This will fail if another connector in this cluster is not online“)
INFO[2024-04-01T11:55:38-04:00] Starting connector - version v0.246.9 INFO[2024-04-01T11:55:39-04:00] Check if the agilicus connector is already running as a service. If so stop it INFO[2024-04-01T11:55:39-04:00] Create file /usr/bin/agilicus-agent-wrapper.sh INFO[2024-04-01T11:55:39-04:00] Create file /etc/systemd/system/agilicus-agent.service INFO[2024-04-01T11:55:39-04:00] Will install to /agilicus-agent.service -> {/etc/systemd/system/agilicus-agent.service -r--r--r-- 0x14cf980} INFO[2024-04-01T11:55:39-04:00] Will install to /agilicus-agent-wrapper.sh -> {/usr/bin/agilicus-agent-wrapper.sh -rwxr-xr-x <nil>} INFO[2024-04-01T11:55:39-04:00] Create a directory at /opt/agilicus/agent/tufmetadata/latest INFO[2024-04-01T11:55:39-04:00] Create a directory at /opt/agilicus/agent/tufmetadata/stable INFO[2024-04-01T11:55:40-04:00] Create a user and group named Agilicus to run the agilicus-agent service INFO[2024-04-01T11:55:40-04:00] Copy executable to /opt/agilicus/agent INFO[2024-04-01T11:55:40-04:00] Set permissions to Agilicus on /opt/agilicus/agent INFO[2024-04-01T11:55:40-04:00] Create symlink from /usr/bin/agilicus-agent to /opt/agilicus/agent/agilicus-agent INFO[2024-04-01T11:55:41-04:00] creating connector instance INFO[2024-04-01T11:55:41-04:00] Join a connector cluster INFO[2024-04-01T11:55:41-04:00] Joining existing cluster. This will fail if another connector in this cluster is not online INFO[2024-04-01T11:56:01-04:00] Start agilicus-agent service
