HOWTO use Zope and IIS together in remote user mode

Created by . Last modified on 2003/08/01.

Notes (2000/05/25)

• you have to install the jcNTUserFolder before you put Zope in REMOTE user mode.
• zope in its current form can't handle REMOTE user authentication mode together with standard authentication mode. When you install Zope as as pcgi process to get through IIS, it is the only way to be authenticated and get, for example, to the management screens. When you install jcNTUserFolder as the root user folder, you have to choose the NT user that will be mapped to the super user. The first time, you have to log with that user. Note that this super user needn't be a privileged one under NT.

HOWTO use Zope with IIS in remote user mode

Note: my native language is not English and writing in english is a time consuming task as far as I'm concerned. So the howto has been written in french, and I attempted to translate in english afterhand. If someone can provide a better translation, he is welcome.

• Lire le HOWTO, en francais
• Read the HOWTO, in english

HOWTO (in french)

Introduction

Zope détache la gestion de l'authentification (qui est l'utilisateur?) et de l'autorisation (que lui est-il permis de faire?). Quand Zope tourne avec un serveur web par exemple avec un wrapper PCGI, il peut fonctionner dans un mode appelé remote user mode, ou il délègue la gestion de l'authorisation au serveur web. Ceci est pratique quand la gestion utilisateur a déjà été mise en place, ou que le serveur web utilise une méthode non standard pour authentifier l'utilisateur (comme IIS par exemple).

Ce document explique comment interfacer Zope et IIS de façon qu'IIS gère l'authentification des utilisateurs. De cette façon, l'on peut configurer IIS pour utiliser le mode d'authentification par stimulation/réponse (qui est censé être plus sûr) pour la sécurité, et Zope pour la puissance...

Authentification sous Windows NT

Avant d'aborder l'interfaçage avec Zope, il faut comprendre comment fonctionne l'authentification sous Windows NT.

Quand un utilisateur ouvre une session sur un serveur NT, il doit fournir un nom d'utilisateur, ainsi qu'un nom de domaine par rapport auquel il faut être authentifié. Ce nom de domaine est soit le nom du serveur NT, auquel cas il s'agit d'une ouverture de session locale sur le serveur et donc ce serveur doit effectuer l'authentification, soit un nom de domaine dans lequel se trouve le serveur NT, auquel cas l'authentification est effectuée par le controleur principal de domaine ou par un controleur secondaire.

Ainsi, le serveur NT a besoin de savoir sur quel domaine l'utilisateur veut ouvrir une session pour savoir quel serveur effectuera l'authentification. C'est pour cela qu'en interne, un utilisateur sous NT est en fait écrit sous la forme DOMAINE\Utilisateur. Notez que le nom de domaine et d'utilisateur n'est pas sensible à la casse.

Interfaçage de Zope avec IIS

Pour interfacer Zope avec IIS en utilisant PCGI, suivez les instructions de brianh à l'adresse http://www.zope.org/Members/brianh/iis_howto. Cependant, ne désactivez pas l'authentification par stimulation/réponse de Windows NT. Ceci permet à IIS d'utiliser une méthode sûre pour authentifier l'utilisateur. Et comme de toute façon Zope ne s'occupera pas de l'authentification, autant utiliser ce que IIS a de plus sûr.

Dans le gestionnaire de services internet, cliquez avec le bouton droit sur Zope.cgi, affichez les propriétés, et dans l'onglet sécurité de fichier, cliquez sur modifier le contrôle d'authentification. Vous devez:

• Désactiver les connexions anonymes. Si vous voulez vous assurer que seuls les utilisateurs du domaine puissent utiliser Zope. Il y a aussi l'avantage que l'on saura à tout moment quel est le nom de connexion de l'utilisateur qui utilise Zope. Si vous voulez autoriser les connexions anonymes, cochez la case. Notez que si vous désactivez les connexions anonymes, cela ne vous oblige pas à donner des rôles autres qu'Anonymous dans Zope. Les utilisateurs ne doivent pas être anonymes vis à vis de IIS, mais peuvent continuer à avoir le rôle Anonymous sous Zope.
• Décocher authentification de base, sauf si vos utilisateurs utiliseront des navigateurs incompatibles avec l'authentification par stimulation/réponse de Windows NT, comme Netscape Navigator par exemple. Actuellement, seul Internet Explorer à partir de la version 3.0 supporte cette méthode d'authentification
• Cocher l'authentification par stimulation/réponse de Windows NT pour une sécurité maximale, et si les navigateurs utilisés par vos utilisateurs supportent cette méthode.

