I am building a PHP application and would like to lock the backend (even login page) to only be accessible to preauthorized people - even further be able to link activities to the authorized individuals.
I am aware that such locking may be done using SSL or a certificate of sort but not sure what it is exactly or how to achieve it. I have seen different companies implement it in ways as mentioned below
At one company, A user fills in a form with details and the company issues a certificate that the user installs on the browser in order to access the backend
Another company, A user is given an exe to run each time they want to access the backend.
My PHP application is running on windows server 2016 and I would like to know how to achieve both or either of the above. A resource or specific would be appreciated.
I am not sure if this question is right here or another Stack Exchange
Network, kindly forgive my ignorance.
First of all:
Do not cross post on different networks.
Secondly, the way to do this is to supply client certificates from another web app that are accepted by the app you're developing. Key words for research are: TLS, client certificates, certificate based authentication.
Related
slightly losing my mind here and I would really like some help to get me pointed in the right direction.
I'm using a shared Linux server on GoDaddy where I have two PHP websites with separate user logins authenticating with two separate MySQL databases. What I'd like is for a user to log into Site 1 and then be automatically logged into Site 2. And when they logout out of either site, they should be logged out of both sites.
I currently have SimpleSAMLphp installed and I'd really appreciate some guidance on how to setup the IdP and SPs. Am I right in thinking that the Site 1 and Site 2 are the SP's?
Any guidance would be greatly appreciated, this is my first ever SSO setup and I'm just a little lost.
To implement single sign on you need somthing common in both website to authenticate. Cookies won't help as there are two different site and it is not good to expose your cookies to a another website.
In general, SSO is implemented using a central serevr basically which handles the authentication data.
Basic steps are as follows:
For login, user is redirected to the common server and credentials get verified.
Central server sets the cookie for the login.
When your other website needs a login it checks the central server again using redirection.
Then, central server check the cookies and authenticates or redirect to login if not aythenticated before.
So, you can configure a central authentication server which check authentication and provide the appropriate response and both websites handle it accordingly.
But, Central server needs a common user database which in your case you clearly lack. So you can declare one of the websites as central or principle resource and expose APIs for other website which will expose its user base to verify the details.
Let one website handle the login process. If other needs authentication to be done it will redirect user to the main website and then handle the return response.
There is a lot to cover in theory but hope it would help.
Useful links:
Building and implementing a Single Sign-On solution
Basics of Single Sign on (SSO)
I am looking to build an API that I can deploy on my servers to monitor system load.
It will report to a central manager server that runs a client to display the information.
The issue I am struggling with is best to secure the API.
What I want is for the client to be the only software that can access the server and retrieve this information but I am unsure how to achieve this using PHP.
I also want the possibility of distributing the API and client for others to use on their servers so I don't want people to be able to access other people data if they are using the API also.
The client is also written in PHP using MySql and has a secure login.
This sounds like you're trying to solve the wrong problem.
I also want the possibility of distributing the API and client for others to use on their servers so I don't want people to be able to access other people data if they are using the API also.
The only right answer to this is authentication. You need to protect your API by giving each user access credentials known only to them.
Your API must never reveal any data that the client isn't allowed to see as per their authentication credentials. Trying to work around this danger by trying to somehow protect the client from prying eyes is not safe - somebody who has access to the client and can observe it running will be able to reverse engineer any traffic between it and the server given enough effort.
If the API is properly secured, it won't matter to you which client tool is used to access it. The requirement to limit API access to a certain program will go away.
if you use SSL, along with authentication (i use 3rd party auth google, fb, etc), create data /reports on the fly and have the data saved in a subdirectory OUTSIDE your web folder (instead of /var/www, /var/myStorage/currentSessionId/), then you basically guarantee the security that you want.
your php will only access a subdir that is named for the session it is running under.
We've been developing a web application (PHP, using the Yii PHP framework) that is going to be used for data entry. The clients will be users from both the LAN and WAN (many of the remote clients will be behind a proxy, reaching our network using one IP address with NAT). What we basically want is to guarantee the validity of data in the way that no malicious user alters it.
Is there a way to programmatically identify each client in a unique way, so that I can guarantee (at least at some good percent) that no malicious remote user will connect? We were thinking of gathering the MAC addresses of all remote users and using a (non-web) client that generates a hash string that the user will input in the web application and then proceed if this authentication scheme passes. As I said, using other non-web applications for the remote client is an option.
Is such a solution as the one I describe above viable? Should we see other solutions, like maybe a VPN?
A VPN is a typical solution to the problem of locking out everyone except those you've explicitly given access --- basically you're rejecting all connections to the site that aren't authenticated in your local network or vpn. That way you dont have to write any funky logic for your actual web application.
I think this is an ideal solution because it allows the application to be maintainable in the future when other developers step in... furthermore it will require less of your developers and will ultimately keep costs down.
Normal user authentication is generally OK, but if you have higher security needs you can provide clients X.509 certificates to install in their browser. VPN is of course an option but you just move authentication problem from website to network vpn.
What you are looking for are the SSH-Key pairs:
https://help.ubuntu.com/community/SSH/OpenSSH/Keys
There are much more ressources on this, the theory in brief:
Each client creates a pair of unique keys, a private and public one. The public goes onto your server, the private stays with him. Then the client uses the key to authenticate. The server calculates a valid public key from it and checks if you have such a key in your system. If a pair is found - authentication was successful. (I never used this so far for Web authentification)
Additionally you could use OTP (One Time Password) technology. Since it is normally bound on per-account basis it will be very secure:
https://github.com/lelag/otphp
I am writing the spec for a complex business solution; it is basically a set of web apps that are all on their own servers. I want them to be independant so if one has a problem or becomes very busy then the rest are not affected.
There will be a central server that will act as the payment gateway for the apps as well as providing data to the apps themselves. The data is minimal; user ids, have they paid for that app etc.
The idea was that when an app was purchased then we'd just pass that data to the app in question.
The question is how to do this while not holding up the user's experience while we wait for the app server to resoned. The idea was to enter it into a queue and process them one by one on a cron job. However there are concerns that this will not be fast enough and the user could have to wait before accessing the app.
The other idea is that the app just contacts the main server when the user tries to use it. The main server can then approve the user and this will be kept on the app server DB so it doesn't have to check again.
What do you all think about these ideas? Is there an obviously best way of doing it?
The system should be able to scale to 100+ apps and tens of thousands of app purchases an hour.
Very interested to see what you all think! Many thanks
I have a similar but slightly different situation here, supporting a potential competitor... have I gone mad?? haha
To the topic, we use cURL to connect the server requests generally, especially if we don't want information to be public, we have a specific VPS set up for payment handling, account functions and financial functions, this will post to a centralized mySQL database for access information only so it will support a single sign on for multiple apps on multiple server clusters.
To ensure the user is immediately moved to the app they want and it works correctly, we use cURL to post initial data creating the default records in the specific app database, we then set up a PHP header redirect using to move the user to the app requested with the single sign-in already working as part of the cURL post preformed earlier.
An access key is important to us as it enables the single sign-on to be secure. It is generated 1 time per account and never updated even though we can if there is ever a security violation. We then use cURL in the user auth process to ensure the user is still signed in using their key and user id. The key is never actually passed publicly but always posted server side using a cURL method hiding it in the PHP.
I hope this helps.
What would be recommended as an authentication solution for a Software-as-a-service product?
Specifically, my product would have clients that would typically have low information technology skills, potentially not even having an IT department within their organization. I would still like to have my application authenticate against their internal directory service (eDirectory, Active Directory, etc.). I don't want them, however, to have to open/forward ports (for instance, opening up port 636 so I can do LDAPS binds directly to their directory service).
One idea I had was to have an application installed on a server within their organization's network that would backconnect to my service. This would be a persistant socket. When I need to authenticate a user, I send the credentials via the socket (encrypted) - the application then performs a bind/whatever to authenticate against the directory service and replies with OK/FAIL.
What would you suggest? My goal here is to essentially have the client install an application within their network, with very little configuration or intervention.
This vendor, Stormpath, offers a service providing exactly what you are asking for: user authentication, user account management, with hookups to your customers’ on-premise directories (if need be, as is your case).
I think in your case, it'd be necessary to drop an agent on to their network which performs the authentication locally, then creates a signed token which "proves" to your SaaS app that it has done so; this can be passed on by the browser in a query string or form post (for example).
The agent might be an IIS-installable web app which can just authenticate the user and then direct them on to your servers in the cloud. This should not be a major hassle to install, but will create tech support issues. In particular, you need to get this component right first time, as users are not going to update it on a regular basis.
Making it work securely may be interesting.