Checking access rights via the Access Control Database

Therefore, protection must be provided at the level of the file delivery to realise reliable protection for objects which cannot perform a permissions check themselves. In FirstSporit the FirstSpirit Security module is available for this purpose. When a project is generated a local Access Control database is created which manages all permissions information for the individual project content. Comparison/synchronisation of this local Access Control database with the live system takes place via the FirstSpirit Security module (via the CRC Transfer Servlet – see FirstSpirit Security module documentation). The module can be used, among other things, to define a filter (“Multi-Access Control Filter”), which reliably prevents delivery of all objects which match the filter criteria (The server does not deliver the protected files).

The concept of “Secure media” can also be realised in the live system via the FirstSpirit Security module and a filter individually adapted filter to the required “Secure Media” directory (or the medial file).

Configuration takes place via FirstSpirit ServerManager.

For further information, see documentation for the FirstSpirit Security module.

Access Control Database

A sub-area of the FirstSpirit Security module is the Access Control database. An Access Control database consists of several “Access Control Lists” (ACL). The Access Control database manages any project file information (e.g. pages, media). Apart from many other different types of information, for example the object's CRC 32 checksum required for differential upload (cf. Deployment via the FirstSpirit Deployment Servlet), the Access Control database can also be used to save the access rights to an object (i.e. rights of a user of the generated site – “user rights”). With the help of individually configured filters, which are also made available via the module, access to generated project content can be controlled in this way (see Multi-Access Control Filter, below).

The local Access Control database of a schedule is created with the first generation and is updated with each further generation.

For further information, see documentation for the FirstSpirit Security module.

Multi-Access Control Filters

The Multi-Access Control Filters can be used to define different filters for project content for which special access protection is required within the generated or deployed content. The task of the Multi-Access Control Filter is to check a certain class of objects before delivery with respect to their permissions configuration. The filter uses the information from the Access Control database for the check. 

The Multi-Access Control Filter is realised as a servlet filter which must be configured in the staging and Live system in the relevant web application. A specific generation directory (or an individual object) can be given, which is to be checked by the filter. The validity areas (scope) of the filter can be defined within the scope of the mapping. To do this, a URL pattern is defined with the URL classes and specific file filters can be described. The Multi-Access Control Filter can be further adjusted using parameters, for example by specifying specific access rights only to be checked or by limiting filtering to specific files (e.g. PDF files only). Several different filters can be configured within a configuration.

When defining the URL pattern, always consider that servlet execution prior to providing an object which matches a filter criterion results in increased computing effort. URL patterns should, therefore, always be kept as “small” as possible. This means that “/” should never be mapped if “*.pdf” is sufficient.

For further information, see documentation for the FirstSpirit Security module.