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.
Related
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.
What are the basic functionality which it provides?
Specifically for the person who has never used asp.net built in stuff.
The MSDN tutorial is confusing me a lot. Claims, OWIN,etc are going above my head.
What I can make out of all this is - The Identity framework helps me to manage my application plus social logins. It handles my cookie,etc.
What if I have just one role in my application - just the plain user?
Should I go for the Identity then or I should implement my own custom thing?
Any help is appreciated.
If you are starting from scratch, build a sample MVC project with individual membership option, which will create the following components for you:
Login module that creates and manages authentication cookies
Simple database to store basic user data (credentials, name)
EF code to interact with the database
This will most likely meet your use case for a user without roles and attributes.
OWIN really has nothing to do with authentication, it is a new spec for building web apps. The login module happens to be implemented according to this spec and it sounds cool, so Microsoft likes to throw this term around a lot.
If you are not planning to have authorization logic in the app, then you don't need to worry about Claims. Claims is another term for user attributes (login, name, roles, permissions). The Claims collection will be populated by the framework, but you most likely won't use it. If you need just the user id/name, the old ASP.NET interfaces are still there to get this data.
As far as implementing your own, I've seen people here ditching the database and EF code, especially if they already have an existing user store. You just need to implement a credential verification logic against your store. You don't want to build your own cookie management, though. Use the login module provided by Microsoft or well established third party systems (SiteMinder, Tivoli, etc.)
Looks at this open source project for a good alternative to ASP.NET Identity.
This is a very well put together tutorial that explains many of these concepts, you can get a free trial to the site to see it.
Looking to create a completely external portal using only HTML5, JS, and CSS to show CRM 2011 data. It does not look like I can use REST or SOAP because they cannot authenticate externally. Does anyone know how I would do this?
Thanks!
To do this, your OrganizationData.svc service would need to be externally accessible, and it would need to function without authentication (or, your authentication would need to happen within your javascript - where the end user would be able to read your source code). Either way is not a wise idea, since all of your data would be visible to the world!
If you are only dealing with internal authenticated users, read up on the oDATA endpoint.
If you want to deal with external and/or unauthenticated users, you'll need to find another way to do this that does all of the data filtering & authorization control you need.
I think we normally achieve this using a intermediary integration service. You could have a service which has access to the Org service through conventional CRM authentication, and which provides a number of methods which can be called anonymously (or by custom security) by client code.
For example, a web page calls the 'int' service's 'getContact' method, passing an email address of the user. The 'int' service validates the user's email address and then retrieves the required data from CRM's org service, using credentials stored in a config file (a CRM user with sufficient permissions to serve the 'int' service's methods). The 'int' service then parses the data and returns it to the client code - which has no knowledge of CRM's existence - perhaps as JSON for usability.
I have been tasked with creating a SharePoint 2007 webpart that logs the user directly into our website (which uses forms authentication). Most likely the username and password will be same in the SharePoint account as in our website.
Ideally we would like it to be fully integrated in that the webpart looks up the SP login & password, somehow encodes that using SHA1, MD5 or similar encryption, then passes that along to our login page on the query string. However given we have little experience with SharePoint, and that it's probably impossible to programmatically access the SP username/password from a webpart we realize this isn't very likely to be possible and if so would probably require a lot of development time.
Another option would be to load a login form from the website within an iframe in the webpart, which would show the login & password first but store a "remember me" cookie after the first login, and on each subsequent load display just a button that logs them in directly using the cookie.
Has anyone done something similar before? I'm in over my head, any guidance would be much appreciated! :)
A good login system doesn't allow retrieval of passwords at all. (Forgot your password? Prove you're you and we'll reset it, send it to you, and force you to change it to something we can't see once you're back.) This way you CYA against both Angry IT Admin Guy back-dooring his way into other user accounts when he's disgruntled over coffee pot politics as well as a potential attack vector for the Internet at large to exploit.
The cookie idea is plausible. Depending on your SharePoint/other website configuration you may be able to federate your logins to a single authentication provider (using ADFS, Passport, OpenID, etc.), which would be a more elegant solution, but may not be feasible in your scenario.
If you're using SPS 2010 and your other website is based on .NET, then Windows Identity Foundation would be a option.
Is it okay to put your Google Maps API Key into your source code and publish it?
Others could take it and misuse it, but I don't want every developer / user to get their own API key and type it in somewhere. If the owner of the key is responsible, should I create a new google account for the project? (The project is a desktop application in Objective-C and a small developer tool.)
What would be the best way to make this convenient?
I don't think it's legal, but even it were, it's technically impossible, because the Google Maps API Key is tied to your domain name. Google will check the referrer of the HTTP request to validate the key.
The key isn't secret anyway: simply viewing the source of a website using Google Maps reveals the API key.