Securing the server

Architecturally, the Razor server is a fairly standard web service, consisting of the web server itself (embedded in Torquebox) and the PostgreSQL database; as such, access to these components can be secured by the usual means of operating system security.

Over the network, Razor exposes a RESTful API via HTTP; the API actually consists of two parts: one, mapped underneath /api meant to control the provisioning process to which administrators connect to create policies, view node information, etc. the other, mapped underneath /svc for communication between nodes and the server. By its very nature, the latter can only be secured by restricting access to the /svc URL space on the server at the network level.

The management API underneath /api is secured with basic HTTP authentication.

Since the username and password are sent in the clear in HTTP headers, it is crucially important that access to /api only happens via HTTPS. The Torquebox documentation has details on how to configure that.

Authentication information is configured in shiro.ini in the server's root directory. The configuration format is described in the Shiro documentation.

You can also find some example shiro configuration files for interfacing to external data sources such as Active Directory or a JDBC supported database in the distribution.

Razor Authentication Structure

This documents the current authentication trees available in Razor, and their structure. This will be useful in setting up your own roles.

Commands -- changes to the system

All the commands authorize in this structure:

commands:${name}:${subject}

name is the name of the command (eg: create-repo, delete-repo).

subject is the name of the main object (eg: create-repo:esxi55, delete-repo:esxi55).

When a command applies to multiple subjects, we will assert the permission required for all of them.

Queries -- reading data from the system

Queries authenticate in the structure:

query:${collection}:${name}

The one exception is the node logs:

query:${collection}:${name}:logs

collection is the name of the collection (eg: tags, brokers).

name is the name of the entity (eg: tags:virtual, brokers:puppet).

Reading node logs requires does not require reading data for the node, but reading data for the node implicitly grants reading logs.