Forums / Developer / Single Sign On Active Directory

Single Sign On Active Directory

Author Message

Michael Hall

Monday 03 March 2008 4:47:00 am

We're considering implementing an eZpublish intranet built on a RedHat server, located on a Windows 2003 Network. Current intranet solution is IIS/VBscript/.NET.

Management have made it clear that single sign on has to stay. Meaning that once a user logs on to a computer, no further logins are required to access the intranet.

Just as importantly, we need to be able to build a profile of that user (eg name, groups, email address, preferences) out of AD, probably using a Kerberos UPN or similar as user ID.

Also, we don't want to have to replicate and maintain a user database/directory separate from Active Directory.

I'm aware of the various technologies and HTTP server requirements involved (Kerberos, LDAP, mod_auth_kerb etc).

I'm wondering if the SPNEGO Integrated Windows Authentication described here ...

http://ez.no/developer/open_funding/suggestions_for_new_functionality/signal_sign_on_active_directory/we_ve_done_something_similar

... does this, or comes close? Has anyone had any experience with it?

Gaetano Giunta

Monday 03 March 2008 10:43:15 am

The most annoying drawback of using sso with apache auth and spnego is the fact that auth is not controlled by php anymore but directly by apache.

This means eg. that it is quite hard to have an intranet site that can be browsed at the same time by authenticated users or by anonymous ones. If apache sends the kerberous auth challenge to the browser and the browser does not have an ad ticket, it will pop up the password dialog to the end user without php ever having had a chance to intercept any request.
If otoh all your clients are authenticated, this is not a big problem.

The spnego extension you mention can be of use (in fact it is a very general mechanism that can be used with any apache based auth, not only with spnego or ad), but it only tackles the 'recognizing an authenticated user' part. You should add extra effort in eg:
- disabling user/logout and user/login views
- either importing your ad users into ezpublish via batch processes or making sure they are imported on-demand at the time of their first login (it is quite hard right now to have eZ Publish working with a 100% external user base. Most of the external auth solutions rely on still having a user object inside eZ for every external user)
- mapping permissions/group membership from AD into eZ Publish. The ldap user php class that is provided in the standard eZ distribution is probably more interesting in that aspect

Principal Consultant International Business
Member of the Community Project Board