Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-10640

BusinessObjectAuthorizationServiceImpl unmask methods do not consult authorizers for role qualifiers

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: KNS Equivalency
    • Labels:
      None
    • Similar issues:
      KULRICE-4405Adding check to role qualifiers in ResponsibilityService
      KULRICE-8490Recall Routing permissions do not work with KC role qualifiers
      KULRICE-11851DocumentPresentationControllerBase should consult isValidAction to filter workflow actions
      KULRICE-5339Finish integration with presentation controller/authorizer/AttributeSecurity checking KIM
      KULRICE-12836Role qualifiers lost on role maintenance document
      KULRICE-4153Inactive qualifiers cause problems on existing roles
      KULRICE-1470KIM Qualified Role with multiple qualifications
      KULRICE-9165Person document not displaying role qualifiers
      KULRICE-7896NullPointerException if no role qualifier added on Person document
      KULRICE-3989UIDocumentService.loadRoleMemberQualifiers - is there a way to load qualifiers not associated with the role type
    • Rice Module:
      KNS, KRAD
    • KRAD Feature Area:
      Authorization and Presentation
    • Application Requirement:
      KFS
    • Sprint:
      2.4.0-rc1 Sprint 3
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      org/kuali/rice/kns/service/impl/BusinessObjectAuthorizationServiceImpl's #canFullyUnmaskField and #canPartiallyUnmaskField always send in empty or null qualifiers when they do their permission checks. It would, ideally, look at an associated authorization class to build some qualifiers and send those into the check. As it is currently coded, assigning unmask permissions to derived roles fails, as the necessary information to derive role members has not been passed into the role type.

        Issue Links

          Activity

          Hide
          James Smith added a comment -

          Actually, with further research, I'm betting that role qualifiers do work if you're doing this check on a document (we just had a bad derived role).

          But...if you're trying to unmask on an inquiry and the unmask permission is granted to a derived role - that's problematic. What I did for our workaround (https://svn.kuali.org/repos/kfs/branches/release-5-tem/work/src/org/kuali/kfs/sys/service/impl/BusinessObjectAuthorizationServiceImpl.java) is to see if the business object being inquired on has an associated maintenance document, and if so, use the authorizer associated with that business object. Hopefully this didn't break too much, and obviously, it doesn't cover every business object...but it does something at least.

          There is a "BusinessObjectAuthorizerBase" in Rice, but no way to associated a BusinessObjectAuthorizer with an actual BusinessObject in the data dictionary - did I miss that somewhere? Even if so, the BusinessObjectAuthorizer was not being called in this code - in the case of an inquiry, the dataObject being inquired upon isn't even passed to #canFullyUnmaskField or #canPartiallyUnmaskField.

          And again: I can totally understand if KRAD does this stuff differently.

          Show
          James Smith added a comment - Actually, with further research, I'm betting that role qualifiers do work if you're doing this check on a document (we just had a bad derived role). But...if you're trying to unmask on an inquiry and the unmask permission is granted to a derived role - that's problematic. What I did for our workaround ( https://svn.kuali.org/repos/kfs/branches/release-5-tem/work/src/org/kuali/kfs/sys/service/impl/BusinessObjectAuthorizationServiceImpl.java ) is to see if the business object being inquired on has an associated maintenance document, and if so, use the authorizer associated with that business object. Hopefully this didn't break too much, and obviously, it doesn't cover every business object...but it does something at least. There is a "BusinessObjectAuthorizerBase" in Rice, but no way to associated a BusinessObjectAuthorizer with an actual BusinessObject in the data dictionary - did I miss that somewhere? Even if so, the BusinessObjectAuthorizer was not being called in this code - in the case of an inquiry, the dataObject being inquired upon isn't even passed to #canFullyUnmaskField or #canPartiallyUnmaskField. And again: I can totally understand if KRAD does this stuff differently.
          Hide
          Kristina Taylor (Inactive) added a comment -

          If KFS has already patched and tested it, then we would prefer not to patch the KNS. I have attached a Rice patch though for convenience for anyone who wants to patch their own server with the equivalent of your code. If there is a deeper problem, then we can of course look at it.

          KRAD handles this situation a lot better. With everything having a view and every view having an associated authorizer, then the authorizer is just called without having to add extra code to determine what that authorizer is. Really, the call to authorizer.isAuthorizedByTemplate(..) eventually calls the PermissionService anyway, only after adding some extra role and permission stuff, which is exactly what you are aiming for here.

          Show
          Kristina Taylor (Inactive) added a comment - If KFS has already patched and tested it, then we would prefer not to patch the KNS. I have attached a Rice patch though for convenience for anyone who wants to patch their own server with the equivalent of your code. If there is a deeper problem, then we can of course look at it. KRAD handles this situation a lot better. With everything having a view and every view having an associated authorizer, then the authorizer is just called without having to add extra code to determine what that authorizer is. Really, the call to authorizer.isAuthorizedByTemplate(..) eventually calls the PermissionService anyway, only after adding some extra role and permission stuff, which is exactly what you are aiming for here.
          Hide
          James Smith added a comment -

          I think the concern was going forward with KRAD, so the reassurance that KRAD fixes these issues is great. Thanks!

          Show
          James Smith added a comment - I think the concern was going forward with KRAD, so the reassurance that KRAD fixes these issues is great. Thanks!

            People

            • Assignee:
              Kristina Taylor (Inactive)
              Reporter:
              James Smith
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 day
                1d
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours Time Not Required
                2h

                  Agile

                    Structure Helper Panel