I've attached a package that allows users to be authenticated to matrix based on $_SERVER['REMOTE_USER']. It's basically a hack that allows you to off load user authentication to Apache. The advantage of this is that matrix can then support any authentication method that Apache does and users only need to login once if you have applications outside of Matrix.
In our case we've used it to implement single sign-on against active directory using kerberos. It means that most users only need to login to their computer and they are automatically logged into Matrix.
USE THIS AT YOUR OWN RISK.
uts_lib.tar.gz (5.46 KB)
Fantastic, Richard.
Could you point me in the direction of some good documentation to configure Apache to do the Kerberos single sign-on? I've only really found Samba-based authentication stuff.
Edited to ask: What version of MySource Matrix was this written for? The files mention v3.1 RC2 which is exceptionally old. 
Another person here set up Apache & Kerberos. You might like to try
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/http-sso-1.asp
and
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/http-sso-1.asp
I nearly forgot your question about the version. For 3.1RC2 we wrote a simple ldap authentication asset. It authenticated local (matrix) users from an LDAP server. We did this because our DN's changed too often to use the LDAP bridge.
I used that code to create this new asset. From what I could tell there weren't too many changes but I'm probably wrong because I got lots of errors during install/step_03.php. I found this strange because the original asset code is still there and didn't create any. As it worked once installed I didn't pay too much attention.
We are currently working to encorporate HTTP based authentication into the Matrix core based on $_SERVER['REMOTE_USER']. When completed, it will not require a new authentication system but will instead allow existing authentication systems to validate on username only (if requested).
The login box will also be suppresed if authentication is successful.
The idea for this had been floating around for a long time, but we didnt think real SSO could be achieved with it, so it was put on the back-burner.
Hi Greg,
That's basically what I found. I made a couple of changes to the core matrix so it would accept the username via $_SERVER['REMOTE_USER'] if it didn't look like credentials were being posted. The rest of the work is done in the remote user authentication asset (but could have been done in the default one).
If you're looking at building this into matrix you might like to make sure you provide a way for people to log into the web server as one user and matrix as another. I know I always authenticate to the web server using my normal username but I may want to log into matrix as another (i.e. root). That's why if it looks like credentials are being posted then my solution uses those instead of the REMOTE_USER.
My solution also effectively hides the login box from the user. The login design contains some javascript that redirects the user to the same page with ?SQ_ACTION=login if there are no parameters. This means that when I first access a sight I'm automatically logged in as me but I can then logout, get the login screen and authenticate as root.
To make true single sign-on work for IE6 make sure you check the security option "Enable Integrated Windows Authentication". The day we switched to SSO we discovered that most of our computers didn't have this checked by default so those users got pop-up windows.
Richard
Nice point about checking for posted credentials rather than always using REMOTE_USER if it exists.
I guess the login design should be suppressed unless the SQ_ACTION is set to logout, at which point you are asking for the ability to log in as another user.
This all sounds very interesting - is this going to solve the issue of unified logins to external systems? For example a customer may have matrix logins for their clients to access extranets but this should also provide a bridge to other services that the client supplies post login eg. Access to Saleforce Self-service support portal (SSP)
It's generally uncool to force people to login twice - I know it's not a problem to "wrap" the SSP with Matrix but it's the unified login that may be the tricky bit … ?
If you have all of your applications on the same site and they all use the web server for authentication then yes.