Overview
Figure: Live system overview
FirstSpirit Clients: Communicate exclusively with the FirstSpirit server and never directly with, e.g., an LDAP server or database (for further information see Architecture - Overview).
FirstSpirit Server: Processes all client requests, manages accesses to external resources (databases etc.), generates preview pages, attends to the staging and live system (for further information see Architecture - Overview).
Staging system: (Also “generation directory”) is used for the final check of the total system including, if necessary, occurred application integration. All web applications and modules of the live system have to run here. In contrast to the preview system, the directory and file names are identical to the structures of the subsequent live system. The configurations of all the web applications essentially correspond to the ones of the live systems, except for absolute paths and URL prefixes (for further information see Architecture - Overview).
Live system: The system visible to the end user. All the relevant data within the scope of deployments is transferred into the live system (for further information see Architecture - Overview).
FirstSpirit-Client, Server and preview generation
The permission component is usually used as an input component in the metadata tab. The component is (project-specifically in the metadata form) parameterised with a unique group document. The permission component uses this name to determine the corresponding structure in the FirstSpirit Server. This takes place via the permission service – this service is a special FirstSpirit Server service responsible for managing group and user configurations (for the configuration of the file fs-server.conf see Activating the permission service).
Live system extract
The group and user configurations managed by the “permission service” are configured in the service configuration file (service.ini). The respective XML files can be generated manually (via FirstSpirit ServerMonitoring), or automatically via a connector script based on an exiting user/group management system (e.g. LDAP or Active Directory).
Using a group/structure definition the editor can subsequently carry out a permission definition for an object in the FirstSpirit Client.
As described under Application in the project it is possible to use the permission definition as “target permission” for the personalization, or within the scope of the access protection using the Access Control Database and the Multi-Access Control Filter.
At this point a further security mechanism steps in. This mechanism has no relation to the user permission definition, but should nevertheless be mentioned here. The “preview servlet”. The preview servlet is responsible for monitoring the access permissions during a preview request (see Secure media within FirstSpirit preview). The preview servlet provides the content and the request is internally redirected to the web server. This architecture is necessary if an HTTP server-specific extension is to be used, e.g. ASP or PHP extensions in the preview.
While the preview servlet only steps in on the access layer, the Multi-Access Control Filter works on the object layer. The main difference to configuration in the live system is that the files required by the FirstSpirit web applications (e.g. content schema or OR runtime, or user.xml and groups.xml for personalization) can be accessed directly in the preview, while copies of the files have to be deployed in the live system.
Staging system (generation)
The staging system differs from the FirstSpirit preview system, particularly the file storage organisation. While all files are generated with “artificial” names and without directories in the preview system for performance reasons, the structure of the staging system is identical to the live system structure. Therefore, it is also possible to integrate applications which do not principally run within the preview (due to the already mentioned differences).
The basic structure of the HTTP server infrastructure is identical to the preview system structure (see Architecture - Overview)
Live and staging system
The multi-access-control filter is only effective if the object is really provided by the servlet engine. This aspect will be illustrated in more detail using a PDF file which, e.g., has been generated from a page of the Page-Store, but is not a “secure medium”. In an unfavourable case, the PDF document is provided directly via the HTTP server. The multi-access-control filter, which is part of the servlet engine, is unable to prevent the provision. It has to be ensured that the HTTP server request is redirected to the servlet engine where it is processed.
Please note that the content provision takes place via the servlet engine. This method is less efficient than direct provision via the HTTP server. Another disadvantage of the staging system and of the live system is that they communicate directly with the Access Control Database to check the permission.
Live system
In contrast to the staging system, the FirstSpirit Server cannot control the web application configuration in the live system. Therefore, configuration has to take place manually. One possibility is to use the automatically generated configuration files of the FirstSpirit web applications as the starting basis. Usually only a few paths have to be adapted to the live system.
The live system is updated by the deployment manager located on the FirstSpirit Server. The deployment manager is responsible for the compilation of all relevant data and its upload onto the live system. In the live system, access check management occurs either independently or on the basis of the information of the Access Control Database (see Checking access rights).