Jetspeed 2
  1. Jetspeed 2
  2. JS2-1262

Enforced portlet level security constraints checking at render time through custom jetspeed-portlet.xml metadata

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.1
    • Fix Version/s: 2.2.2
    • Component/s: Security
    • Labels:
      None

      Description

      For some administrative portlets it is required to enforce security constraints on portlet definition level, e.g. restrict (all) usage for certain admin portlets to users having admin only.
      By default, Jetspeed only enforces portlet level security constraints (see: http://portals.apache.org/jetspeed-2/deployguide/guide-registry.html, section jetspeed-portlet.xml) while adding new portlet instances to a page/fragment.
      Once a portlet has been instantiated, only the page/fragment security constraints are enforced.

      This default behavior can be changed globally, but has rather a high impact as potentially the expected behavior of existing portlet instances might thereby change.

      As an light-weight alternative, I will add support for an additonal, portlet level meta data configuration through jetspeed-portlet.xml which allows turning this behavior on for individual portlets only.
      By adding a <js:metadata name="render-time.security-constraints">true</js:metadata> tag to a portlet configuration in jetspeed-portlet.xml, the security constraints for that portlet will be enforced at render time.

        Activity

        ate committed 1178678 (22 files)
        Reviews: none

        JS2-1263: Hardening j2-admin security by restricting access to hot deployment and portlet metadata features to admin role only
        Both portlet render time enforcement of admin constraints and related psml level admin constraints (hiding portlets/pages instead of showing 'Access Denied') added
        See also JS2-1262 for more detail concerning individual portlet render time constraints checking configuration.

        Portlets/pages 'locked down' this way:
        - PAM (Portlet Application Manager)
        - RPAD (Remote Portlet Application Deployer)
        - Permissions & Constraints management
        - PortalDataSerializer (Import/Export)

        portals trunk
        Ate Douma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        ate committed 1178677 (1 file)
        Reviews: none

        JS2-1262: Enforced portlet level security constraints checking at render time through custom jetspeed-portlet.xml metadata
        See: https://issues.apache.org/jira/browse/JS2-1262

        Ate Douma made changes -
        Summary Adding enforced portlet level security constraints checking at render time through custom jetspeed-portlet.xml metadata Enforced portlet level security constraints checking at render time through custom jetspeed-portlet.xml metadata
        Ate Douma made changes -
        Field Original Value New Value
        Summary Hardening j2-admin security by enabling render-time enforcement of security constraints defined on portlet level and restricting access to hot deployment and portlet metadata features to admin role only Adding enforced portlet level security constraints checking at render time through custom jetspeed-portlet.xml metadata
        Description Jetspeed currently enforces security constraints defined on portlet (descriptor) level only for adding new portlets to a page fragment.
        These portlet level constraints are by default not enforced for already existing portlet fragments, only the security constraints on the fragment itself.
        This however makes it difficult (up to impossible) to completely 'lock down' for instance access to certain administrative portlets to users with admin role only if such a portlet already has been setup for a fragment with lesser strict security constraints.

        And good example for this is the PortletApplicationManager. This is typically a portlet which only a user with admin role should be allowed to use (and see).
        Restricting such access can easily be done by defining a admin-only security constraint on the fragment containing this portlet.
        However, if another user, with for instance (only) a manager role has (and needs) access to the PortalSiteManager portlet, this might pose a potential security issue.
        The manager user then can modify the security constraint of the PortletApplicationManager fragment to relax it again, and also allow access for users with manager role.

        The only proper way to truly lock down access to the PortletApplicationManager portlet then is through a portlet level security constraint, as can be defined in jetspeed-portlet.xml with a js:security-constraint-ref tag, see: http://portals.apache.org/jetspeed-2/deployguide/guide-registry.html
        However, as described above this is currently not enforced by default, e.g. as a render-time check, only while adding new portlets to a page.

        Switching this default is a trivial change, as also described in the registry guide, through the Spring assembly configuration for the PortletRenderer.
        However, when we do this, by default, the behavior and logic for the (primarily j2-admin) portlets does change (flip) as well.
        As default Jetspeed only comes with security constraints configuration for j2-admin portlets, this change requires updating and adjusting the j2-admin jetspeed-portlet.xml accordingly.


        This will require the following changes:

        - enable render-time security constraints enforcement in the PortletRenderer configuration

        - change the default application level j2-admin security constraint from <js:security-constraint-ref>admin</js:security-constraint-ref> to <js:security-constraint-ref>AEUV</js:security-constraint-ref>
        This will retain the default behavior as with without render-time security constraints enforcement, e.g. any user may see already pre-instantiated j2-admin portlets, as long as they have the appropriate access for the containing fragment (or page).

        - add new/additional PortletSelector <js:metadata name="selector.conditional.role">admin</js:metadata> constraints to j2-admin jetspeed-portlet.xml to retain the restricted set of portlets which can be added to a page as before
        Previously j2-admin portlets were by default restricted from adding to a page to users with admin role only, but with the new j2-admin application level <js:security-constraint-ref>AEUV</js:security-constraint-ref> this longer is the case.
        So, every portlet which should not be allowed to be added by anyone other than admin users now needs to be explicitly restricted with <js:metadata name="selector.conditional.role">admin</js:metadata>

        The above changes then will result in effectively the same *default* behavior as before.
        But it now also allows to further restrict global render-time access to selected portlets where needed.

        The primarily goal of these changes is to limit hot deployment and portlet application meta data to admin users only.
        For hot deployment, this means locking down access to the Portlet Application Manager portlet (PAM), the Remote Portlet Application Deployer (RPAD) and the PortletCloneManager portlet.
        And to ensure non-admin users won't be able to 'break' this down, the same is also required for the Permissions, Constraints and Import/Export admin portlets.
           

         
        For some administrative portlets it is required to enforce security constraints on portlet definition level, e.g. restrict (all) usage for certain admin portlets to users having admin only.
        By default, Jetspeed only enforces portlet level security constraints (see: http://portals.apache.org/jetspeed-2/deployguide/guide-registry.html, section jetspeed-portlet.xml) while adding new portlet instances to a page/fragment.
        Once a portlet has been instantiated, only the page/fragment security constraints are enforced.

        This default behavior can be changed globally, but has rather a high impact as potentially the expected behavior of existing portlet instances might thereby change.

        As an light-weight alternative, I will add support for an additonal, portlet level meta data configuration through jetspeed-portlet.xml which allows turning this behavior on for individual portlets only.
        By adding a <js:metadata name="render-time.security-constraints">true</js:metadata> tag to a portlet configuration in jetspeed-portlet.xml, the security constraints for that portlet will be enforced at render time.
        Ate Douma created issue -

          People

          • Assignee:
            Ate Douma
            Reporter:
            Ate Douma
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development