Skip navigation
Currently Being Moderated

Removing signatures in a digital signature field

Jul 8, 2009 8:21 AM

Hi all, I have a question relating to the topic above that i hope
you guys can help me with;

 

1) Is it possible to remove digital signatures from form? For instance
if you have a form going thru several approval steps that requires
signatures, and then one step happened to reject, it would be nice to
remove the previous signatures so that they could be re-signed.

 

2) And finally is there a simpler way to combine digital signatures
and rights management then what was listed in the pdf provided by
Duane (second post from the bottom of the thread)? When creating a policy there is

a checkbox for "Filling in form fields and signing". Is this forsomething else?

 

Thanks!
Billy 

 
Replies
  • Currently Being Moderated
    Jul 8, 2009 9:02 AM   in reply to bilimam

    1)  Is it possible to remove digital signatures from form?

    ANSWER:  A signature can only be removed ("unsigned") if the system or user has access to the "private" key used to generate the signature in the first place.  For example, let's say User A signs a PDF... Only User A can unsign that PDF.  If you were to use LC Digital Signatures ES to "unsign" a PDF, you would need to have all of the potential user "Credentials" and Credential passwords stored in the Trust Store so LC would have access to the private keys to be able to unsign a signature field.  This is not very feasable if the number of potential signers is large.

     

    2) Is there a simpler way to combine digital signatures and rights management

    ANSWER: Combining Digital Signature and Rights Management is not complicated.  You just need to be aware of the "Order of Operations" required.  Always "Encrypt" first (Rights Mgt, Certificates, and Password can be used for encryption) then "Certify" (assuming you are Certifying the PDF), then add Reader Extension rights (assuming you want to extend functionality of the document for Reader)

     

    The reason the above order is required...  When you sign a document, a hash is generated based on the document, if you then encrypt that signed document, you are modifying the document which in turn causes a different hash to be generated... this breaks the signature.

     

    As for the "Filling in form fields and signing" option in a policy, this is a "permission" that you can allow or disallow for PDF forms with a policy applied by RM.  For example, A PDF has a policy applied where User A has the "Filling in form fields and signing" permission enabled andf User B does not.  User A can open the form and interact with it by filling it in and or sign the form.  User B would only be able to "view" the form.  This permission is only relevant what using RM to protect fillable PDF forms.  Also, it shouldn't be confused with the Reader Extensions permission of allowing Digital Signatures in Reader.

     

    For example, If you wanted a "Certified" form to be filled in and signed by User A with Adobe Reader, you would need to:

     

    Apply a policy to the PDF where User A had the "Filling in form fields and signing" permission enabled, then apply a "Certify" signature which had the "Allow Form Fill and Signing" permission enabled, then Reader Extend the PDF form that enables the "Digital Signatures" permission which activates the Digfital Signatures functionality in Reader for that particular form.

     

    It may sound complicated, but it really isn't

     

    Regards

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 17, 2009 8:25 AM   in reply to bilimam

    Billy

     

    You don't need\want to Remove the policy to be able to sign the document.  Use the "Unlock Policy Protected PDF" operation, this temporarily decrypts the document so you can work with it (i.e. sign it).  When the work is done the PDF remains protected with the policy.  "Remove Policy" does just that, it removes the encryption.  You would nned to then reapply the policy to get the encryption back, which is problamatic in your case as the document will be signed, therefore you will not be able to apply a policy to it.

     

    There are a couple of things that you need to know for this to work...

     

    1)  The process that contains the "Unlock Policy Protected PDF" operation must be "Short-Lived"  Typically you would create a seperate process to do this and call is as a subprocess from the main one

     

    2)  The process that contains the "Unlock Policy Protected PDF" operation must be executed in the *context of a user or account that has permissions to view the document (the user is a member of the policy)

     

    * to set this, access the Admin UI and set the "Run As" property (Home > Services > Application and Services > Service Management > you service name > Security (tab)

     

     

    As for your variable type, you can use a "document" variable if you are dealing with a PDF.  The type "Document Form" is used to hold PDFs that are loaded into the Workspace application that is part of the Process Management ES solution component.

     

    Regards

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 17, 2009 10:38 AM   in reply to bilimam

    Billy

     

    Could you explain how the document becomes encrypted afterwards? If this temporarily decrypts the document, does it mean that it automatically puts the encryption back on?

    ANSWER:  Basically, the document or parts of it is "decrypted" and stored in memory.  The encryption is automatically re-applied by RM when the process is complete.

     

    The process that contains the "Unlock Policy Protected PDF" operation must be executed in the *context of a user or account that has permissions to view the document (the user is a member of the policy)

     

    Would system be good enough for this?

    ANSWER:  You cannot use the system context for the Unlock Policy Protected PDF operation as there is no way to add "System" as a user to the policy.  This is the reason that the "Run As" functionality was introduced in LiveCycle ES Update 1 (ver 8.2x)

     

    The type "Document Form" is used to hold PDFs that are loaded into the Workspace application that is part of the Process Management ES solution >component

     

    Which is what i'm trying to do, so i'm guessing i use the setvalue to convert the Document Form to document, and vice versa?

    ANSWER:  You can access the "document" (PDF) stored in a Document Form variable by using XPath.  Use the XPath builder to navigate to the document, i.e.  /process_data/DocumentFormVariableNameHere/object/@document  You could map this into a document variable, but you shouldn't have to.

     

     

    Regards

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 17, 2009 12:52 PM   in reply to bilimam

    Billy

     

    Is sounds like you have everything configured correctly... but it would work if everything was correct!  The error you are getting typically means that the user attempting to open the PDF is not included as a member in the policy.

     

    1)  Can you open the PDF manually in Reader or Acrobat using the same user you have set as the "Run As" account?

     

    2)  Is the user who is the Policy Set Coordinator also a member of the policy that is applied to the PDF you are testing with?

     

    The user account that is specified in the "Run As" setting must be a member of the policy that was applied to the PDF that you are using.

     

    Regards

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 20, 2009 6:59 AM   in reply to bilimam

    Billy

     

    Can you post a screen shot of the "Security" tab and the settings for your service that you created to unlock the PDF?  Also, if possible could you export your process and post it as well?

     

    Thanks

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 20, 2009 9:39 AM   in reply to bilimam

    The LCA file did not make it.  Rename the file with a .TXT extension so it will not be blocked.

     

    Thanks

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 20, 2009 11:28 AM   in reply to bilimam

    The screen shots look like the correct configuration.  I made a few changes\corrections to your "RemovePolicyAndClearSignature" process, tested and got it working on my system.  I attached the new version.  By the way, prior to making the changes, I tested and duplicate your coercion error, it was caused by the fact that your "list" variabe had a subtype of document, you were trying to put an object of type "PDFSignatureField" into a "document" variable, therefore the corecion error.

     

    Changes I made included:

     

    1)  Changing the "sigLst" variable to have a subtype of "PDFSignatureField"  (You had used "document")

    2)  Created a variabe of type PDFSignatureField, named "objSignatureField"

    3)  Added a "Set Value" step to map the "PDFSignatureField" object from the "sigLst" variable into the "objSignatureField" variable, and a second mapping to map the "name" attribute of the "objSignatureField" (which hold the PDFSignatureField") into the "signatureName" variable of type string

     

    I set the service security to "RunAs" a named user, this named user was a member of the policy, and had "Modify" permissions.  I invoked the process from Workbench and was able to see that the resulting PDF file had the signature cleared from the field.

     

    Hope this helps.

     

    Regards

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 20, 2009 12:42 PM   in reply to bilimam

    Policy Set and Policies do not come across as part of an LCA (neither do trust Store settings either)

     

    I created my own test policy and did not get the "No View Permission" error.  Can you test the process I posted (invoke from Workbench, with the "Run As" set to your user) with your policy and document to see if you get the error.

     

    Regards

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 21, 2009 6:00 AM   in reply to bilimam

    I'll take a look at your other processes.  I'll let you know what I find shortly.

     

    Are you using "Record and Playback"?  What step in the process is causing the Not Serializable error?

     

    Regards

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 21, 2009 11:05 AM   in reply to bilimam

    Billy

     

    I tested everything again (including your render service, and your Expense process), ands was able to run the process(es) successfully, with no errors.

     

    I did however create my own policy set and policy which I set in your render service.

     

    On your end, it has to be an issue between the policy and the user that you are defining as the "Run As" account.

     

    Can you now post a screen shot of the Policy configuration, including the specific permission details for the user "glennj".

     

    Regards

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 22, 2009 7:55 AM   in reply to bilimam

    Billy

     

    I was actually looking for the specific permissions for "glennj"... see attached screen shot for the screen I was referring to.  The user in the screen shot is the account I use to run the "RemovePolicyandClearSignature" process.

     

    Make sure the "glennj" user has the "Modify" permission eanbled.

     

    Thanks

    Steve

    Attachments:
     
    |
    Mark as:
  • Currently Being Moderated
    Jul 22, 2009 9:45 AM   in reply to bilimam

    Billy

     

    The "collaborate" permission is a subset of the "Modifiy" permission.  If "Modify" is enabled, "collaborate" will also be enabled.

     

    I'm not sure why you are experiencing the error still.  As I have stated before, everything looks ok, and I am able to get it to work in my environment.

     

    At this point, a few things I would try are:

     

    Test with a different\new policy and policy set

    Create a new user that will be used exclusively as the "Run As" account

    Recreate the "RemovePolicyAndClearSignature" process from scratch and test it with your other processes

     

    Regards

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 23, 2009 12:06 PM   in reply to bilimam

    Billy

     

    Does the user "glennj" happen to exist in both domains (DefaultDom and the one you were using previously)?

     

    Steve

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 23, 2009 12:32 PM   in reply to bilimam

    Billy

     

    A user can be in multiple "groups" in that same domain, but a user should not be duplicated in multiple "domains"  If a user is duplicated across domains, LiveCycle will simply find the first instance one and stop looking.

     

    I'm not aware of any restrictions around minimum number of characters etc...

     

    Steve

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points