Notez qu'il faut qu'au moins une des méthodes d'authentification soit cochée, sinon cela signifie que Zope doit gérer lui-même l'authentification, ce qui n'est pas ce que nous voulons.

Notez que cette configuration se fait fichier par fichier dans le gestionnaire de services internet, et donc qu'il n'est pas nécessaire de modifier les paramètres pour tout le site.

Sauf si vous avez désactivé les connexions anonymes, vous devez pouvoir à ce niveau accéder aux ressources non protégées de Zope.

Comment fonctionne l'authentification

Si l'on essaye d'accéder à une ressource protégée, Zope renvoie un en-tête HTTP 401-Unauthorized. IIS s'engage alors dans un dialogue avec le navigateur web pour essayer d'authentifier l'utilisateur.

Notez que Zope n'est à aucun moment engagé dans ce processus. Tant que l'utilisateur ne s'est pas correctement authentifié (nom et/ou mot de passe incorrect), IIS continue à dialoguer avec le navigateur.

Quand l'utilisateur s'identifie correctement (nom/mot de passe correspondant à un utilisateur valide sur le domaine spécifié), et que cet utilisateur a les droits pour accéder à Zope.cgi sur le serveur, alors Zope est lancé avec l'information sur l'utilisateur qui se présente dans la variable REMOTE_USER.

Notez que cette information est sous forme canonique, c'est à dire DOMAINE\Utilisateur. Zope cherche ensuite cet utilisateur dans sa propre base d'utilisateurs (super utilisateur, contenu des User Folders), et vérifie les rôles de cet utilisateur. Si cet utilisateur n'est pas trouvé (auquel cas il obtient le rôle Anonymous), ou si ses rôles ne correspondent pas aux exigences pour accéder à la ressource protégée, Zope renvoie l'en-tête HTTP 401-Unauthorized au serveur web, et le processus d'authentificatin recommence.

Notez donc que l'authentification se fait en deux temps:

• d'abord l'utilisateur doit exister sur le domaine et il doit avoir les droits sur la ressource Zope.cgi pour que l'authentification puisse se faire par IIS
• puis l'utilisateur doit exister dans Zope sous forme canonique pour que des rôles puissent lui être attribués.

Configuration de Zope en mode remote user

Il faut configurer Zope pour qu'il passe en mode remote user. ceci se fait en supprimant le mot de passe du super utilisateur dans le fichier access du répertoire d'installation de Zope. Par exemple, si ce fichier contient:

        superuser:password

Il faudra le remplacer par:

        superuser:

Attention! La documentation de Zope précise qu'il faut que l'utilisateur superuser existe au niveau du serveur web, en l'occurence IIS.

Et c'est là qu'est le problème. Zope est sensible à la casse pour la gestion des utilisateurs, alors que IIS ne l'est pas. Heureusement, IIS envoie toujours les informations utilisateur sous la forme DOMAINE\Utilisateur. Le domaine est donc en majuscule, et Utilisateur est la copie conforme de la définition faite dans le gestionnaire des utilisateurs sous NT. Ainsi, si l'utilsateur MikeP est créé sous NT dans le domaine wild_west, et que l'on veut que cet utilisateur soit le super utilisateur, il faudra que le fichier access contienne:

        WILD_WEST\MikeP:

Redémarrez Zope après avoir fait cette modification.

Création des utilisateurs sous Zope

Comme dit précédemment, Zope est sensible à la casse. Si un objet UserFolder classique est utilisé pour gérer l'autorisation des utilisateurs, ceux-ci doit être créé sous forme canonique dans le UserFolder si l'on veut pouvoir leur donner des rôles.

Il y a aussi possibilité d'utiliser un UserFolder tel que NTUserFolder de htrd ou jcNTUserFolder de jephte. Je ne sais pas pour NTUserFolder, mais jcNTUserFolder n'est pas sensible à la casse, ce qui résoud le problème. C'est pour permettre de saisir le nom du super utilisateur indépendamment de la casse que jcNTUserFolder demande le nom de l'utilisateur NT qui fera office de super utilisateur lors de sa création.

Résumé

En résumé, voici les étapes à franchir pour interfacer Zope avec IIS en mode remote user:

• En suivant les instruction de brianh, interfacer Zope avec IIS avec PCGI.
• Choisir la méthode d'authentification utilisée par IIS: de base ou par stimulation/réponse de Windows NT, en fonction des navigateurs clients. Il est possible de choisir les deux, auquel cas les deux types de clients (compatibles et non compatibles) peuvent naviguer sur le site web.
• Configurer Zope en mode remote user, en faisant attention d'écrire le nom du super utilisateur sous forme canonique DOMAINE\Utilisateur
• Utiliser un UserFolder insensible à la casse tel jcNTUserFolder ou créer les utilisateurs sous forme canonique dans le UserFolder si l'on utilise celui livré avec Zope.

