Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 1.0
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-13515create local Rice environment
      KULRICE-2315Implement caching of data to the IdentityManagementService implementation
      KULRICE-13327IT Failure PostProcessorTest in CI, passes locally
      KULRICE-13612revise/simplify local Rice install guide
      KULRICE-9285AccountManagerMaintenanceDocumentTest fails with NPE locally and in CI with unable to get class for unknown documentTypeName 'AccountManagerMaintenanceDocument'
      KULRICE-13671Create local testing environment
      KULRICE-7258Implement caching on ExtensionRepositoryService
      KULRICE-7354Standalone server is attempting to load remotable attributes locally
      KULRICE-6885Rice Dev2: Error with user cache?
      KULRICE-7533KualiPropertyMessageResources does not cache messages
    • Rice Module:
      KIM
    • Application Requirement:
      KFS, KC, KS, Rice

      Description

      We can not assume that potentially external identity management systems will forever provide all users that ever existed to the system. As such, the PersonService (which is the contact point for all user lookups and references) must cache data retrieved from the external IdM system locally within Rice so that, if a user is deleted externally, references to that principalId that may exist within workflow and other database tables can still be resolved.

      Create KR_KIM_PERSON_CACHE_T. Add a column for each main data element on the Person interface that does not represent a derived value. The table will be keyed by principal ID and also have a timestamp as to the last

      Update the person service to attempt to pull person information from the IdentityManagementService. But, if not there, pull from the cache and populate a PersonImpl object. However, if the user was found in the IdM, then the record in the database would be updated.

      Roles and groups do not need to be cached. If they are not in the IdM system, we can assume that they no longer have any permissions.

      Another possibility is for the PersonService to be given a refresh period before which it will pull a given person from the cache instead of calling the IdM service. This would require an in-memory cache of principal ID->load time mappings. (This could have a WeakReference to the actual PersonImpl object instead.)

      The above may be necessary to prevent updating of the cache table upon every request for a person.

        Activity

        Hide
        Nate Johnson (Inactive) added a comment -

        Are you sure we don't need to cache at least roles? At least in terms of workflow once you can route to roles... for auditing purposes?

        Show
        Nate Johnson (Inactive) added a comment - Are you sure we don't need to cache at least roles? At least in terms of workflow once you can route to roles... for auditing purposes?
        Hide
        Jonathan Keller added a comment -

        Not in the context that I understood. It was mainly so that people's names didn't disappear off the documents if they left the institution. I think we can assume that this kind of "disappearance" would only occur quite a while after any work they performed.

        Show
        Jonathan Keller added a comment - Not in the context that I understood. It was mainly so that people's names didn't disappear off the documents if they left the institution. I think we can assume that this kind of "disappearance" would only occur quite a while after any work they performed.
        Hide
        Ailish Byrne added a comment -

        i'd like to think more about this and discuss with eric before proceeding in terms of route log impacts

        Show
        Ailish Byrne added a comment - i'd like to think more about this and discuss with eric before proceeding in terms of route log impacts
        Hide
        Jonathan Keller added a comment -

        This was done as part of another JIRA.

        Show
        Jonathan Keller added a comment - This was done as part of another JIRA.
        Hide
        Eric Westfall added a comment -

        Bulk change of all Rice 1.0 issues to closed after public release.

        Show
        Eric Westfall added a comment - Bulk change of all Rice 1.0 issues to closed after public release.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel