2

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.

  • this is a though one. Just a few pointers -> custom webservice which validates authorization before calling the other application/functionality. Secure Store may help in some way, storing credentials securely, not sure it will help here. – Cameron Verhelst Jun 26 '17 at 16:27
  • @CameronVerhelst thanks for the input. I have looked at the Secure Store, but do not see a way to implement in the manner I'm looking for. Any suggestions/pointers would be appreciated. – user959729 Jun 26 '17 at 17:26
  • Did some digging and seems like Secure Store won't help you solve this directly. You'd need to set up a proxy using a webservice, which does the authenticated data access on your user's behalf, using credentials configured in the webservice or perhaps the Secure Store Service. But you can't access it from JSOM directly, and it's a bad idea to fetch them from JS, because that means that the users can do that too. – Cameron Verhelst Jun 27 '17 at 7:42
  • Can you clarify whether for your use case, the credentials should remain a secret or if this is merely a question regarding how to make them configurable, but not secret per se? – Cameron Verhelst Jun 28 '17 at 12:23
  • A similar question/answer : sharepoint.stackexchange.com/a/194346/10170 – Cameron Verhelst Jun 29 '17 at 8:56
1

Can you modify the other application? If not, what specifically do you need to do to authenticate? Pass in a username/pwd? If the latter, I think you're out of luck, as regardless of how you store the credentials, any users who knows how to hit f12 will be able to get access to them.

alternatives:

  1. Use something like Azure AD to provide single sign on across multiple applications.

  2. Modify the other app to be deployed as a SharePoint add-in, and take advantage of single sign on provided by SP

  • Doesn't this basically authenticate your users directly against the other service, using their Azure AD credentials? Not a bad idea, though I'm not sure it's a matching answer for his question. – Cameron Verhelst Jun 28 '17 at 12:22
  • Correct. And you're right, it's not quite the solution OP was asking for, but again, what OP was asking for is likely not going to be secure, so they should investigate other options. – Mike2500 Jun 28 '17 at 12:39
  • Thanks @Mike2500. I think the answer is to take a different approach. I can not modify the other application to use the SharePoint creds. – user959729 Jun 29 '17 at 14:25
1

What you want is to control the actions taken on the external app/data by means of a web proxy. User's authenticate directly against this web proxy (the same credentials they use to login to SP). The secrets used to connect to the external resource remain at the server side, and are never exposed to the client side.

You can validate at the web proxy side if the actions performed are allowed or not.

This web proxy serves the same function as your typical "server-side" code for your JS client side app.

0

One approach is to do a REST call from your JavaScript to retrieve a text file OR a record from a List that contains your credentials. The library would need to be secured to give your users read access and you update (i.e. contribute/admin) so that you can maintain your credentials.

See SP REST Basic Operations for further information.

  • This is a bad idea because you're users can do the same rest call (you're using their credentials to access it) and they can see the secrets as well. It's better to hide everything behind a web service which acts on the users behalve. – Cameron Verhelst Jun 27 '17 at 7:43
  • Thanks for mentioning the potential exposure. While I agree there is a measure of risk, the developer will half to evaluate the degree of risk for themselves. If we are simply accessing a weather feed, that risk is much lower than other services. It is outside of the scope of the question, but my preference would be to switch to the new SP Framework. This provides the ability to develop a more secured application as well as other features. – maleman Jun 27 '17 at 19:30
  • I inferred it from the question mentioning credentials, although you're right and it may be a public service with generic credentials. Can you a link resource explaing how SPFx helps handle this use case in a more secure way? I've not seen anything yet explaining how it's done differently. – Cameron Verhelst Jun 28 '17 at 12:21
  • The primary security enhancements pertain to SharePoint objects and user management. When using the SP Framework, your app cannot "elevate" its security clearance. In other words, you will remain confined to the current user's authority. Also, your app is better protected from accidental or intentional interference from other add-ins on the same page. See Waldek's comments on security. – maleman Jun 30 '17 at 17:43
  • 1
    My mistake. I read the comment too quickly and gave a general answer regarding security enhancements with the new SP Framework. To my knowledge and experience, all REST calls along with the details are still viewable via the browser's developer console. – maleman Jun 30 '17 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.