Access to the configuration can be restricted. The access control model works based on user permissions defined using the object in the config itself.
Initial config
The initial configuration has no users defined. Until a user is defined full access is available to the config with no login It is therefore important to add a user to a new FireBrick.
Editing the Configuration
General config edit
Config view and edit are only available to users that have at least ADMIN access level. This is the default access level.
It is possible to create users with lower levels of access that cannot view or edit the config in any way but may be able to carry out other tasks via the web interface or console.
In addition to this access level, defined by level=”…” in the <user…/> object, there is also a config=”…” attribute that defines whether the user has access to the config as a whole.
The default it full and the options are:-
none User cannot view or edit the config as a whole.
view User cannot view the config as a whole but only in a safe mode, with all passwords hidden.
This view of the config cannot be used to load into a FireBrick.
read User can view the config as a whole (including any plain text passwords) and download in a form that could be loaded into another FireBrick.
full User has full access to view and edit the config as a whole.
Config object edit
In addition to the above controls on managing the config as a whole, there is also a facility to access specific parts of the config.
Note: This is not yet released, but this is how it works…
Within the config definition, some objects are marked as editable (they are tagged fb:edit=”true” in the published XSD.
These are either a single instance top-level object such as <system…/> or a multiple instance objects that has a specific unique index attribute, such as <user…/> or <rule-set…/>.
Each editable object will have attributes, and possibly other objects that it contains. If it is a multiple instance object then one or more of these is marked as the index attribute (using fb:edit=”index” in the published XSD).
For example, in the user object, the name is the index. Also, some of the attributes will be marked as editable (with fb:edit=”true”).
Editable objects also have an access=”…” attribute which contains a list of user names that is allowed to edit the object.
Access security
Access to config depends on a specific user performing the access. This is either done in a session using a cookie from a previous login to the web interface or by using HTTP basic authentication (–user “username:password” in curl).
Object list
Via the web pages, or using a specific URL a user can obtain a list of all instances of a specific object type to which he has access.
If the user has an access setting other than none as his config access level then the list will include all objects of the specified type.
If he has none it will only include objects of the specified type that include that user name in the objects access list.
The list contains each object and all attributes but not any contained objects within it. If the user only has view config access and is not listed in the objects access list then any attributes which are passwords are hidden.
The URL is /config/list?object=objecttype
Object fetch
Using the object type and (for multiple instance objects) the index field(s) a user can fetch a full copy of any object to which he has access. This includes any contained objects and all attributes.
The user only has access if they have config access other than none or they are listed in the access list for the object.
If the user has config access of view and not listed in the access list then all passwords within the object and any contained objects are hidden.
The URL is /config/fetch?object=objecttype&key=keyvalue. For single-instance objects the key is omitted.
Object update
The user can submit a complete instance of an object to update the config. Depending on access level this could replace the existing object, move an existing object or insert a new object in a list.
In all cases, a new config is constructed with the changes and that new config processed.
Note: Object editing is subject to some change as not fully implemented yet. The concept is that web-based javascript will allow object editing. When design and coding for this are complete it is likely that there will be changes to this specification. We welcome feedback on the design.
Replace
The URL is /config/update?object=objecttype&key=keyvalue. For single instance objects the key is omitted.
The XML is checked to be syntactically correct as a single object and that it has the right object type and key-value, and that any attributes that cannot be edited match the existing object.
The access rights on the existing object are checked. If the user has full rights or is listed in the object access list then the new object replaces the old.
Move
The URL is /config/update?object=objecttype&key=keyvalue. To move the object the URL also has &before=keyvalue or &atend to indicate the new location for the object.
To move an object the user must have full access rights.
Insert
The URL is /config/insert?object=objecttype&key=keyvalue. To insert the object the URL also has &before=keyvalue or &atend to indicate the new location for the object. If these are omitted then the object is inserted at the start.
For single-instance objects, the key, and before/atend is omitted, and /config/replace can be used instead.
To insert an object the user must have full access rights.
Erase
The URL is /config/erase?object=objecttype&key=keyvalue. For single-instance objects the key is omitted.
The user must have full access rights to erase an object. No XML is posted in this case.