Best/secure way to have web pages communicate with each other

[Red Squirrel]

I'm writing a central authentication system to tie my forum, game server and other services so it uses one login. Basically same idea as a Google Account, I guess. This system will also house ACLs (Access Control List) which will entail being able to give users access to specific items. Like for the forum, all forum access will be done in this system instead of the forum. If I want to give a user access to a specific feature on any of my sites, same idea, I just drop them in the proper group in the authentication system.

Right now everything runs on the same server so it would be very easy to just have all the sites read/write to the same DB, but I want to make this future proof by making it so that each website just talks to the authentication system through a special URL. Basically it will POST info and get a result back. So when you login to the forum for example, your credentials are sent and then a yes/no is sent to say that you authenticated. A list of ACLs is then sent.

What is the best way of doing something like this? Most programs will be using php, but some of them may be other languages. I'm thinking of just using HTTPS for everything, so in php I could probably juse use cURL to POST data. This would be done over HTTPS, as stuff like logging in or verifying a session cookie would be done in "clear text". (HTTPS would encrypt it but the web page at the other end would see it as clear text so it can process it properly).

is cURL the way to go for this type of cross site communication or is there a better way? Of course, I will also want to implement proper security so that a random joe who happens to find that administrative URL can't just submit commands to it. So there will probably be some kind of passcode or something, and IP access list as well.

Any performance issues I should also be worried about to doing this? Debating on if I want the authentication/session checks to be real time or if sites will just cache it so each page load does not also involve a hit to the authentication server.

Eventually I would probably get a small VPS or something for the authentication server as I figure if it's running JUST that, and SSH for administration, there is less attack surface for the user database to get hacked etc. Of course the passwords will be salted and peppered with bycrypt so have fun with that even if it does get compromised. 😛

 

[Ken g6]

It sounds like you want "single sign-on". I've never seen a single sign-on system that wasn't a mess to set up and maintain. But I'd like to be proven wrong.

 

[Red Squirrel]

Essentially yes. Given this is fully custom and I'm not restrained by anything proprietary I am confident I can make it work nicely, but I just want to make sure I may not be overlooking something when I do the inter-site communication, security or performance wise. I've written some basic ajax before so I imagine it will sorta be a similar concept, except it will all be server side.

 

[purbeast0]

I am no security expert or auth/auth expert, but I would think your "central" server could issue some pub/priv keys to site A and site B, and when you have A/B authing a user on the central server, you could pass the cert along. Only the servers A and B will have this cert, so anyone trying to just hit the endpoint.

On the central server you could just make your own endpoints for the authorization that takes in whatever parameters you want, but make one of them the key that it passes along, and the central server can see if it's a match. If it is, you respond with the authorization info. If it's not, you respond with a forbidden response.

 

[Red Squirrel]

I am no security expert or auth/auth expert, but I would think your "central" server could issue some pub/priv keys to site A and site B, and when you have A/B authing a user on the central server, you could pass the cert along. Only the servers A and B will have this cert, so anyone trying to just hit the endpoint.

On the central server you could just make your own endpoints for the authorization that takes in whatever parameters you want, but make one of them the key that it passes along, and the central server can see if it's a match. If it is, you respond with the authorization info. If it's not, you respond with a forbidden response.

I was kind of thinking that too, essentially I would just POST a chunk of encrypted data, the script would then decrypt and process it. Keys/certs would be preshared. Since it would be happening over HTTPS I could probably skip encrypting the response as it would just be rather basic information that is not that sensitive like whether or not the authentication was successful, or list of accesses etc.

Or another option might be to just make my own protocol/server and it connects to another port. Then it would just be a full encrypted stream. Though probably easier to do HTTPS as php will have all the libraries for encryption already.

 

[Cogman]

There are a couple of ways to do this, how you want to accomplish it is really up to you.

I would suggest going with something like jwt. Give the user non-confidential session information on authentication, then just validate the jwt token and use TLS for the secure communication. Then when the user wants to access anything (or things want to talk with each other) you just forward along the jwt token and validate it at each step.

Barring that, I'd take a look here
https://www.postgresql.org/docs/9.6/static/auth-methods.html

With all the discussion on auth methods on postgres, it should get you thinking about the best way to auth within your own app. They have some nice summaries on the different methods and the pros/cons of using them. It also gives you some good jump off points.

 

[beginner99]

Personally I advise KISS. If there is no need to use different server (as in hardware / OS) for all the features, then don't do it. You don't now the future. It's better to deploy something now that works good and is simple to maintain so that people will actually use it. Also what does separating the servers make the system more future proof? You can get pretty powerful servers for pretty cheap nowadays. Vertical scaling can go very far.

If you insist on doing this because you want to learn or your management forces you to do so, then yes. https is a good choice to communicate between servers. Of course the authentication server should be configured to only accept requests from the forum and game server. This can also be easily deployed on 1 machine and in that case only localhost/127.0.0.1 gets access to the authentication API.

 

[sao123]

tieing your forum login to other services seems like a bad idea from a security standpoint.
Forums are heavily targeted for vulnerabilities and are slow to be patched, and could lead to your entire platform being compromised...
Perhaps you could have a master login, but that would transmit alternate (separate) credentials to each system (forum, page, game) based on a lookup, that way one being compromised doesn't compromise everything, unless of course they get the master login database.

 

[Red Squirrel]

Hmm yeah I see what you mean, though keep in mind the forum would not be storing any credentials. It would probably store it's own cashed session info only for the forum itself after a proper authentication takes place. Though I suppose a compromised forum could be setup to sniff for user passwords and then yeah it would be an issue for the entire platform.

One thing I also need to figure out how to do is to split up sites into "containers". Right now if one site gets compromised, all php scripts run as apache so that could then be used to compromise any other site. Every time I google this I just run into a bunch of solutions like phpsuexec and then it tells me it's deprecated. But there's got to be a way given shared hosts probably do it, so that php scripts run under whatever user the site is setup under. In general one thing I do need to do is up my security. I'd say right now it's probably average (ex: better than Equifax, but it could be better.

As for splitting it to different servers the reason I want to code it that way is so it gives me the option later without having to totally redesign it.

 

[beginner99]

As for splitting it to different servers the reason I want to code it that way is so it gives me the option later without having to totally redesign it.

Yeah but why do you need that option? It's a form of over-engineering.

If you do split each app should have an api the others, and only the others can use.

Hmm yeah I see what you mean, though keep in mind the forum would not be storing any credentials. It would probably store it's own cashed session info only for the forum itself after a proper authentication takes place.

The security server authorizes the user. All the forum should do is set a cookie with session id or similar technique. Since it is all https this safe enough (not safe in http!!!)

 

[Red Squirrel]

Yeah the forum is only going to send user supplied username/password (via HTTPS) to the auth server and get a yes/no response along with list of accesses. From there it will most likely use it's own session/cookie management where it occasionally rechecks auth server. Basically the auth server will most likely also dictate forum access so it's a central area to manage it. My permission system is also better than SMF's. 😛