1

We are developing a single page Angular2/NodeJS app which will have a web based form for our users to fill and submit.We do not have any Web based application for our users to login to (so no SSO), but our users logs into our partner Apps, which can be a web application or mobile device each having its own authentication mechanism. Our partner apps basically calls our api to get various contents and show that in their UI. Now one of our content will have the link to the new form app that we are developing.

We want to secure the call to the Form app in such a way that the request can only be triggered from our partner apps and from no place else. The partner apps cannot stop the user from copying the url but we want to make sure that the request came in from our partner apps.

What is the best way to achieve this with minimal to no coding for our partners as we have no control over their development or release cycles. Few of the options we are evaluating

Option 1 :

Check the http header, Referer. https://en.wikipedia.org/wiki/HTTP_referer. This may not be the right solution as a) it can be easily spoofed (https://stackoverflow.com/questions/14854117/php-allow-access-to-specific-referrer-url-page-only) and b) The client can be a mobile app and decide to not send the header

Option 2 :

Another option would be our partners to pass a token as a hidden parameter. So assuming any non tech savvy user will not look into the page source to find what the token is. Ofcourse this may need some dev activity from our partners which we would like to avoid.

Are there any other elegant solution which we can try

  • It might be useful to explain what you are trying to achieve with the restriction of only allowing access from the partner apps. Because, this restriction might be the Y in an XY problem and by knowing the original problem X one might find more practicable solutions to X outside of Y. – Steffen Ullrich Jun 16 '17 at 18:56
  • @SteffenUllrich basically the form is for medical professionals and will contain PII (Personal Identifiable Information) data. The business requirement is since our partner apps are secured apps the call should only come from them. We shouldn't allow requests from people who have just got acess to the url by other means. DOes that answer your question? – Tatha Jun 16 '17 at 19:03
  • Linking from a secure application to another one does not magically make the linking itself secure. If the link triggers sensitive actions (which I assume is your primary problem) the goal is not to keep the link itself unusable outside the application (which is I think impossible) but to make sure that the trusted application has created the link, for example by signing it with a key pair associated with the application and adding some time stamp to detect later replay attempts. – Steffen Ullrich Jun 16 '17 at 19:27
  • Do the partner apps call your API from client (e.g. via JavaScript running in a browser, or code running in a mobile app) or from the back end (the partner's web server)? – John Wu Jun 16 '17 at 22:34
  • If you don't have a web application, then how does the partner application's call to your Javascript have any effect? A server calling another server will not even attempt to evaluate the Javascript it gets in return like a browser would. – jacobbaer Jun 17 '17 at 4:49
1

You're trying to use your vendors as Single Sign On providers. That is absolutely possible... if they are willing to implement some federated identity protocol like OAuth, SAML, Kerberos, etc. This would involve substantial engineering work on their part, and probably substantial burecruatic work and legal liability since HIPAA is in play. (I don't know. I'm not your lawyer).

For the reasons you've listed, relying on the Referer header or a shared, unlimited-use, unaccountable secret is absolutely out of the question. Further, trusting a user simply because he was logged in at a trusted vendor is also out of the question. Your API needs to know who, specifically, is acting on it, and store/log that information. Your business may not care, but HIPAA does.

SSO/federated identity protocols are ways of generating, passing, and checking tokens like your Option 2 that are specific to the user, time window, etc. Don't invent your own. OAuth is probably the easiest to implement.

The simplest solution is to build user accounts into your NodeJS app. Users must be logged in (have session cookies) to get anywhere with the URL from your vendor. No federated identity problem.

Another fairly simple solution is to have your API and your vendors' backends communicate directly, with no end-user browser in the loop. HTTPS and a simple token in an HTTP header would be reasonable. Mutual TLS with client certificates is the gold standard. But this relies on the secrets staying in the backend. This would also mean any changes in the way you interact are code changes for your vendors.

The real solution is to implement an Identity Provider (farm it out to Microsoft Azure, AWS, or OneLogin, or hire consultants to do it inside your firewall) and integrate it with all your vendors and your API so that your users only have one account to deal with. Your existing vendors almost certainly don't want this role. SaaS folks might not want it because HIPAA, but probably one of them will be willing to execute a HIPAA Business Associate Agreement for the right price.

  • Hi @jacbbaer Thanks for your response. It's quite complicated to explain but the solution of integrating with an IDP is the long term plan and we cannot implement it now and it may take months due to bureaucratic processes between us and the partners. We are thinking of some quick solution without partner dev activity. We have oAuth enabled for our REST APIs, so one option is let the partners pass the token in the header when invoking the links, but the links will be anchor tags, so each partner will need a dev activity to pass the token header. – Tatha Jun 19 '17 at 19:55
  • Your best bet for a stopgap is to implement user sessions in your Node webapp directly then. There's no getting around your partners needing to modify their applications to do a secure handoff of user sessions to your own app. If you're concerned about convenience for your users (and you own their machines, and they have full disk encryption and screensaver locks as required) you could issue client certificates instead of passwords. – jacobbaer Jun 23 '17 at 4:13

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.