Personalization

The module “FirstSpirit DynamicPersonalization” consists of an easy-to-use Java TAG library for personalizing JSP pages, i.e. page display can be completely or partially prevented. Whether a part area of a page is visible or not depends on the user permission. This is decided by comparing the target permission of the page to the user’s actual permission.

The target permission (Who is allowed to view a document or a part of the document?) takes place via the permission component. The personalization carries out the evaluation, i.e. a comparison of the actual configuration, resulting from the user’s login context, with the target configuration. Within this context there is a close (logical) relation between the groups which are used in the permission component and the groups to which the “group module” of the personalization refers.

Example: If a user belongs to a group which does not appear in the permission component, it might not be possible to set permissions for the user.

This relation between the group model in the permission component and the one in the personalization module can be established as follows:

1. The generation of the group definition file for the permission component and the "group module” of the personalization evaluate the same external data sources (e.g.: LDAP server or AD server). In this case, data sovereignty is completely external.
2. The permission component generates a group definition file and the personalization module uses this data or refers to this file. The permission component can generate this file by requesting an LDAP server. The difference is that the personalization module does not request the LDAP server, but uses the data basis generated by the permission component.

While the “group module” of the personalization is configured to the modes “Content-Store” or “LDAP” in the first case (and the runtime environment requires a permanent connection to the data source), the “group module” has to be configured as “group service” in the second case and then uses the same XML files as the permission component. Therefore, the second case does not require permanent access to an external resource. Nonetheless, it has to be ensured that the group configuration files are also deployed on the live system during deployment configuration (see Configuration for the deployment).

Permission checks can only be forced on JSP pages through use of personalization in FirstSpirit. The personalized hiding of links can therefore be used to make access to non-JSP documents difficult (e.g. PDF files or pictures). However, this does not provide reliable protection as delivery can be forced by direct entry of the links. The module should therefore always be combined with the standard FirstSpirit SECURITY module (for details of concept see Checking access rights).

The FirstSpirit Personalization module is an additional function which has to be purchased.

For further information see the FirstSpirit Personalization documentation ().