HOWTO (in english, sort of)

Introduction

Zope separates authentication (who is the user) from authorization (what is he allowed to do?). When Zope is interfaced with a web server, for example through PCGI, it can run in remote user mode, that is it can delegate authentication to the web server. This can be handy when the web server uses a non standard authentication scheme (e.g. IIS)

This document explains how to use Zope and IIS in remote user mode, to allow IIS to handle authentication, in challenge/response mode for example.

Authentication under Windows NT

Before we can deal with interfacing Zope and IIS, we have to understand how does authentication work under Windows NT.

When a user open a session on a Windows NT server, he has to provide a username, and a domain name from which he wants to be authenticated. This domain name may be the NT server computer name, and the user opens a session locally (in that case, the NT server must perform the authentication itself), or it can be a domain name into which the NT server exist, and the authentication is performed by the PDC (primary domain controller) or a BDC (backup domain controller).

It is clear that the NT server needs the domain name on which the user wants to open the session to be able to delegate authentication to the right NT server. A canonical username under NT is written DOMAIN\Username. Note that the canonical username is not case sensitive

Interfacing Zope and IIS

Follow instructions given by brianh at http://www.zope.org/Members/brianh/iis_howto. But you don't have to disable challenge/response authentication. This does not matter because Zope won't do authentication.

Go to IIS Manager, right-click on Zope.cgi, select Properties, click on the file security tab and then on authentication control. You have to:

• uncheck allow anonymous connexions if you want only users from the domain to browse the site (this is handy in the case of an intranet). Check the box if you needn't the user identify himself before browsing your Zope site
• uncheck basic authentication, unless your users use browsers not compatible with the challenge/response protocol (i.e. all browsers except Internet Explorer >=3.0)
• check challenge/response authentication, if your users use Internet Explorer

Note that you must check basic authentication or challenge/response authentication, or both. If you check None, this means Zope must handle authentication itself which is not what we want.

That configuration can be done on a file by file basis in the management console, so you needn't change the parameters for all the site.

Unless you disabled anonymous connexions, you should now be able to browse public (i.e. not protected) Zope ressource.

What is the authentication protocol

When you try to browse a protected ressource, Zope send a 401- Unauthorized HTTP header.

IIS chats with the web browser to try to authenticate the user. Zope is not involved at all in this process. IIS verify that the user/password in correct (match with a valid nt user), then verify that this user has sufficient right on the Zope.cgi ressource (ACL settings)

Only if all those don't fail that Zope is given the user identity in REMOTE_USER variable in the canonical form DOMAIN\Username.

Zope looks for that user in its user database (in the User Folder or any other user folder product), and check what roles are given to that user. If the user does not exists, or if he has not the required roles, Zope responds with 401-Unauthorized again, and the entire authentication process stard again.

You have noted that the authentication is done in two phases:

• First the user must exist on the domain and have permission on the Zope.cgi ressource for IIS to accept him
• Second, that user must exist in Zope in canonical form for roles to be given to him

Putting Zope in remote user mode

The file access in Zope installation directory must not contain any password for the super user to enable remote user mode. For example, il access contains:

        superuser:password

It has to be replaced with:

        superuser:

Be careful! Zope documentation says that the superuser user exists from the web server point of view.

And here lies the problem. Zope is case sensitive. IIS is not. Fortunately, IIS always send user information in canonical form DOMAIN\Username. The domain name is uppercase, and the user name is shown exactly the way it has been typed in the NT user manager. For example, if user MikeP from domain wild_west is to be the super user, the access file must contain:

        WILD_WEST\MikeP:

Restart Zope after this modification

Creating users under Zope

Zope is case sensitive. If the default User Folder is used to manage users, they have to be created in the canonical form

You can also use NT User Folder product like htrd's NTUserFolder or jephte's jcNTUserFolder. I don't know about NTUserFolder, but I wrote jcNTUserFolder to be case insensitive. This is why upon creation of jcNTUserFolder, you must choose the nt user who will be the super user, to be able to input the user name case insensitive

Summary

In summary, this is the steps to follow to interface Zope with IIS in remote user mode:

• Following brianh's instructions, configure PCGI
• Choose authentication method to be used by IIS: basic, challenge/response or both
• Configure remote user mode in Zope, and be sure to use the canonical form form the super user name.
• use a User Folder product which is case insensitive, or create users in the canonical form in Zope.

That's all folks!