Chattanooga
Unix
Gnu
Android
Linux
Users
Group

 

Hot Topics:

Sponsoring:

Access Control for LAMP

From: Eric Wolf 
------------------------------------------------------
OMG! An honest-to-goodness Linux related post to CHUGALUG!

A client of mine has a series of LAMP applications running on the same
server. They currently manage access control through separate htaccess
files and giving out the URLs on a per customer basis.

I need to implement a unified login across all their apps but it would be
nice to not have to modify a bunch of code. Ideally, the system would have
a central username/password (maybe even OpenID) and present a menu of apps
available to that user. Access to the other apps not available to the user
would be restricted even if the user worked out the URL.

The solution needs to pass basic security audits by IT flunkies at
reasonably large non-tech companies.

Any thoughts? Tricks? Etc?

-Eric

-=--=---=----=----=---=--=-=--=---=----=---=--=-=-
Eric B. Wolf                           720-334-7734

=============================================================== From: Dan Lyke ------------------------------------------------------ On Fri, 5 Oct 2012 10:58:40 -0600 Eric Wolf wrote: Something that won't necessarily work: Links that embed the existing username and password combos. It seems like a really good idea to have a centralized login scheme that then sends users off to http://username@passwordtoken:server/internalapp and this works absolutely swimmingly on Firefox and Chrome, but IE won't do it unless you do some registry hacks. Which sucks. So, yeah, my first response was "centralized OpenID thing that manages .htaccess files and funnels users off to URLs that automatically log in to the existing apps", but when I actually tried to implement that... Turns out Microsoft thinks RFC 1738 is for losers. Dan

=============================================================== From: Eric Wolf ------------------------------------------------------ I thought about an htaccess manager too, so I'm glad you tried this before and found the glitch. Unfortunately, the customers here use IE almost exclusively. -Eric -=--=---=----=----=---=--=-=--=---=----=---=--=-=- Eric B. Wolf 720-334-7734

=============================================================== From: Mike Harrison ------------------------------------------------------ 1. using .htaccess files is a crude and nasty nasty way to do this. Works, but even I stopped doing in circa 199x? 2. Basic/Simple auth over SSL (never plain text/http) is a great first step. -1. Session ID based auth can be snarfed, captured, abused. I actually do this with permission on a couple of "smart grid" systems faking logins, getting the cookies, and then abusing that credential. My fear is that it is snarfable from user space in a browser (cookies) and is not rechecked for validity. I have seen systems where the cookie is good for days+ even after the user has been denied access or had permissions/access changed. As this is SSO across multiple apps/(possibly servers) the trick is the ability to modify code in each system to support whatever it is you do do. A central system could easily be used to provide auth services if you can modify or hock into the current systems. kewl thing about basic auth, if done right, the can auth at one level and it will maintain their creds "down the path" in the browser. ie: login/auth first at: https://acme.foo.com/app acme as a hostname is the hostname, and could relate to a customer grouping or not. we use this a lot to group customers, manage look and feel, etc.. /app is a common top level directory. You can also auth at the root of the hostname. Then that exact same set of credentials is automagically used for everything at that level or below: https://acme.foo.com/app/widgets/.... through separate htaccess files and giving out the URLs on a per customer basis. 

=============================================================== From: Mike Harrison ------------------------------------------------------ https. Always https. and you never do that with microsoft systems, that URL gets logged and cached in interesting places that trojans go looking for. And it won't work with MSIE because they were comprimised so many times with such things. I forgot when the turned it off, but it was in response to it being abuses a lot.

=============================================================== From: Mike Harrison ------------------------------------------------------ basic auth works well with MSIE browsers, you just can't use the URL format against other systems with it. and really should not anyway. If they are part of the same domain it automatically gets passed to the subdirectories.

=============================================================== From: Sean Brewer ------------------------------------------------------ http://i.imgur.com/u0YA2.jpg

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is how I implement login to all my http code now. I use a database on the back-end, and my schema includes group memberships, although I'm not 100% certain I have actually implemented permissions based on group membership, although I do have an article bookmarked. I should also define "all my http code", which so far in the past two years has consisted of two small database apps. Ugly as sin (I'm not a front-developer, I like text too much) but functional. Apache configured to deny access in the non-SSL vhost, and the SSL vhost requires basic-auth. Regards, dtb - -- "Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network." RFC 1925 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBvPPMACgkQABP1RO+tr2QLZwCeIVKS3B+bPIsrL4HrvjRgzTGB 5YQAni0JK6zJS2MF2JumexOyquqLB++9 =5hvX -----END PGP SIGNATURE-----

=============================================================== From: Billy ------------------------------------------------------ What about two way ssl? You could do that on a virtual host basis. It would be an all or nothing thing. There might be a need to modify an apache module to centralize the auth and perhaps do something using saml or other types of encryption over cookie schemes.

=============================================================== From: James Nylen ------------------------------------------------------ Actually this works pretty well for my personal server. Here is my setup: - master password file containing all users and their hashed passwords (in htdigest format) - set of shell scripts that slice and dice this file as needed for each service, and create per-service htdigest files - front-end for the shell scripts and files that helps me see who has access to what, and lets me manage everything pretty nicely - htaccess files containing a common "auth" section, each pointing to a different digest file created by the scripts above Rather than having to ensure that my applications all use the same auth code, and that I am smart enough to make that work correctly, I just have to copy a small section of a .htaccess file to each application, and let Apache handle it. It would be a small step from there to parse the lists of users and provide a "portal" to logged-in users (actually a pretty good idea that I will try to work on). What do you see as the drawbacks of using .htaccess files for authentication? I feel like this system addresses most of them. 2. Basic/Simple auth over SSL (never plain text/http) is a I agree, but I have a few services that should be accessible by http (to avoid self-signed cert errors), so I use digest auth, with some stupid workaround for IE6. Works for me since I never have any reason to support IE5.x or older.

=============================================================== From: Mike Harrison ------------------------------------------------------ James, digest mode is not encrypted. it is encoded. --Mike--

=============================================================== From: Mike Harrison ------------------------------------------------------ If your only concern is auth, and everyone has the same levels, it works. Just better make sure thos .htaccess files don't get munged/deleted/etc.. Doing in code allows you to easily apply rules and logic to the auth, such as allowed ip addresses, velocity detection (blocking an IP after XX bad logins), blacklisting, http referrers, agents, time of use, password change rules, allowing users to change passwords (without shelling a command to update a .htaccess file that should only be writable by root), which SSL client certificate can be used.. Doing in code also can be used to tie user attributes to those credentials. security levels, access to specific functions, etc... Digest auth is not encrypted, just Base64 encoded. Self-signed cert errors are preferable to plain text. It is easy to add them for applications people often use. Suggestion: Grab TinyCA2 and setup a certificate authority, use client certificates as one of the factors for authentication if you want to do some really fun stuff. --Mike---

=============================================================== From: Dave Brockman ------------------------------------------------------ Grab XCA if you need a GUI, it works on Win & *nix. Regards, dtb