This documentation describes how authorizations are combined and optimized at query runtime before the actual check takes place. In particular, this documentation explains how characteristics for which no explicit entries are available are handled.
The optimization runs as follows:
If a characteristic is not specified in an authorization, this means first of all that the authorized values for this characteristic are not defined. Therefore, all authorized entries of all other authorizations are referenced - of course taking into account the rules for multidimensional "combinatory" restrictions. Only if the user has no other authorization that can contribute to the empty characteristic does this user have no authorization at all. The message "No authorization" then appears if this characteristic occurs here in the InfoProvider. Note: Even if the characteristic does not occur in the query, authorization is required. For more information, seeAuthorization for Aggregated Values.
After the empty dimensions have been filled, the resulting authorizations are combined if possible.
Steps (1) and (2) are repeated until no further optimization is possible.
This logic simplifies the maintenance and delivers a mechanism with which different contexts can be split up into different authorizations and then automatically combined "as expected".
You can trace the optimization steps in the authorization log. Multiple iteration steps can be required to obtain the final record of authorizations. For these reasons, the authorizations are simply numbered (1, 2, 3, and so on). This is displayed in the authorization log. The process for combining and preoptimizing the authorizations was itself optimized and some of the steps are not therefore obvious.
It is of course always possible to build authorizations in such a way that they produce so many new different authorizations that performance is negatively impacted. It is not technically possible, however, to clearly predict this and display a warning when the authorizations are being assigned to users.
You should therefore try to keep the authorization concept simple. You can do this, for example, by reducing the number of authorization-relevant characteristics in the InfoProvider or by reducing the number of authorizations that are assigned to a user.
An inconsistent description of characteristic values can also have undesirable effects. For example, using an interval [01,03] in one authorization and individual values 01 and 03 in another. Logically, this is the same for Activity. This is not however the same for characteristics with a length of 10 characters. Here, the consistent use of one of the two expressions (interval or list of individual values) would be logically identical, but would result in better performance.
Important: A differentiation is normally made between the two descriptions. The underlying type of the characteristic cannot be checked for performance reasons, and the two descriptions are not usually identical.