I am working on a project which needs multiple users of the application to sign a document with docusign.
I was working with the JAVA quickstart project and tried to retrieve a document after signing using the download document example (7th one on the page )in the quickstart.
The document was sent via the bulk signature example and I signed it through two of my e-mail accounts. I hardcoded the document id and the envelope id in the
code as the quickstart by default only lets you view a document created through example 2. The document does get downloaded but I cannot see the signatures on it.
Secondly, when I signed the document from the two accounts, I signed it from both in the same place to see how it will get handled.
Lastly I see the option to place the signature widget by the signer only in the bulk signature example, can this be enabled for any signature request ?(This may be there somewhere in
the documentation but i could not find it anywhere)
In general, there is very little clarity on how multiple signatures are handled in docusign (How the widget is placed, who can place them, how they are finally visible on the document when the document
is completled, and when signatures are being done in some order, then do the succeeeding signers see the signatures of the preceeding ones), will greatly appreicate any help on this.
Regards,
ANur
Signatures are placed in documents using Tabs. In the Java Quickstart there are a few helper functions that add the tabs to the documents. You can find those functions in this file. When you're dealing with multiple signers you need to make sure that the tabs are associated with the correct recipients. If you download the document using example 7 before the document has been signed it won't have the signature fields on it but after it has been signed you should see the signatures there. I don't think DocuSign will prevent the two signers from placing their signatures in the same location but you can prevent that by specifying the locations of the SignHere tabs so that they do not overlap.
For more on placing tabs in documents you can check out this blog post.
Related
I am trying to understand and implement a solution based on European Commission-sponsored Digital Signature Service project. I currently have succeeded in using the abstraction provided by the DSS-DEMO application, mentioned in the aforementioned github link, with the help of Nowina NexU client software. My wish is to digitally sign a PDF document with the following configuration:
no container
PAdES signature form
enveloped
PAdES_BASELINE_LT signature level
SHA256 digest algorithm
I want the signature to have a visible part, i.e. to be seen on the first page of the document. This is somewhat demonstrated here. Personally, I need the actual signing timestamp and the name of the signer from her certificate. In the above demonstration this is done by providing "parameters" to the signing function.
I also want to fill the Reason field of the signature - it is then subsequently displayed when you view the Signature properties with a program like Adobe Acrobat Reader.
My problems so far are the following, and I can't seem to find neither examples nor other sort of information about them.
If I want to display the signing timestamp that I would get from a Timestamp Authority service, how would I get it, since the communication with the timestamp server is done during the signing process, i.e. after specifying the parameters as I mention above. I guess I have to dig into DSS code and do all the steps done there for me myself.
Currently, a strange thing happens. It appears that the signatures are deemed valid, or at least UNKNOWN, when I specify a hardcoded Reason (like 'testtest'), or no Reason at all. When I fill it from results of something else, the signature is not valid. Because things like this don't usually happen by magic, I must be doing something awfully wrong.
The code is organized approximately like this - there's a REST communication between two machines - a server and a client with NexU installed. NexU does all the communication with the smart card or any other certificate store on the client machine - it exchanges the digest value and the signed digest value with the server. There are, among others, two specific phases in the server code :
getDataToSign - here a digest is calculated from the PDF content
signDocument - here the actual signing - (embedding of the signature into the document, i guess?) takes place.
I am giving to both these phases a host of parameters, that, among other things, specify the signing timestamp, the Reason, and the visual parameters of the text I want to appear on the first page. I am doing this with the same parameters for both of the phases (because I am not sure on which phase I should give which)
My signing date - isn't it logical for it to be as close to the timestamp authority server's timestamp as can be? Okay - I am setting it to the current timestamp of my own server at the time of the beginning of the signing process.
I am setting Reason using PAdESSignatureParameters.setReason.
Any helpful insight is appreciated - thanks.
I have solved the weird issue with the Reason field of the Signature.
I don't seem to see any way around the Signing Date being different from the Timestamping Authority-provided Timestamp.
Explanation follows.
As far as the first case, it was my fault. To elaborate, following my understanding, the signature parameters are provided to the DSS methods two times using SigningService.fillParameters() method.
in SigningService.getDataToSign(...) and then
in SigningService.signDocument(...)
This is important to be done in both methods, because during the first time, the hash/digest of the document-to-be-signed is calculated. Since I have chosen the signature to be enveloped, i.e. to be contained within the document that is going to be signed, we need to first apply the signature, and then calculate the digest basing on that "final" document.
As far as I saw in the DSS code (approximately), the in-memory representation of the uploaded PDF is signed, and its digest is calculated, during getDataToSign - but the outcome is discarded.
During the actual signDocument method (in between, the digest has travelled back to the client with NexU installed, and returned back to the server signed), the uploaded PDF is signed again, its digest calculated again, but this time the actual signed digest (we got from the client) is also applied to the document - and the in-memory outcome of this operation is sent back to the client as a signed PDF document.
What I was doing wrong is that during the first time, I was losing the variable that I was going to add as the Reason (it was lost somewhere in the model attributes - i was not passing it somewhere in between requests), with the result of my first map of parameters passed to getDataToSign differing from the second map of parameters - so it is only logical, that the actual hash/digest of the document was different from the digest in the saved signature (because at the time the digest-to-be-signed was calculated, i wasn't passing the Reason). That's why when I was passing a hardcoded value, because it was hardcoded, it was present during both calls to fillParameters. It was such a stupid mistake, I know. I should have known this because there was absolutely nothing about any difficulties with passing Reason (or other fields like Location) to the Signature.
BTW the signing is done using Apache PDFBox, and it is done incrementally.
As for the second thing, we decided to leave it as it is, although there is a comparatively impressive gap between the signing timestamp and the timestamp authority one. I don't really know what should be the allowed gaps in cases like this. I guess that this happens because
My server might have a slightly off-normal local time
Because the whole process of signing is going on between two machines (server and client with NexU installed, as well as the smart card), and because there are different dialog windows appearing asking for password etc. - it all postpones the actual signing and the call to the timestamping authority is done during the very last step. Of course, I am not sure if it is an issue, since theoretically timestamping authority doesn't know about the actual contents being changed - the previous error would have been triggered in that case..
That's more like it - of course I am open to other comments and answers. Thank you!
I am able to extract text from PDF's which doesn't have any security restrictions. I just want to know if it is possible to extract text from PDF which has restrictions
UPDATE:
Thanks to all for your comments. I appreciate your concern. Please understand the question. I did not ask how to do it. I just want to know if it is possible. I have created a PDF with these restrictions. I do not want my information to be extracted from my document. There are many developers who can achieve any task. I want to know if this task can be done. If this can be done, then I will investigate further to overcome this issue.
As the OP clarified that he asked the question to know whether his documents with such restrictions are safe from text extraction, and that he does not ask how to do it (in spite of the explicit languages and libraries given in tags), here an answer on the principle option, not a concrete implementation. Thus...
Yes, it is possible to extract text from documents with restrictions as long as the document can be read at all and no other means are applied to prevent text extraction.
The restrictions you show merely are flags that indicate to a PDF processor what the author wants to allow or not to allow a user to do with his document but they are not technical restrictions.
These restrictions can only be applied to encrypted documents, but you surely want these restrictions to work in particular for anyone (other than you) who can open the document for reading, be it by knowing a specific user password or be it by using the empty password.
Cf. the specification ISO 32000 (here from part 2, similarly in part 1 with a focus on PDF viewers):
If a user attempts to open an encrypted document that has a user password, the PDF reader shall first try to authenticate the encrypted document using the padding string defined in 7.6.4.3, "File encryption key algorithm" (default user password):
If this authentication attempt is successful, the PDF reader may open, decrypt, render and otherwise provide access to the document.
If this authentication attempt fails, the interactive PDF processor should prompt for a password. Correctly supplying either password (owner or user password) should enable the user to gain access to the document.
Whether additional operations shall be allowed on a decrypted document depends on which password (if any) was supplied when the document was opened and on any access restrictions that were specified when the document was created:
Opening the document with the correct owner password should allow full (owner) access to the document. This unlimited access includes the ability to change the document’s passwords and access permissions.
Opening the document with the correct user password (or opening a document with the default password) should allow additional operations to be performed according to the user access permissions specified in the document’s encryption dictionary.
Access permissions shall be specified in the form of flags corresponding to the various operations and the set of operations to which they correspond shall depend on the security handler’s revision number (also stored in the encryption dictionary).
...
Once the document has been opened and decrypted successfully, a PDF reader technically has access to the entire contents of the document. There is nothing inherent in PDF encryption that enforces the document permissions specified in the encryption dictionary. PDF readers shall respect the intent of the document creator by restricting user access to an encrypted PDF file according to the permissions contained in the file.
(ISO 32000-2 section 7.6.4 Standard Security Handler)
Thus, these restrictions only work in cooperating PDF processors, but in particular in case of open source PDF libraries, it is trivial for a programmer to remove any code trying to enforce the restrictions.
Being aware of this, the developers of open source PDF libraries usually don't try to enforce the restrictions at all, or they add some flag to override restriction enforcement to prevent patched copies of the library to circulate.
I am looking for a way to resolve multiple signatures on a document, so I got a couple of questions of what I can do and what I cannot.
First, since multiple signatures from different people can be added to the document, the position of the signatures is important due to aesthetics and document printing if needed. Having said this, I would like to know an approach to handle this. What I was thinking was adding/append an additional page at the end of the documents and assign to it some kind of identifier like "doc_signatures", so when the second person opens the document for signature, it detects it already has a "doc_signatures" page created, and just add the signature and save the document using the increment option in PDFBox. Is this a good approach? If it is, is there a way to identify the "doc_signatures" page so I don't append it again.
Also, can I add like signature fields to that "doc_signatures" page, with a position each one, so when I open the PDF, I detect it has "doc_signatures" already created and that it already has a signature on that page on "Field 1"(with its own X,Y coordinates) so place the second signature on "Field 2" on "doc_signatures" page and "Field 3" for the third signature, and also some type of limmit of the amount of signatures on the document?
I would appreciate if this is a acceptable approach and if it is not, is there any recommendation or something I can do to accomplish this? I would appreciate any other approach or logic for this that can be implemented using PDFBox. Regards everyone.
As you ask this question in general (not PDFBox specific) terms, I'll start by answering similarly. PDFBox is versatile enough to implement the concepts in question.
First, since multiple signatures from different people can be added to the document, the position of the signatures is important due to aesthetics and document printing if needed. Having said this, I would like to know an approach to handle this. What I was thinking was adding/append an additional page at the end of the documents and assign to it some kind of identifier like "doc_signatures", so when the second person opens the document for signature, it detects it already has a "doc_signatures" page created, and just add the signature and save the document using the increment option in PDFBox. Is this a good approach?
Whether this is a good approach or not depends on the nature of the documents to be signed and your influence on the pre-signing workflow of the document.
Paper documents often have dedicated positions for signatures of persons in a specific role. If you are buying something and as part of the sales contract acknowledge receipt, your signature has to clearly also sign the receipt part while the signature of the vendor needs not.
In digital PDF signatures you can alternatively make this clear by means of the Reason entry of the signature field value, but as you also want to print the documents, that might not suffice: In print there is no signature field value, only its appearance.
In such a situation the document to sign should already be prepared with empty signature fields positioned appropriately in the document and named or otherwise flagged to signal the role of the person to sign it. This, by the way, would also be the interoperable way, empty signature fields can easily be signed in e.g. Adobe Reader.
If this is not possible, though, and if the software for signing the document has a GUI, this GUI might provide the capabilities for each signer to position his signature appropriately for his signing reason and role.
Otherwise your extra signature page approach would be the approach of choice.
If all signers have the same role, though, or if there at least is no special appropriate position for any of the signing roles, your extra page approach might not merely be a last resort. It even kind of looks like a document resulting from a notarial act.
If it is, is there a way to identify the "doc_signatures" page so I don't append it again.
For PDFs according to the current ISO 32000-1 norm, you could do this using a page-piece dictionary:
A page-piece dictionary may be used to hold private conforming product data. The data may be
associated with a page or form XObject by means of the optional PieceInfo entry in the page object or form dictionary.
(section 14.5 of ISO 32000-1)
It looks like these piece dictionaries will be deprecated in the upcoming ISO 32000-2, though. Thus, a more future-proof approach would be for you to register a developer prefix and use your own key for that endeavor:
Developer
prefixes shall be used to identify extensions to PDF that use First Class names (see below) and that are
intended for public use.
(annex E of ISO 32000-1)
These custom keys don't seem to become deprecated in ISO 32000-2.
Also, can I add like signature fields to that "doc_signatures" page, with a position each one, so when I open the PDF, I detect it has "doc_signatures" already created and that it already has a signature on that page on "Field 1"(with its own X,Y coordinates) so place the second signature on "Field 2" on "doc_signatures" page and "Field 3" for the third signature, and also some type of limmit of the amount of signatures on the document?
You can easily inspect the annotations on your extra page and especially determine their location and extent. Consequently you can arrange additional signatures to your liking on an individual basis. Alternatively you can prepare a fixed number of empty signature fields on that extra page when you create it, arranging the signatures to your liking in one go.
All the above is only possible if the source document has not been signed before! If it already has been signed, adding a new page usually is considered a disallowed change of the document, effectively invalidating that first signature. For allowed and disallowed changes of signed document, see this answer.
Lets say each document type has a specific amount of signatures, for example, A sales document, with seller and buyer signatures, so the approach would be adding too signing fields to the documents and then place the signatures on those fields.. am I correct?
Exactly that is what I would propose: If you know the number and roles of the signers beforehand, prepare empty signature fields for them. In that case you do not even have to mark a signature page or something.
Now, sorry to bother you, with PDFBox will I be able to create signature fields and add signatures to those fields? Is there any example code for that?
Both is possible with PDFBox, but in particular adding a signature to an existing empty signature field may require some own coding.
Do you know a way (f.e. library) in which I can generate signature lines in Microsoft Word document in Java as described for example on Microsoft's page
and later use it to sign a document multiple times? Each signature can be added at different point in time.
The crucial functionality I need to have is that a signer's name is added when a document is signed. In MS Word at the beginning you can define a number of 'signature lines' and then each person must right click on one signature box and click sign. The signer's name is filled in without breaking previous signatures.
I know how to sign documents in java (usually external xades signatures). I was also able to add multiple signatures at the same time using Apache POI as described here:
How to programatically sign an MS office XML document with Java? but this will not work when changing a document (to update a signer's name). Maybe this functionality is also available in Apache POI?
In the attached print screen you can see (unfortunately in Polish; PODPIS/PODPISY == SIGNATURE/SIGNATURES) what can be generated in Microsoft Word. Near the 'X' signers' names are updated when the document is signed by each person.
Thanks for any help.
I'm wondering if it is possible, using iText (that I used for signing) or other tools in Java, to add biometric data on a pdf.
I'll explain better: while signing on a sign tablet, I collect signature information like pen pressure, signing speed and so on. I'd like to store those informations (variables in java) togheter with the signature on the pdf. Obviously hidden and encrypted such as the signatures info.
Is there some kind of hidden data field on a pdf or something that can contain this kind of information? I think it is inappropriate to store it in the metadata fields such as author etc.
There are different ways to add info to a PDF document.
You could add the data in a document-level attachment. That way, people can inspect the data by opening the attachment panel.
Storing it as metadata is fine too, but you're right about it being inappropriate to store that info in something like the author key.
As you may know, the /Info dictionary will be deprecated in PDF 2.0 in favor of using an XMP metadata stream. In this metadata stream, you can add custom XML data (see section 2.2.1 of the XMP specification - Part 3).
If you don't want to mix your biometric data with the document metadata, you can even define an XMP stream for any dictionary you want, probably including the signature dictionary. See section 14.3.2 of ISO-32000-1.
PS 1: I don't know who downvoted your question. I upvoted it, so you're back at 0.
PS 2: If you want to create future proof signatures, read http://itextpdf.com/book/digitalsignatures
PS 3: Signatures created with the 4-year-old version of iText usually aren't future-proof.