Integrated Authentication Method

[smiller]

Hi guys

 

I've come up with a method getting Windows Integrated authentication running with PHP. I wanted to get some feedback on the method to see if there's any major security holes.

 

Firstly some background. I'm well aware that if you want Windows Integrated Auth, you're better of building your application in ASP.Net. But the particular set of circumstances I'm in forced the architecture on this.

The client has an accounting-related system available via SharePoint to the general staff. Initially it was a simple system, but over time it has grown and grown and grown and is now a little too complex to manage effectively. It ties together several InfoPath forms, each of which have several SQL secondary connections (which are quite when being used as filter values in repeating tables), several workflow, multiple Approval tasks and more. The architecture is a mess.

 

They wanted it re-built as a custom system, but absolutely had to have the integrated authentication continue. They wouldn't accept a separate login box. Unfortunately I only know PHP, my ASP/ASPX knowledge is next to 0. So the first challenge to solve is getting integrated authentication running on a PHP system.

 

The high-level overview of the system is:

 

- Clients initially land at index.php. This page checks to see if there is a $_SESSION variable called 'user'.

- If not found, this page loads a randomly generated ID into the database called 'authToken' and then redirects (via die(header(login.aspx?authToken=X&returnPath=thispage))) to an ASPX page called login.aspx

- This ASPX page is hosted on an IIS site with Integrated Windows Authentication as the only method of authentication

- The login.aspx page takes the users login name (via Request.ServerVariables("AUTH_USER") and places it into a hidden form control, along with the authToken and returnPath.

- The form on login.aspx is set to POST to a new PHP page called session.php

- Some JavaScript on login.aspx submits the form automatically on page load

- Session.php receives the psot from login.aspx, and retrieves the three variables (username, authToken and return path)

- If it cannot find a matching authToken in the database, session.php errors out (to prevent someone hacking in by coding up their own page that posts to session.php)

- If it does find a matching authToken, it deletes the authToken from the database, places the username in $_SESSION['user'] and then returns to the parsed return path, which is usually index.php

- Index.php can now see $_SESSION['user'] and continues on happily. One of the first things it does is use an ldap search to find the full name, given the username

 

Known Strengths

- The ASPX page can be hosted on a different web application (within IIS) or a different web server on the same host or even on a separate server. That gives a lot of flexibility

- The return path is set from $_SERVER['url'] so this works no matter what page in the site the user lands on (except for session.php of course)

- This works internally and externally via and ISA rule with FBA

 

Known Weaknesses

- JavaScript is required for the ASPX page to POST-back. I'm looking for a more elegant solution around this, but as the clients all use SharePoint this isn't a problem for this particular instance

 

The use of the authToken negates, I think, any security vulnerabilities. But as I said, I wanted to have some smarter people than me take a look at this solution and tell me if there's something bad that I'm missing.

 

Any comments or feedback are welcome

 

Regards,

Sam Miller