Details

    • Type: Improvement
    • Status: Open
    • Priority: 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)
    • 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

        Attachments

          Activity

          Hide
          jkeller 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
          jkeller 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
          jkeller 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
          jkeller 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
          jcoltrin 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
          jcoltrin 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:
              jkeller Jonathan Keller
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: