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

Person maintenance document encrypts the encrypted tax ID value when user can't see it

    Details

    • Similar issues:
      KULRICE-3193KFS Maintenance & Infrastructure Tax ID is not encrypted in KRIM_PERSON_DOCUMENT_T
      KULRICE-3366Cannot encrypt TAX ID with post-encrypt job
      KULRICE-7688Decrypting/Encrypting hide fields value that are not set as encrypted when click on custom button on Maintenance Document
      KULRICE-7667Decrypting/Encrypting hide fields value that are not set as encrypted when click on custom button on Maintenance Document
      KULRICE-3111Person lookups by external identifier do not work when identifier is encrypted
      KULRICE-9076Fix Criteria Masking on Lookups with encrypted fields
      KULRICE-8412Fields encrypted on URL are not always decrypted when returned to document
      KULRICE-8299Create UI for encrypting/decrypting document content
    • Rice Module:
      KIM
    • Application Requirement:
      KFS

      Description

      The person document is not handling encrypted external identifiers correctly when the user does not have the ability to see the value. (I'm assuming that's the only case.)

      In these cases, the value which gets written to the database is the encrypted value of the already encrypted string. See an example on the linked KFS issue.

      The document needs to avoid setting the value on the external identifier Impl class to the encrypted string value, since the encryption should be handled in the @PrePersist method.

        Issue Links

          Activity

          Hide
          Jeremy Hanson added a comment -

          The problem is that KimEntityExternalIdentifierImpl overrides both beforeUpdate methods from PersistableBusinessObjectBase, each time calling the super method, and then encrypting the id. The problem is that in PersistableBusinessObjectBase, the beforeUpdate(PersistenceBroker persistenceBroker) method, which calls the beforeUpdate method.

          So when we overrode beforeUpdate(PersistenceBroker persistenceBroker) and called the super method, then encrypted, it calls the new beforeUpdate() method and encrypts, then when that value returns, it encrypts it a second time. I think the easiest way to fix this is to change KimEntityExternalIdentifierImpl's beforeUpdate(PersistenceBroker persistenceBroker) method to just call it's own beforeUpdate method instead of calling the super method.

          Show
          Jeremy Hanson added a comment - The problem is that KimEntityExternalIdentifierImpl overrides both beforeUpdate methods from PersistableBusinessObjectBase, each time calling the super method, and then encrypting the id. The problem is that in PersistableBusinessObjectBase, the beforeUpdate(PersistenceBroker persistenceBroker) method, which calls the beforeUpdate method. So when we overrode beforeUpdate(PersistenceBroker persistenceBroker) and called the super method, then encrypted, it calls the new beforeUpdate() method and encrypts, then when that value returns, it encrypts it a second time. I think the easiest way to fix this is to change KimEntityExternalIdentifierImpl's beforeUpdate(PersistenceBroker persistenceBroker) method to just call it's own beforeUpdate method instead of calling the super method.
          Hide
          Jeremy Hanson added a comment -

          Is there any reason to do the encrypting/decrypting on both the identityManagementPersonDocument and the KimEntityExternalIdentifierImpl?

          Show
          Jeremy Hanson added a comment - Is there any reason to do the encrypting/decrypting on both the identityManagementPersonDocument and the KimEntityExternalIdentifierImpl?
          Hide
          Jonathan Keller added a comment -

          On the before Update methods: sounds good to me

          On the encrypting in the identityManagementPersonDocument: Yes. It needs to encrypt it before putting it into the pending tables used by that document.

          Show
          Jonathan Keller added a comment - On the before Update methods: sounds good to me On the encrypting in the identityManagementPersonDocument: Yes. It needs to encrypt it before putting it into the pending tables used by that document.
          Hide
          Jeremy Hanson added a comment -

          changed the beforeUpdate methods and things seem to have cleared up. I also modified a unit tests so it does an update in addition to the insert so this code is tested.

          Show
          Jeremy Hanson added a comment - changed the beforeUpdate methods and things seem to have cleared up. I also modified a unit tests so it does an update in addition to the insert so this code is tested.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel