3

I have a web service S that provides certain services. There are two web apps, A1 and A2, both on different servers within the same VPN, which I trust and want to grant access to my web service.

+------+     HTTPS   +-----+     HTTPS   +------+
|  A1  | <---------> |  S  | <---------> |  A2  |
+------+             +-----+             +------+
   ^                                         ^       VPN
. .|. . . . . . . . . . . . . . . . . . . . .|. . . . . . . .
   |                                         |       Internet
   |          +----------+                   |
   |        +----------+ |-------------------+
   +--------| Browsers |-+
            +----------+

However, I want to be able to distinguish in S between clients A1 and A2. A1 might not have the same privileges in S as A2. Moreover, I can't be sure there might not be some other web app A3 around that some evil guy installed in the same VPN. So, the basic problem is that S needs to know who it's talking to.

Some more clarification: A1 is JavaScript-based. A JavaScript in a browser is talking to the web server A1. The JavaScript is never directly talking to S, however. The web server A1 has some means to forward messages to S, e.g. a simple PHP script. There is probably no way to block evil users from contacting S through A1 in the same way as the JavaScript does. To prevent abuse of this, S is a session-based service that requires a username and a password to generate a session key. Browsers pass the session key to A1 or A2, which then pass it on to S.

The question is: How can S safely identify A1 and A2 and block any other calls?

digory doo
  • 131
  • 1
  • Who controls the VPN? – miniBill Feb 12 '15 at 17:30
  • The VPN connects two fairly large companies. S and A1 is something our company provides, A2 is implemented by the other company. – digory doo Feb 13 '15 at 10:21
  • How about creating a "trusted" VPN, that only S and A1/2 can access, with forced IPs? – miniBill Feb 14 '15 at 07:31
  • The VPN is actually not the point. A2 is to be prevented from accessing certain services in S for the reason that the other company may not fully understand how to use S. The less A2 is allowed to do, the less damage it could do if things go wrong. What I want to achieve is a fine-grained control over what clients of S may do. – digory doo Feb 14 '15 at 19:32
  • TLS with client certs? – miniBill Feb 14 '15 at 19:33
  • That's what I suggested to my boss, but he said it's too complicated. :) – digory doo Feb 15 '15 at 07:35
  • Complicated? Why so? – miniBill Feb 15 '15 at 11:36
  • Some implementations constantly complain when self-signed certs are used. And more important, the certs will be checked on each call instead of once per session, so it may be too slow. – digory doo Feb 15 '15 at 12:48

1 Answers1

1

Define rules based on API keys (Something like RESTful API)

A1SA2

If no one hacks the https connection the keys are ok Ex: https://S/req?api_key=A1&contet=action

user2379099
  • 11
  • 2
  • can you further explain this? our service S is in fact using REST. – digory doo Feb 26 '15 at 07:09
  • Sry for my lack of accuracy i am a bit noob. So my idea is that S1 and S2 have their unique keys and based on the key you create access control rules So now we know who is A1 and A2 and we can grand access or not to a resource. I am thinking of proxmox api model. Here is the link: http://pve.proxmox.com/wiki/Proxmox_VE_API Hope this will help you more – user2379099 Feb 26 '15 at 15:24