Jetspeed 2
  1. Jetspeed 2
  2. JS2-354

Provision for portlet-level permissions

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-M4, 2.0-FINAL
    • Fix Version/s: 2.1
    • Component/s: Security
    • Labels:
      None
    • Environment:
      Generic

      Description

      There has been a lot of discussion on this aspect in both the developer and user forums. Even though the portlet content can be controlled from within the Portlet (by checking for the appropriate roles), it would be nice to control the content from a layer above like PSML (or the RdbmsPolicy). That gives the programmer the flexibility to modify the permissions per portlet, and hence the content without any code change.

      Since the feature has already been implemented, but just disabled (refer David's and Randy's comments in the forums), I hope its not too much of work to provide this feature. Sincerely appreciate your effort folks!

        Activity

        Hide
        Randy Watler added a comment -

        Ate has requsted that if we do choose to implement this feature, that it be enabled/disabled via configuration.

        It is still not clear how a portlet should be removed if access is not granted. In particular, should both the action and render phases be skipped, just rendering, or should all phases be executed and the content simply stripped from the layout. If either phase is to be executed, how can or should the portal communicate the fact that access is not granted to the portlet?

        What are the ramifications of stripping a portlet out of a layout? Do we need to consider having a "Access Forbidden" portlet placeholder, and if so, how would it be specified?

        Finally, does this feature need to be bundled with or related to the proposed "Portlet Menu"/"J1 Fragment" functionality that allows portlets to appear conditionally within pages based on menu selections or other url criteria?

        Show
        Randy Watler added a comment - Ate has requsted that if we do choose to implement this feature, that it be enabled/disabled via configuration. It is still not clear how a portlet should be removed if access is not granted. In particular, should both the action and render phases be skipped, just rendering, or should all phases be executed and the content simply stripped from the layout. If either phase is to be executed, how can or should the portal communicate the fact that access is not granted to the portlet? What are the ramifications of stripping a portlet out of a layout? Do we need to consider having a "Access Forbidden" portlet placeholder, and if so, how would it be specified? Finally, does this feature need to be bundled with or related to the proposed "Portlet Menu"/"J1 Fragment" functionality that allows portlets to appear conditionally within pages based on menu selections or other url criteria?
        Hide
        David Sean Taylor added a comment -

        > If either phase is to be executed, how can or should the portal communicate the fact that access is not granted to the portlet?

        The portlet content could be optionally rendered with the message "Access Forbidden"
        However I don't think thats always the required behavior
        Instead I would make it optional in the aggregator configuration.
        The other option will be to render the portlet empty
        I'll look into this since Im in the middle of the aggregator refactoring this week

        The other issue is : should we support another way of securing access besides the policy.
        It could be defined in:

        • jetspeed-portlet.xml
        • PSML fragments referencing page.security constraints
        Show
        David Sean Taylor added a comment - > If either phase is to be executed, how can or should the portal communicate the fact that access is not granted to the portlet? The portlet content could be optionally rendered with the message "Access Forbidden" However I don't think thats always the required behavior Instead I would make it optional in the aggregator configuration. The other option will be to render the portlet empty I'll look into this since Im in the middle of the aggregator refactoring this week The other issue is : should we support another way of securing access besides the policy. It could be defined in: jetspeed-portlet.xml PSML fragments referencing page.security constraints
        Hide
        Randy Watler added a comment -

        This issue has bee partially resolved with Fragment level security constraints implements in the DB PageManager.

        If the Castor/XML PageManager is intended to be used past the 2.0 release, this functionality will be ported to this implementation shortly after 2.0 is released.

        Show
        Randy Watler added a comment - This issue has bee partially resolved with Fragment level security constraints implements in the DB PageManager. If the Castor/XML PageManager is intended to be used past the 2.0 release, this functionality will be ported to this implementation shortly after 2.0 is released.
        Hide
        sunil kumar tiwari added a comment -

        From a user perspective, its better if no content is displayed. It should appear like the portlet doesnt exist at all i.e the user doesnt know about the portlet on the page.
        If we display some message like "Access Forbidden" then it may be confusing or irritating for the end user point of view. The user may want to enquire about the portlet in question which is not a good idea.

        For example, I have a page with 10 portlets on it. There are 3 groups of users. One group can see all the portlets, the other one only 8 portlets and the last group can see only 5 portlets.
        Now the page should appear normal, I mean, without any error message, to all the groups of users i.e. the page properly adjusted for each group.

        The advantage is that you have only one page with all the portlets on it but still serving to different sets of users with access to different subsets of all the portlets.

        Show
        sunil kumar tiwari added a comment - From a user perspective, its better if no content is displayed. It should appear like the portlet doesnt exist at all i.e the user doesnt know about the portlet on the page. If we display some message like "Access Forbidden" then it may be confusing or irritating for the end user point of view. The user may want to enquire about the portlet in question which is not a good idea. For example, I have a page with 10 portlets on it. There are 3 groups of users. One group can see all the portlets, the other one only 8 portlets and the last group can see only 5 portlets. Now the page should appear normal, I mean, without any error message, to all the groups of users i.e. the page properly adjusted for each group. The advantage is that you have only one page with all the portlets on it but still serving to different sets of users with access to different subsets of all the portlets.
        Hide
        Michael Gustav Simon added a comment -

        If access not granted the RenderRequest should not be executed for this portlet.
        I think the ActionRequest cannot be run, until a RenderRequest will generate the view.
        Remember, what will happen, if a portlet ist set to a personalized page by a pre-given right and this right will be decrated?
        How to mange the portlet level security constraint?
        Maybe a todo for the j2-admin portlets?
        It will be nice, if an administrator can configure the rights in the jetspeed administration web interface!

        Show
        Michael Gustav Simon added a comment - If access not granted the RenderRequest should not be executed for this portlet. I think the ActionRequest cannot be run, until a RenderRequest will generate the view. Remember, what will happen, if a portlet ist set to a personalized page by a pre-given right and this right will be decrated? How to mange the portlet level security constraint? Maybe a todo for the j2-admin portlets? It will be nice, if an administrator can configure the rights in the jetspeed administration web interface!
        Hide
        Ate Douma added a comment -

        Fully implemented in 2.1 and the permissions can be managed through the j2-admin Permissions portlet

        Show
        Ate Douma added a comment - Fully implemented in 2.1 and the permissions can be managed through the j2-admin Permissions portlet

          People

          • Assignee:
            Randy Watler
            Reporter:
            Prashanth Gujjeti
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development