I have a problem with the Docusign embedded Edit View.
My application connects to Docusign via JWT. Using the API, I'm allowing users to edit existing envelopes (when in draft) through my own application. The redirection to docusign works fine and the users are able to edit an envelope, adding/removing recipients, setting the signature blocks, etc. All good there. My problem is with the callback.
Using the ReturnUrlRequest, my callbacks are successful and after editing an envelope, users are redirected back to my application. The problem is that before this happens, for a few seconds they are looking at the Docusign inbox for the account. This is a security issue and could allow users to see privileged information, as if they send an envelope after editing it, they'll be looking at the sent folder and can see all other recent envelopes. I presume they could also stay in the inbox and do whatever they wanted if they click on an entry quick enough, but I haven't confirmed this yet.
I need the callback to go directly from the envelope edit to my application, and prevent anything else from docusign from appearing. Is there a way I can lock this down?
And yes, I know that this is something I shouldn't be doing in any event, and that my basic problem is that I'm using the edit view in the first place. I don't have much of a choice. I originally implemented things using the API and my own application provided all of the configuration options on their own. The client, however, didn't like this and essentially demanded that their users be allowed to use the Docusign system's own editing suite, as that is what they are familiar with. I'm trying to square the circle as best as I possibly can.
As per the Information Security Notice on the linked page, the Create Edit View provides fully authenticated access to the sending user's account. Even if you were able to prevent the brief view of the inbox, a savvy user could 'break out' of the edit view by navigating directly to app.docusign.com (or appdemo.docusign.com in the sandbox) because their DocuSign session is still valid.
The only way to 'secure' this is to provision each sending user their own membership on the DocuSign account so that users cannot see each other's envelopes (unless explicitly allowed to do so via Document Sharing).
In addition to Drew's answer: please ask your DocuSign account rep or customer service contact to add your customer information to internal ticket EC-1009. That will help raise prioritization of providing a secure edit screen for applications to use.
Related
I am creating a web app that has the following requirements:
There will be multiple administrators working for a tenant. The administrators will upload a document that needs to be signed and select the recipients and click send. The recipients will receive a link by email, click it, log in, view the document and sign it.
I was looking into third party developer API's to help with this such as DocuSign but a few questions/concerns came to mind.
I am going to assume that uploading and setting the areas to sign would need to be done through the docusign site. So would each administrator have to login in to the single tenant docusign account and upload their documents? Seems like it wouldn't be possible.
As an alternative I was thinking about staying away from the third parties entirely and just using an HTML signature pad under the document. However, with this technique the actual document would never be signed so for printing purposes it would look bad.
If anyone can shine some light on this topic that would be great. I am trying to figure out what my options are.
(I work for DocuSign.) Using DocuSign or another 3rd party product to handle the signing ceremony and related legal issues is usually a business decision that you'll want to discuss with your colleagues.
Legal issues to be considered include the signer's authorization to use eSignatures for the transaction, authentication, non-reputability, and more.
If you choose to use DocuSign, we have many code examples to help you implement your application.
It is common to "embed" the signing ceremony within your application. Your application can programmatically create the document, or use pre-canned documents.
Signature fields can be placed via anchor text as suggested by #EmmanuelRosa or specific coordinates on the page can be used.
If you have questions about how DocuSign works, contact DocuSign for more information. You can also sign up for a free trial account. When you're ready to develop your software, sign up for a developer sandbox account. More info is available on the DevCenter.
Added: Multiple tenant application
If you're writing an ISV application that you'll sell to multiple customers (tenants) then each customer will usually have their own DocuSign Account. In some cases you'll find that customers will have a pre-existing DocuSign account that they will want to use with your application.
In other cases, your customer's first need for a DocuSign account will be to use it with your application.
If you want, and depending on your volumes, you can resell DocuSign accounts to your customers who need them.
Each DocuSign account can handle any number of users. Users are usually people who send transactions for signing.
Signers do not need a DocuSign account and are not charged for.
You will not want your customers to share a DocuSign account since an account administrator can see all of the account's transactions.
Generally speaking, DocuSign does not charge per account. Instead it charges either per sender or per sent transaction (envelope).
Also note one ISV application written by you will have one Integration Key (same as a client_id) and that application can be used by any number of users, in any number of different DocuSign accounts.
I am going to assume that uploading and setting the areas to sign
would need to be done through the docusign site.
Actually, you can do that programmatically :)
I don't recall the details, but I do remember creating a template (*.docx file) of the document that would be uploaded. The template had placeholders for where the signature goes. I believe I used something like {{signature}} as the placeholder. Then, in your code you use the DocuSign API to upload the document and template; There's a way to tell the API what placeholders you used for the various fields.
The signing happens on the DocuSign website, but you can set up the document through the API.
In fact, it is possible to upload to multiple recipients with DocuSign. As the DocuSign documentation is suggesting, here are the steps to follow in order to send to multiple different recipients from the same account (administrators account).
Upload your document
From your DocuSign Account, click NEW, then click Send an Envelope.
Click UPLOAD A FILE to upload a document from your computer, or click GET FROM CLOUD to upload a document from an online location. Locate the document you want to upload and click Open.
Add the recipient
In the RECIPIENTS field, enter the recipient's name and email address.
Add the email subject and message
a. DocuSign automatically adds an email subject when you upload a document. You can edit this subject and add a message to the recipient by filling in the MESSAGE fields.
b. When finished, click NEXT.
Add signing fields
The Fields Palette and your document appear. The recipient name is displayed in the Recipients List.
To assign a signature or other field for the recipient, click and drag a field from the Fields Palette and place it on the document.
Preview and send your document
Review your document, then click SEND.
I work for HelloSign. The HelloSign API fits your use case very well and you can try it out for free. https://app.hellosign.com/api/reference
Do you want to have the document uploading take place on your website? If so, that is fine with the HelloSign API. We have a workflow called Embedded Requesting where the administrators could place the signature fields using an editor. We have other ways of placing signature fields as well.
Building it yourself is a lot of effort if you want the signature to be legally valid. You can reach out to HelloSign API Support at apisupport#hellosign.com
This question already has answers here:
How can I suppress the browser's authentication dialog?
(12 answers)
Closed 5 years ago.
First of all, I'm not 100% sure what I'm asking is a right thing to do or not. So please free feel to correct me if I'm wrong.
Using Spring Security, I've developed a REST API backend which users can log in using some custom entry. If my users authenticate themselves using my custom API, there will be a session created for them and the rest of API entries will be accessible to them, considering their role and ACL.
At the same time, these APIs are designed so they can provide services to other software. So I thought it makes sense to enable some HTTP Basic Authentication as well. Later on, I might be working on digest as well. And if some request is authenticated using one of these methods, there will be no session created for them. And they'll need re-authenticate for every single request. It's a stateless API.
So far everything is great. The users and other systems can make use of the same sets of APIs. But the problem is when a user's session is expired. Or when some user starts using the backend services before he logs in. In such cases, the right strategy is to redirect the user to a login page and ask them to authenticate themselves. But since I've enabled the HTTP Basic Authentication, calling a REST API which needs authentication (while the user is not authenticated) leads to a browser popup asking for the username and password.
Of course, the user can enter the credentials and keep using the system. But I don't like this way of authentication for my users. First of all, the authentication credentials will stick and I consider it a security risk. They are easily be saved into the browser without informing the user they are. And it's hard to get rid of the saved credentials. The user can leave the computer without even knowing that his username and password are saved.
So my question is, is it possible to have Basic Authentication enabled but at the same time, prevent the browser from knowing it? Or even better, acting on it?
I suspect that if I prevent the WWW-Authenticate response header on the way back, I might be able to do so. But then, I'm not sure of the ramifications of such a decision. Also, I don't know how to remove that header from the response for all of the APIs.
I think I rushed into asking a question without researching it thoroughly first! This post answers it perfectly!
How can I supress the browser's authentication dialog?
The solution: add a X-Requested-With: XMLHttpRequest header to your request.
i am working on a java/j2ee based web application where i have one module called leave management in which when the employee request for the leave the manager approves or reject leave by log in to the application,Here log in into the application creates an extra overhead for the user , so i am trying to implement a feature where the manager can approve or reject the from his/her mail itself as mail is sent to the manager every time the employee request for leave based on the parameters in the url in the link like this
without log in to the application
https://my.xyz.com//LEAVE#LeaveReq#123#1545#State
So my question is
Is it possible to achieve this without log in to the application and saving values to the database and without breaching the security.
2.If yes, how can i implement this?
Yes you could. Just pass in some other parameters like say we call it token which would contain a "random" string which is currently in your database.
Each request that doesn't require authentication should also pass in this token. You check the token in your database if it is there then do the request, if not, you know what to do. If a token is consumed, you could either delete it from your DB (meaning each token is one-time use only).
EDIT: Regarding whether the correct manager approves/reject, well that's difficult without something like authentication to identity the manager.
We just rely on the fact that that URL can only be used once, and that it can only be seen on the email of the appropriate person.
is it possible? Certainly.
Is it desirable? Maybe not. What prevents someone else from sending that confirmation email? You need to find a way to secure it all.
How to do it? A REST webservice comes to mind, with the manager just clicking a link in that automatically generated email which launches a webservice request.
Or you set up a system where the server can receive emails, and the manager can then just forward the leave request to either of 2 email addresses.
There should be at least single authentication like a pin code or password before manager approve or disapprove the leave. Don't think about overhead, for such circumstances security is equally important.
Is it possible to achieve this without log in to the application and
saving values to the database and without breaching the security.
When the manager gets an email & he clicks on the approve. Ideally a request is fired from manager's system carrying an authentication token or something like a remember me token. In this case the application won't prompt the manager to login. It will tally the request token with token stored in the db & would let manager in.
Check how remember me works in web applications. You can create a remember me token for manager for an indefinite amount of time. This way the app will never prompt the manager for a login. But there is a caveat, this approach is a little vulnerable for attack. If there is a man in middle attack the hacker will get hold of the manager's client side cookies & would always login with ease. The auth token should be changed periodically. You can always implement remember me, it just depends on what level of security you require.
Bottom line: Yes it is possible, generate a remember me token which will always be included in the manager's email request for approving employee's leave request. Just follow the best practices to implement a remember me token.
Another way is
If your application is implementing security using filters. You can bypass the request for leave approval. Just put a secure none attribute for that particular request in ant style say "yourapp/approval" resource. Now the server side code would let all the requests in this pattern pass without security check. But this approach is a strict No No. If this happens a hacker which intercepts the leave request from the employee's browser can approve his leave by himself. No need of manager's authentication.
If yes, how can i implement this?
Implementing remember-me for a website
You can also integrate Spring Security with your code. It's hell of a framework, one stop solution for all the security related features which your app would require. You don't have to write the login for implementing auth token & stuff from scratch.
Is it possible? Certainly.
Is it desirable? Yes
Use a one time hash(sha1 hash may be) in the link to approve and after approving the email, send an email to the person who approved the email saying that "He/She has approved a leave for this particular person"
So the manager/authorizer is aware about it.
How password rest with an email link works could be a good analogy.
I think login is not critical for this scenario assuming that cancelling a approved leave is not that critical.(It happens usually in many companies)
I'm have implemented a module for Java web application that users will need to request for them to access the secured data. It works like this: when users that does not yet have access clicks on a certain link, a request is made and is received on the server side. It now generates an email and sends to people who are "approvers". The email contain links on approving or denying the access of that user.
Approved Link:http://hostname/App_name?action=actionClass&approved=true
Denied Link:http://hostname/App_name?action=actionClass&approved=false
Now the question is, is there a better way to do this which also takes into consideration the security?
I did try to look for other posts that are related to this but the results don't seem to be touching on this regard. If there are any that I have missed, I would appreciate if you can also point them so I can revise the question.
Thanks in advance
I'll assume that you are authenticating the users when they click on the given link, because otherwise it's just bad mojo.
You can have some privileges assigned to that user and check that to see if you are going to allow the approve or not.
That depends on how you are sending out the email. Assuming you are doing it client-side, then a user could intercept their own approval link, which clearly you don't want.
A better way (assuming you aren't doing this already) would be to send the user information (via HTTPS of course) to your server and then have the server generate and send the email. This way no one has access to the approval link except those emailed by the server and those in control of the server (you hopefully).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm starting to work on a SSO solution for 3 different webapps we've produced and still maintain for the same client.
Thing is, all 3 store their users and login information in the same place through a fourth separate application which provides just basic restful api services.
Which basically means that when one tries to log into, we actually call the rest service asking whether this username and password are correct.
In a way this fourth restful thingie already does at least half of the job we need.
What we need now is a way to let users log into webapp A, then follow a link (or simply type its url) to webapp B (or simply type its url) and get there already logged (or viceversa).
I've been reading a lot about CAS and openID or even oauth but can't really make up my mind about it.
Is this pattern centralized? Decentralized?
My ten-thousand foot view suggests I would somehow just need to add this "missing feature" to our restful api server.
But how?
ps: these 3 are completely separated. deployed on different machines (2 of them run on glassfish, the other one runs on tomcat). different domains too.
pps: they're all spring-driven webapps (hence they use spring-security)
ppps: as of today, there are other webapps using our restul api (non spring, non java).
this sso solution might have to be ready to handle those too.
Yeah it sounds like you need a "true" single sign on system rather than just a centralized credential repository. As you mentioned there are several options:
OpenId - more suited to an internet type application in which you
want to allow users to log into your systems with credentials that
are maintained by a third party. Stackoverflow is a classic example.
You can sign in with your google account etc.
Oauth provides Pseudo authentication and sso - whereas OpenId says
"this is user x" oauth says "this user has access to x's
information" ... so you can assume that the user is x.
CAS, Cloudseal, OpenAM etc all provide true single
sign on and are suitable for an intranet or extranet environment.
CAS and Cloudseal have especially good Spring support.
Trusted site (relying party (RP) in white list - app a,b,c in your case) make request (redirect) to main site (provider - "fourth separate application") with a return url.
Main site make sure request (returnURL) is from white list of domains
Log user (if not logged, displaying login form), mark user as logged in database and add temporary token to user database.
Main site return (redirect) to RP with token.
RP look into database using token, logs user and deletes token.
SSOff also easy: just check on every request into user database into bool record (userLogged). NO REDIRECTS. On logout simply change record (userLogged) to false and every site will know.