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.
Related
I am learning about SAML and already read many articles and forums but I still having confusion about setup IdP.
I am using "https://simplesamlphp.org/"
For example, I have 3 websites "example.com", "one.example.com", "two.example.com";
All are on three different server.
Now, I want to setup single sign on login using SAML then on which server I need to setup IdP.
As "example.com" is main domain which has all the information about user.
As I learn, when I login to "example.com" then it sends request to IdP.
But I don't get any idea where I have to set IdP and what Idp contains?.
Its on same server where "example.com" hosted OR its different server and what logic I have to write on that server?
It's simple login function OR I need to setup "simplesaml" for this and set login logic to there.
After setting up IdP, what I need to do on other server "one.example.com", "two.example.com"?
Do I need to install again "simplesaml" to both server and set SP and IdP?
In sort, which server has IdP and SP? And on which server I need to install "simplesaml"?
Thanks in advance
simpleSAMLphp is the IDP.
You don't need to write any code, just setup the config.
You will also have 3 SP = the three websites.
They can all be on the same server or you can have one server for the IDP and one server each for the websites. It doesn't actually matter.
The simpleSAMLphp web site shows you the changes you need to make to each of the SP in order to communicate with the IDP.
Identity provider is the one who supplies info about users. You'd create one, let's call it idp.example.com.
You'd install simpleSAML there and configure it so it can read info about your users, be it in MySQL, LDAP etc. (this is the tricky part with IdP setup).
Now, your websites would be service providers and if user isn't authenticated, they'd redirect the user to idp.example.com, user logs in, idp.example.com returns the user to service provider with the XML document containing assertions.
That means your SP needs to be able to consume the SAMLResponse which IdP sends to your site.
You can consume this with simpleSAML, which you'd configure in SP mode now.
Bear in mind that SSP (simplesamlphp) isn't the only option in PHP to deal with SAML. There's also Lightsaml - a proper library. SimpleSAML isn't just a library, it's a complete solution and quite honestly - a super SUPER terrible one at that, it's the epitome of crap code one can type out and make a system that actually works (much like wordpress).
TL;DR:
create an IdP -> idp.example.com -> configure or create the module that authenticates users against your user source (LDAP, ActiveDirectory, relational database etc.)
configure your 3 websites to authenticate using idp.example.com
configure your 3 websites to be able to consume responses from idp.example.com
It's all doable with simplesamlphp. If you want to take it further and implement or play with SAML on your own - you can use the library I linked. It'll take way, way, way longer to do it via Lightsaml library though since you have to take care of single logout and single sign-on, encryption, digital signatures, endpoints, metadata etc.
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.
We have an app hosted on our domain. All users are required to first log in through a POST form. Once login has happened, then form redirects to dashboard page on our site automatically.
Is it possible to allow some clients to host their own login forms (on their site), that POSTS to our app? Is cross-domain posting considered bad practise in any way? Are there any pitfalls to be aware of? And lastly, how is SSL taken care of given that our site always runs on HTTPS, but client sites may not? Can this be circumvented with an iframe?
What you are trying to reinvent is called openid.
What you need to do is provide a openid service, and then users can make there own login forms that connect to your open id server.
I have a great example of such a site: http://www.stackoverflow.com that uses google and others as openid service to log in, making there own login form.
What you're trying to do is generally referred to as Single Sign-On (SSO). This can be implemented using a variety of technologies.
The general idea is to separate the Service Provider (SP) (also sometimes called Resource Provider), which is what provides the actual service the user is going to use, from the Identity Provider (IdP), which is where the user's identity is verified.
The simplePHP library provides implementations for both IdP and SP authenticating layer using a number of SSO standards: SAML, Shibboleth (also SAML-based), OpenID, ...
Note that if you're using a standard, the IdP shouldn't need to be implemented using the same implementation as the one you've chosen for your service. It could be possible to have an IdP implemented in Java using the Shibboleth libraries and use it in conjunction with an SP that uses simplePHP, for example.
Which of these techniques you use will depend on the kind of information your require after authentication, for example if extra attributes are required, and how trust is managed between the IdPs and the SPs.
Typically, a simple OpenID system will be rather straightforward to integrate, from an SP point of view, but it will be quite limited in what it can assert about the user. In contrast, Shibboleth has a number of options to specify which SP can see which user attributes and what IdPs are meant to release or not, but it requires a more substantial infrastructure: this is typically done in a federation, where all the parties exchange a set of metadata configuration that comprises X.509 certificates they use to trust each others' assertions.
Since the authentication will happen outside your administrative boundaries, you can't really control how the users will have authenticated (unless this is part of a more formal agreement, such as in a Shibboleth federation). The OpenID provider could potentially let users authenticate over plain HTTP even if your service requires HTTPS. (This being said, most serious OpenID providers do it securely, and it's up to the user to pick one their trust anyway.)
Never embed the IdP page in your service: make the user go to a their IdP page instead. For an authentication system to be secure (as far as the user is concerned), it is essential that the user be able to see what they're typing their passwords in. By using an iframe, you would effectively hide the real site behind (and logos are easy to grab/forge). (The StackExchange OpenID provider has some problems in that respect.)
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'm managing a set of web apps, almost exclusively written in PHP, and would like to find an authentication platform to build a role-based authorization system on top of. Also, I'd like the authentication system to be extensible to use for, for example, system services (SSH, etc.)
Here are some of the main characteristics I'm looking for, in order of importance:
Easy PHP implementation (storing/reading easily roles, etc.).
Redundant, if possible. If an auth system goes down everyone is not locked out.
Has clients for Windows and Mac.
Easy web-based administration (adding/removing users/roles, changing passwords). If not, I can build an administration system without too much effort.
One-time log on.
I'd also like, when an auth token is issued, to store the user's IP address and use that to authorize the user for some non web-based applications. For that reason, I'd like a desktop client to issue the token and revoke tokens when, for example, the user becomes idle at their workstation.
I'm thinking Kerberos might be a solution, but what are other options?
If I were doing this, which I actually have at several points in the past, I would use a combination of Kerberos and LDAP. Kerberos handles authentication and provides users with tokens. LDAP provides authorization; information about group membership, user contact information, etc.
Kerberos is very, very well-tested and widely deployed. To protect a web application with Kerberos, use Apache's mod_krb5 or a solution like Stanford WebAuth. The user authenticates once to Kerberos and then their browser will use the ticket via SPNEGO to automagically log them in to the web application. If you have a Windows Active Directory Domain, then your users already have Kerberos tickets you can use from their computer login session!
Kerberos is also supported in many other network server programs, such as OpenSSH, various IPSEC VPN tools, email (both SMTP and IMAP), XMPP (Jabber) chat, etc etc.
A Kerberos infrastructure can be as redundant as you like, and organized however you like. Realms can have many servers providing authentication, and can trust eachother in arbitrary ways.
It's not just a solution, it's the solution for single signon.
What you're looking for is (essentially) a Lightweight Directory Access Protocol (LDAP) server/client setup. PHP has a built in library, it's easily redundant, has clients for windows/mac/linux, front ends are available (though I can't recommend any good ones at the moment) and it'll provide authentication to any set of applications you want.
While there are some additional pieces you'll need to put in place to achieve exactly what you want, LDAP sounds like the framework you should start with.