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

Fields encrypted on URL are not always decrypted when returned to document

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.3
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      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-4782forceUppercase and encrypted PK fields are not compatible - unable to perform inquiry
      KULRICE-7947Add methods to EncryptionService interface to support encryption and decryption of streams
      KULRICE-8299Create UI for encrypting/decrypting document content
      KULRICE-4892Document Operation screen in workflow doesn't display XML properly if it's encrypted with a different encryption key then the standalone server uses
      KULRICE-12328When accessing krew_doc_hdr_cntnt_t content, don't decrypt if content seems like uncrypted xml
      KULRICE-9076Fix Criteria Masking on Lookups with encrypted fields
      KULRICE-12808Context ID field is always editable
      KULRICE-2941When Javascript is disabled, the methodToCall is not always properly discovered.
    • Rice Module:
      KNS, KRAD
    • KRAD Feature Area:
      Lookup
    • Application Requirement:
      KFS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Pending Review

      Description

      If a field which needs to be encrypted on the URL is passed back to a document which does not specify it as masked, the value of the field is not decrypted.

      The check in the baseline Rice code should check if the source encrypted the value so it can be returned properly.

      (This is aside from the fact that it probably should be marked as masked on the target, since it's a sensitive field.)

        Issue Links

          Activity

          Hide
          Steve Manning (Inactive) added a comment -

          Jonathan, is there an example of this on a KFS document that you could provide me with? It would be helpful, thanks.

          Show
          Steve Manning (Inactive) added a comment - Jonathan, is there an example of this on a KFS document that you could provide me with? It would be helpful, thanks.
          Hide
          Jonathan Keller added a comment -

          No - This was not a situation I encountered with KFS, but with the UCD implementation of KFS. (It's why there is no project dependency on this JIRA.)

          But, the scenario is:

          Create a BO (ReferenceBo) with some field which is masked via the DD:

               <property name="attributeSecurity">
          		<bean parent="AttributeSecurity">
            			<property name="mask" value="true" /> 
          			<property name="maskFormatter">
            			<bean parent="MaskFormatterLiteral" p:literal="*********" /> 
            			</property>
            		</bean>
            	</property>
          

          From another BO (ParentBo), define a property which relates to the PK of the ReferenceBo with that masked property. (So that a quickfinder will be created.)
          Add an unmasked property on the ParentBo which is the same as the masked property, but without the mask security.
          Override the fieldConversions on the lookup from ParentBo to ReferenceBo so that the maskedProperty is included in the return.

          Perform the lookup from the ParentBo to the ReferenceBo and return a value. The value placed into the ParentBo's field will not be decrypted, since the attribute is not defined as needing to be masked on the ParentBo.

          This should be easy to replicate by making some common property on existing business objects masked. (NamespaceBo?) and then using a lookup against it.

          Show
          Jonathan Keller added a comment - No - This was not a situation I encountered with KFS, but with the UCD implementation of KFS. (It's why there is no project dependency on this JIRA.) But, the scenario is: Create a BO (ReferenceBo) with some field which is masked via the DD: <property name= "attributeSecurity" > <bean parent= "AttributeSecurity" > <property name= "mask" value= " true " /> <property name= "maskFormatter" > <bean parent= "MaskFormatterLiteral" p:literal= "*********" /> </property> </bean> </property> From another BO (ParentBo), define a property which relates to the PK of the ReferenceBo with that masked property. (So that a quickfinder will be created.) Add an unmasked property on the ParentBo which is the same as the masked property, but without the mask security. Override the fieldConversions on the lookup from ParentBo to ReferenceBo so that the maskedProperty is included in the return. Perform the lookup from the ParentBo to the ReferenceBo and return a value. The value placed into the ParentBo's field will not be decrypted, since the attribute is not defined as needing to be masked on the ParentBo. This should be easy to replicate by making some common property on existing business objects masked. (NamespaceBo?) and then using a lookup against it.
          Hide
          Steve Manning (Inactive) added a comment -

          So, I believe that I'm able to replicate this, but wanted to make sure that I was taking into account all factors. When you were seeing this undesirable behavior at UCD was it with a field that was simply masked? Or was the field masked and the data stored encrypted in the DB?

          Show
          Steve Manning (Inactive) added a comment - So, I believe that I'm able to replicate this, but wanted to make sure that I was taking into account all factors. When you were seeing this undesirable behavior at UCD was it with a field that was simply masked? Or was the field masked and the data stored encrypted in the DB?
          Hide
          Jonathan Keller added a comment -

          Yes, both. It was a bank account number. So the DB had it encrypted as well. But the encryption-on-the-URL should apply any time the value is being hidden or masked per the attributeSecurity settings.

          Show
          Jonathan Keller added a comment - Yes, both. It was a bank account number. So the DB had it encrypted as well. But the encryption-on-the-URL should apply any time the value is being hidden or masked per the attributeSecurity settings.
          Hide
          Steve Manning (Inactive) added a comment -

          Jonathan, did you find that having a mask defined for the field on the document (and the required associated permissions defined as well) resulted in the value being decrypted successfully? I've been working with the UnitOfMeasure business object, and accessing from the RequisitionDocument. I'm finding that even with the mask defined on the RequisitonDocument, the value is still returned as encrypted and wanted to verify that this was indeed the expected behavior.

          Show
          Steve Manning (Inactive) added a comment - Jonathan, did you find that having a mask defined for the field on the document (and the required associated permissions defined as well) resulted in the value being decrypted successfully? I've been working with the UnitOfMeasure business object, and accessing from the RequisitionDocument. I'm finding that even with the mask defined on the RequisitonDocument, the value is still returned as encrypted and wanted to verify that this was indeed the expected behavior.
          Hide
          Jonathan Keller added a comment -

          No. I was looking into the code to see what would make it decrypt and found that it was only decrypted if the target field had a setting on it which would require URL encryption. I never verified through testing that it actually would work that way.

          But, the expected behavior would be that the field is always decrypted before being set on the target BO. Then, it would be the target BO's concern as whether to mask the field.

          Show
          Jonathan Keller added a comment - No. I was looking into the code to see what would make it decrypt and found that it was only decrypted if the target field had a setting on it which would require URL encryption. I never verified through testing that it actually would work that way. But, the expected behavior would be that the field is always decrypted before being set on the target BO. Then, it would be the target BO's concern as whether to mask the field.
          Hide
          Peter Giles (Inactive) added a comment -

          I just noticed that this issue is flagged for KTI review. Jonathan, are you going to take this one up with that group?

          Show
          Peter Giles (Inactive) added a comment - I just noticed that this issue is flagged for KTI review. Jonathan, are you going to take this one up with that group?

            People

            • Assignee:
              Steve Manning (Inactive)
              Reporter:
              Jonathan Keller
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel