Package nl.tailormap.viewer.config.security

Class Authorizations

  • public class Authorizations
extends Object
    Utility class for authorization checking. Because of the inheritence of authorizations in tree structures, caches are used for efficient authorization checks.

    There are authorizations on these objects:

    Geo services registry:

    • Categories: currently disabled, not accessible via user interface
    • Layers of GeoServices: with inheritence, read/write authorizations

    Application:

    • Levels: with inheritence, read authorization only
    • ApplicationLayers of Levels: inherits from Level and the referenced Layer, read/write authorizations
    • ConfiguredComponents

    Authorizations are based on role names which are Group names.

    Inheritence and authorization rules:

    1. The empty set of authorized role names (EVERYBODY) means everybody is authorized.
    2. A non-empty set which is not equal to NOBODY means only users who are members of the named Groups in the set are authorized
    3. NOBODY is the set containing a single value which is null.
    4. Inheritence processing starts at the root with everybody authorized.
    5. When inheriting authorizations, the set of authorized roles can only be reduced and not expanded. When a parent is authorized for roles A and B and the set of authorized roles for a child is B and C, only B is authorized. When the child is only authorized for role C, nobody will be authorized for the child.
    6. Because of the default access for everybody, denying editing for example is done by only authorizing write access to a group which has no members.
    Caching
    • Layer authorizations are cached and invalidated when authorizations are changed for a GeoService by updating the GeoService.authorizationsModified timestamp.
    • Level and ApplicationLayer authorizations are cached and invalidated when authorizations on a Level or ApplicationLayer are changed by updating the Application.authorizationsModified timestamp.
    • Because ApplicationLayer authorizations inherit from Layer authorizations, Application caches are invalidated when any authorization on a Layer changes.
    Although when authorizations are changed for an object only the cached object and its inheriting objects could be refreshed in the cache, the entire set of cached Layers of a GeoService or cached Levels and ApplicationLayers of an Application are invalidated because:
    1. The viewer-admin webapp is isolated from the viewer webapp so it cannot access its application-scope cache without extra cross-webapp communication.
    2. The viewer-admin webapp communicates with the viewer webapp to refresh its cache by updating the above mentioned authorizationChanged database columns.
    3. The cache for an Application is invalidated when the maximum authorization changed date (for all GeoServices) column is later than the Application authorization changed date.
    4. These database columns are the simplest method to refresh the cache, and no partial updates are required to maintain performance because authorizations are modified infrequently.
    5. Applying inherited authorizations is optimized by loading a tree in a single query using hierarchical queries.

    Group membership for a User is not cached and read from the database for the first authorization check in a Transaction. So authorization changes by an administrator should always be directly applied except authorization checks which use HttpServletRequest.isUserInRole(), which is cached by the servlet container. Currently only viewer-admin checks roles this way.

    Author:
    Matthijs Laan

    • Method Detail

      • isFormAuthorized

        public static boolean isFormAuthorized​(Form f,
                                       Set<String> userRoles,
                                       javax.persistence.EntityManager em)

      • isUserExpired

        public static boolean isUserExpired​(User u)