I have an ASP, vb.net, forms-based system. I want to allow people to use PDF documents created within that system to send them to DocuSign and out to others for signature. I have used the DocuSign SDK to build a system that works; however, I am concerned that I may not have the best setup for that.
The problem relates to the "open" nature of this system. Our users are allowed to see and modify all parts of the underlying system, including forms, coding, etc. As a result, a clientID and secret would be seeable to users. And that is concerning.
The system will need to be set to be easily used by our users. So, having users set up a developer account, setting up API settings, etc., will not be something we can reasonably expect.
It would be better if the system did all the interaction and they just had to log on to DocuSign to send the document out for signing. DocuSign has suggested becoming a partner in their referral system. I worry that will still require all the pieces (clientID and secret) that people will be able to see. But, I am not sure that is true.
Will being a partner mean we can avoid having those items saved in an open system where users can see them? Or does being a partner mean some of that is removed or not necessary?
Is there a better way of setting this up so that we can avoid all that mess?
There's no reason that all your customers wouldn't be able to use the same clientID (also know as Integration Key or IK) and secret key (clientSecret).
You will be the only one that can see/set them as the ISV. They will all use their own DocuSign accounts, using your IK. That is abosltuly fine and does not have any limitations.
We recommend ISVs use a single IK per app if it's the same code for the app even if they have multiple customers using the app.
Related
I am working on a project which needs User Authentication. The "Clients" are iOS (Swift) or Android (Kotlin) native applications. The original form of the API (NodeJS) used Facebook and Account Kit for OAuth and Phone authentication respectively. Since Account Kit shutdown, we moved to Firebase Phone Authentication for Phone but left Facebook in its original form. Now, we're wanting to consolidate our Authentication providers (to Firebase) but I can't seem to find a way to "convert" or "import" Facebook users to Firebase-based Facebook users.
So far, I've read through the Documentation, including the category about importing users, but it doesn't seem to indicate an ability to maintain backwards compatibility, while also moving forward to Firebase. What I mean is, it has an ability to set information, but it doesn't indicate that the same information will be used to authenticate that user as the same unique visitor.
What I am looking for is either transitory logic, which will handle this during login, or preferably, a "bulk-insert" type migration. Essentially, I want to have it setup so that the API only needs to keep a single authentication UID, and use only a single third party (even if they then use another subsequent third party) while maintaining user uniqueness (so that it doesn't create a new user for the same Facebook account).
Part of my problem in creating a temporary patch (not necessary if the main question is answered) is that I don't know of a way to differentiate between a Facebook UID and a Firebase UID to fork the logic. Again, this is only relevant if there isn't a solution for migration.
Feel free to request any more details that would be useful.
Update #1
I realized my question was open ended in what I was asking. I've been digging further and can better define my question:
I need a way to bulk insert users into Firebase's Authentication with a provider of Facebook. I know I can import them, via admin.auth().importUsers([...]) and that I can create accounts via admin.auth().createUser({...}) but when I do the former I can't seem to get back the user's UID, and the latter doesn't seem to allow specifying a provider. Am I missing something?
I am a C# software guy by day and a SharePoint beginner. I am using a Content Editor Web Part with SharePoint Online and do not know how to securely store secrets. My SharePoint app must communicate with another application and todo so I must use custom credentials. Because I am in the Dev phase, I am able to hard code the creds inside of my Type Script files, but this is not what I want long term.
My ask is if someone can walk me through the proper strategy for storing secrets using SharePoint Online Content Editor Web Parts to be consumed by the TypeScript/JavaScript.
Thanks
Quite honestly, the proper strategy would be to not use JavaScript at all for sensitive API calls. Sensitive API calls should only be made server-side (so that any "secret" keys, passwords, etc. never reach the browser).
The problem with storing a secret value somewhere and accessing it with JavaScript is that JavaScript would have to decode the value somewhere along the way in order to use it. That means a savvy user could view the source code for your page, open their browser JS tools, and execute the same commands to get the value. Not great for security.
On-premise SharePoint actually has a solution for this called the Secure Store Service, but part of why that works is it's designed for use in server-side code. As of yet, Microsoft hasn't released a client-side API for that service in SharePoint Online (probably because using it with JS would be less secure as I mentioned).
The "proper" strategy depends on your goals. You've got at least 2 options:
If you want real security for your secret key/password/whatever, you'd need to develop a SharePoint Online "Hosted Add-In" which lives on another server or a cloud service like Azure. SharePoint provides "app parts" that wrap hosted add-ins with iframes and let you add them to a page, so you could use that to add your app to a SharePoint page and have it display results from an API call (very similar to how a Content Editor Web Part would look).
If you don't need real security and "security by obscurity" is good enough, then I'd recommend storing the secret value in a SharePoint list and doing some "fake" encryption on it like Base64 encoding. Then decode the value in JavaScript after reading it from the list. If you want to add even more obscurity, you can use PowerShell or JavaScript to make the list hidden so users don't see it in their browser, but that also means you'd have to add/edit values through code.
I am writing an application that uses Docusign and I’m trying to figure out the best way to manage my Docusign account in general.
Here is the use case:
1) My software uses custom Docusign templates and tabs and uses the Docusign API to accomplish populating the templates, tabs, and generating envelopes
2) The user will have to provide their own Docusign account to use my software
Questions:
1) How do I get the custom templates loaded into their Docusign account?
Can templates be shared between totally disparate Docusign accounts?
Other options I think might work are an export or import of the templates (but that is clunky).
Maybe I can use the API to upload the templates as well???
2) Who’s Docusign Integrator Key do I use?
Do they need to generate one from their Docusign account and I use that one from my software? Or do I ALWAYS use my developer integrator key???
3) Who’s API username and password do I use to log in via the API?
I assume theirs, but I’m not a fan of needing to save a bunch of Docusign passwords in my database.
Any other options for setting this up the right way???
Thanks everyone!
For future inquires, include if you're using REST or SOAP.
Here are the answers to the questions that you have above.
1) How do I get the custom templates loaded into their Docusign account?
Can templates be shared between totally disparate Docusign accounts?
Other options I think might work are an export or import of the templates (but that is clunky).
Maybe I can use the API to upload the templates as well???
Templates can only be shared within users on the same account. There isn't a way to upload a template via the API either. You can use composite templates for a standardized template across multiple accounts (depending on SOAP/REST, the coding changes here)
2) Who’s Docusign Integrator Key do I use?
Do they need to generate one from their Docusign account and I use that one from my software? Or do I ALWAYS use my developer integrator key???
Your application will always use your Integrator Key, which will only work in Demo until you go through the Certification to get the Integrator Key promoted to production.
More info on that process here: https://www.docusign.com/developer-center/go-live/certification
3) Who’s API username and password do I use to log in via the API?
I assume theirs, but I’m not a fan of needing to save a bunch of Docusign passwords in my database.
Any other options for setting this up the right way???
You will need specific permissions enabled on a user and on an account to make API calls successfully. Most integration's use a system user to login and make these calls. If you're working within multiple accounts that you do not have administration over, you will end up running into permission errors.
It sounds like you're wanting to setup a Partner integration, which does differ a little from a standard integration.
I am creating a web-page/website that integrates all my accounts into one spectrum, as in, from this page I want to use this page to log into my mail box online or any other site that requires authentication. All i want is a central login panel. enter my unname&passwd and get redirected to my mail. Is that an impossible question to ask?
It sounds to me like you want to consider using OpenId, which is a standard, fairly widely adopted form of single sign-on. Used by this very site, in fact, and supported by at least two of the three companies you mentioned: yahoo and google. Hotmail does not currently support it.
It completely depends on the individual service. You'll have to investigate each service to see if they even allow you to authenticate against their servers remotely. In the event that they do allow it, it's still up to the service whether or not you'll be able to retrieve any kind of information from them after logging in.
Banks in particular are very unlikely to give you any way to interface with them and the ones that do will likely require a monthly access fee.
You want to look into SAML, an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee.
With SAML, you can communicate between the major single sign on (SS0) technologies like CAS, OpenID, Shibboleth, AD/LDAP...
I work in a large company, and I'm interested in best practices for internal security standards. We have a large ($500 million +) investment in SAP, and we also have .Net and a bit of Java EE in our internal environment.
I've found some documentation from MS and SAP, but it's outdated and not very specific.
So far, it looks like we could end up using Active Directory as the standard user store for all non-SAP applications, and SAP CUA / Portal for SAP applications.
Some concerns I have about AD are:
Being able to aggressively time-out for applications on shared computers (A small number of our applications run in remote offices in rural areas with a limited number of shared machines. In these cases, a supervisor with "power user" privilages could use an application, and then a clerk who should have only basic privaleges could use the same machine immediately after)
Being able to force the user to enter a username and password instead of just having the credentials read from the user's workstation - Because it's pulling the same credentials for the desktop and email, it won't currently ask users to log in. This is a concern for applications on shared computers as well. (See the explanation in the previous bullet)
As far as synchronization between AD and CUA is concerned, I want to approach this very carefully. We have a limited budget, and I want to make sure that if we end up putting something in place to synchronize the stores, that it's rock sold and provides excellent value. If we can't find something like this, I'd be comfortable coming back with a recommendation that the stores remain independent. SSO would be ideal, but I've worked with trying to get an SSO application up before SAML, and it wasn't pretty.
Acronyms:
SSO: Single Sign-On SAML: Security
Assertion Markup Language
CUA: Central User Administration (For SAP)
There is a lot of possibilities on this subject.
We had a customer that updated both their AD and their SAP user list from SAP HR. The idea was that the OM module contained all employees. You could export daily a list of all active employees to the LDAP, with basic informations (firstname, lastname, employeeId, login...). For the SAP system, unit/function/job needing a sap access where tagged and user where created/removed daily.
In fact, all employees had a SAP account, but only those tagged had a "dialog" one. Those account are allowed to connect via SAPGUI, others had to use the portal, which is a less costly licence. A set of rules allowed to set the roles for the managed users. The goal was to minimize user management and limit the inexorable grows of autorisation that comme from moving from job to job an organisation. (this was for 105000 employe, with a lot of personnel movement).
Thus SAP was not directly linked to the AD, but they where synchronised. Depending on the system (Development, qulity, integration, production), SAP was configured with time-out. You could also have différent password for separate systems.
Of course the reverse is also possible : interrogate a LDAP from SAP to manage SAP's accounts, without beeing directly linked to the LDAP. transaction LDAP can problably give you some informations.
hope this helps
Edit : the synchronisation was done by an ABAP program. that program was run every day at four, and created/deleted/modifed some accounts in the LDAP. After that, another program added some technical informations to the LDAP entries, informations that where not available to the SAP RH system (such as the mail server to use for a given employee, depending on its location around the world). The entries where then checked for consistency, and send to the master LDAP.
This program only managed personnel and units. Groups (authorization for others application) where managed either manually, or by others programs. Thus non SAP data were also stored in the LDAP.
Regards
Why is it a problem if users don't have to log in? Wouldn't that be more convenient for users? And wouldn't it give them further incentive to log out of the application?
The project I'm working on now uses AD, and we have a mapping table inside of SAP to map AD accounts and SAP accounts. Syncronisation is manual, which may or may not work for you, but there's no real technical risk.
I wish I could give you more information, but I haven't been very involved with that side of things. I can look into it,though.
You might want to look at OpenSSO - it has agents for SAP and it will integrate with AD as the user store. It's also pretty solid - Verizon use it for 40 million customers to log in to their web site.
IMHO.
This is not good solution to use different users in one windows session. Especially users authenticated in AD.
Usually it will be going that USER1 running sap client without closing , and work another USER2.
You get non-personified users. And don't forget users don't like perform all instructions.
We used thin client like citrix and SSO. It is full split data and authorization between users. And you have to use different sessions for users on workstation. The good think is no critical data store on workstation.
Not good idea and not secure but you can use run as different users
application in Windows environment in same session. But it is not secure solution for big company.