About this document

Zope has it's own personnal way of doing authentication that is adapted to web environments. This document is not meant to explain completely this area, but give some hints to understand how it works, and how CAS integrates into it.

It is supposed the reader already knows the CAS mechanism

Zope BasicUserFolder

BasicUserFolder is the parent class for all Zope related objects meant to provide some kind of user authentication. It provides 4 importants authentication-related methods to override :

• validate(self, request, auth, roles)

  This all-in-one method is called whenever Zope needs to check user authorizations against specific roles.

  It then calls identify() authenticate() and authorize()

  • identify(self, auth #string# )

    RETURNS (name #string#, password #string#) or None

    overriden by ACASUserFolder

    This method is called 1st and is mainly meant for BasicAuth usage. auth is of this form : base64_encode("name:password") and it's value is None when there is no basic auth.

    BasicAuth is a simple authentication mechanism where the browser send username+password for each request.

  • authenticate(self, name #string#, password #string#, request) ---- CAS work here ----

    RETURNS user instance or None

    overriden by ACASUserFolder

    This methods returns a user instance. And this is where ACASUserFolder do its main Job. The Zope way of doing authentication is to return here a kind of identity card which it has computed from it's environment (session variables, Basic credentials, etc...) This identity card contains user name and roles (plus password).

  • authorize(self, user, accessed, container, name #string#, value, roles)

    RETURNS 0 or 1

    check if user has roles

CAS Integration in Zope mechanism

The CAS work is done in the authenticate() method. ACASUserFolder check if it has already got a previously validated ticket. If it is the case, a cached user object is returned. Otherwise the client browser is redirected to the CAS server.

User instances can be stored in two ways :

1. into the Zope session itself, then all users has default roles as choosen in the CASUserFolder properties (Zope Management Interface aka ZMI). User instance disappear at session expiry.
2. Users can be persistent, then ACASUserFolder works like a classic BasicUserFolder for stored users instances. In this case per-user roles can be choosen and default roles can be choosen too for newly created users. However, the folder will keep an entry for each user that has connected. Future release will set expiry dates.

Users logging-in for the 1st time (and which has not been created by hand) always has the default roles choosen in the ZMI.

ACASUserFolder and GroupUserFolder (aka GRUF)

For clean Plone Integration CASUserFolder must work within GRUF.

With GRUF unpatched version (until GRUF 3.22) the GRUF implementation do not call the authenticate() method of it's subfolders if auth == None for performances reasons. So this behaviour do not allow the authenticate() method of CASUserFolder and other SSO solutions to be called because auth is always None in these cases.

The patch provided on this site has been included with GRUF 3.3

CASUserFolder credentials

When a user has authenticated successfully to the CAS server it's credentials are stored in it's Zope session. The Zope session is linked to the client browser with the _ZopeId cookie.

So CASUserFolder security is at the same level as Zope security, and may be improved as well as Zope sessions security are improved. This method provides clean and compatible credentials as no new cookies are generated. More: another sessioning method can be choosen, then CASUserFolder will just continue to work without cookies.