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
You must be logged in to post messages in this topic!
