How can I implement single sign-on (SSO) using Microsoft AD for an internal PHP app?

Question

I'm vaguely aware that on a computer joined to a domain IE can be asked to send some extra headers that I could use to automatically sign on to an application. I've got apache running on a windows server with mod_php. I'd like to be able to avoid the user having to log in if necessary. I've found some links talking about Kerberos and Apache modules.

http://www.onlamp.com/pub/a/onlamp/2003/09/11/kerberos.html?page=last https://metacpan.org/pod/Apache2::AuthenNTLM

Since I'm running on Windows it's proven to be non-trivial to get Perl or Apache modules installed. But doesn't PHP already have access to HTTP headers?

I found this but it doesn't do any authentication, it just shows that PHP can read the NTLM headers. http://siphon9.net/loune/2007/10/simple-lightweight-ntlm-in-php/

I'd like to be able to have my users just point to the application and have them automatically authenticated. Has anyone had any experience with this or gotten it to work at all?

UPDATE Since originally posting this question, we've changed setups to nginx and php-fcgi still running on windows. Apache2 and php-cgi on windows is probably one of the slowest setups you could configure on windows. It's looking like Apache might still be needed (it works with php-fcgi) but I would prefer a nginx solution.

I also still don't understand (and would love to be educated) why HTTP server plugins are necessary and we can't have a PHP, web server agnostic solution.

Solution 1

All you need is the mod_auth_sspi Apache module.

Sample configuration:

AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIDomain mydomain

# Set this if you want to allow access with clients that do not support NTLM, or via proxy from outside. Don't forget to require SSL in this case!
SSPIOfferBasic On

# Set this if you have only one domain and don't want the MYDOMAIN\ prefix on each user name
SSPIOmitDomain On

# AD user names are case-insensitive, so use this for normalization if your application's user names are case-sensitive
SSPIUsernameCase Lower
AuthName "Some text to prompt for domain credentials"
Require valid-user

And don't forget that you can also use Firefox for transparent SSO in a Windows domain: Simply go to about:config, search for network.automatic-ntlm-auth.trusted-uris, and enter the host name or FQDN of your internal application (like myserver or myserver.corp.domain.com). You can have more than one entry, it's a comma-separated list.

Solution 2

I had a similar problem which I needed to solve for my organization.

I was looking into using adLDAP.

There is some documentation on the site for achieving seamless authentication with Active Directory too.

Solution 3

I'd be curious about a solution that uses OpenID as a backend (of sorts) for this... I wasn't seeing anything that would hook into ActiveDirectory directly when I googled (quickly). However, it could be pretty painless to implement over plain HTTP(S) (you'd be an OpenID provider that checked credentials against your local AD). In a best case scenario, you might be able to just add a couple classes to your app and be off and running -- no web server modules required. There is a lot of open source code out there for either side of this, so if nothing else, it's worth taking a look. If you exposed the backend to the users (i.e. gave them OpenID URLs), you'd have the added benefit of them being able to log in to more than just your internal sites using these credentials. (Example: Stack Overflow.)

As an aside, I'd be against making it so that Internet Explorer is required. I'm not sure if that is the goal from the way you wrote the question, but depending on your IT environment, I'd expect people who use Firefox or Safari (or Opera or ...) to be less than enthusiastic. (You're not developing against IE first, are you? That's been painful whenever I've done so.) This is not to say that you couldn't use this feature of IE, just that it shouldn't be the only option. The link you posted stated that NTLM worked with more than IE, but since I don't have any experience with it, it's hard to judge how well that would work.