Access Control

Apart from basic user account access control, you can also setup access control to specific endpoints (for example, particular web pages).

You can do this through the security files. There's one shared file at /model/defaults in your ARDI installation directory, and you can also create site-specific security files by creating a file called security.json in your site folder.

Below is an example of the default security settings.

{
	"paths": {
		"api/drivers": "local",
		"api/driverdata": "local",
		"api/driverdetails": "local",
		"prometheus/live": "prometheus",
		"admin/": "admin",
		"admin/sites/purge": "restricted",
		"admin/sites/reset": "restricted",
		"admin/restore/": "restricted"
	},
	"groups": {
		"local": {
			"type": "whitelist",
			"list": ["127.0.0.1","localhost"]
		},
		"prometheus": {
			"type": "whitelist",
			"list": ["127.0.0.1","localhost"]
		},
		"admin": {
			"type": "useraccess",
			"level": "admin"
		},
		"blocked": {
			"type": "block"
		},
		"restricted": {
			"type": "isuser",
			"list": ["admin"]
		}
	}
}

The paths section contains a list of web URLs that you'd like to protect.

A url that ends with a slash (/) character protects the entire folder, while one that ends without a slash only protects that specific URL.

For example, admin/sites/purge specifically protects the page that allows you to erase your ARDI database, while admin/ protects every page in your 'admin' folder.

Each path has a matching group which defines the access control rules.

Access control rules are bundled into groups, making it easier to modify security settings (for example, it's much easier to update one group than it is to update a dozen individual paths).

Each group has a either a single security rule, or a list of them. Each security rule has a type, such as those below…

whitelist - Allows access to specific IP addresses
userlevel - Allows access to a specific user level
isuser - Allows access to a specific user
token - Requires a specific HTTP header/token

Most rules (such as whitelist, userlevel and isuser) can be set to deny rather than allow, making the 'whitelist' function work as a 'blacklist'.

In the default example above, there are a few basic rules.

1) The API functions for ARDI-to-driver communication (api/drivers, api/driverdata and api/driverdetails) and for Prometheus recording (prometheus/live) are restricted to local access only - meaning only users (and drivers) running on the ARDI server itself can access those particular functions.

2) The entire admin folder is protected against access by non-admin users (NOTE: most administrative pages have their own internal security tests that can't be overridden by this file).

3) Several very destructive pages (database purging and restoration) are limited so that they can only be accessed by the 'admin' user specifically. In this case, even if a different user tried to reset the database, they'd be denied access.