Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0, 2.0.1, 2.0.2
    • Fix Version/s: 2.6
    • Component/s: Development, Performance
    • Security Level: Public (Public: Anyone can view)
    • Similar issues:
      KULRICE-2673Optimize the RuleService.getDuplicateRuleId check
      KULRICE-6463New DB Indexes for KIM Permission checks
      KULRICE-2354KIM Permission Service Test
      KULRICE-3717Optimize the checking of getValidActions
      KULRICE-2531Modify htmlControlAttribute to check KIM permissions
      KULRICE-2264Refactor Rice to use the KIM permission model for authorization checks
      KULRICE-8844KualiDocumentFormBase permission checks are more expensive than they have to be
      KULRICE-3946Check KIM relationships for lazy loading
      KULRICE-3422Reduce KIM logging output amount, set default log levels so permission checks are not logged
      KULRICE-8268broker pool optimization (4067)
    • Epic Link:
    • Rice Module:
      KIM
    • Application Requirement:
      KFS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      1) Permission checks are expensive.
      2) The KNS/KRAD perform lots of permission checked.
      3) Not all permissions vary from call to call.
      4) KIM doesn't really know which permission checks are safe to cache.

      For example, items like initiate document (which only takes a document type as a qualifier), do not change unless there is a permission assignment change or a role membership change. So, in general, that would be safe to cache for a period of time.

      I was hoping to cover this up within the the document authorizer framework in KFS, but watching the locations of the KIM calls shows that a number of the permission checks come from KIM itself. (It's resolving those roles which are based on permissions.)

      So, I would like to propose that a method be added to the permission type service. (role type service as well?) This method would identify the set of qualifier names which should be used (along with the principal ID) to build the cache key. (Returning a null would indicate that it is not safe to cache results of these permission checks.)

      Examples:
      Initiate Document: documentTypeName
      Use Screen: actionClass
      Unrestricted Document Search: (empty list - it has no qualifiers)
      Open/Edit Document: documentTypeName, routeNodeName, routeStatusCode, documentNumber

        Activity

        Hide
        Jonathan Keller added a comment -

        Has something changed in recent builds? I just updated Rice again and am not seeing the same number of checks which prompted me to file this JIRA.

        Show
        Jonathan Keller added a comment - Has something changed in recent builds? I just updated Rice again and am not seeing the same number of checks which prompted me to file this JIRA.
        Hide
        Jonathan Keller added a comment -

        BTW - I'm testing a hack to the document authorizer/document framework to store certain standard checks (canEdit/canCopy/etc...) in the document object itself (keyed by principal ID) so that it can be reused by the document authorizer. The document object survives across page invocations, and is only in the user's session, so it seems like it could work.

        (It doesn't remove them all - since some of the checks are that nested check from within the Role service.)

        Show
        Jonathan Keller added a comment - BTW - I'm testing a hack to the document authorizer/document framework to store certain standard checks (canEdit/canCopy/etc...) in the document object itself (keyed by principal ID) so that it can be reused by the document authorizer. The document object survives across page invocations, and is only in the user's session, so it seems like it could work. (It doesn't remove them all - since some of the checks are that nested check from within the Role service.)
        Hide
        Jessica Coltrin (Inactive) added a comment - - edited

        setting to 2.2-backlog since it's an Improvement, but would nice to get into a release. 2.2 is the next release where we can add improvements.

        Show
        Jessica Coltrin (Inactive) added a comment - - edited setting to 2.2-backlog since it's an Improvement, but would nice to get into a release. 2.2 is the next release where we can add improvements.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jonathan Keller
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Structure Helper Panel