This describes architecture .

The Issue

By moving Zope to the periphery of our architecture, we can no longer rely on Zope permission restrictions to provide authentication and authorization in our system.  But there is a lot tied up in the Zope membership system and we don't want to move away from it at this time.

The Near-term Solution

Zope writes a cookie when a user logs in.  Other applications can read that cookie, though they cannot naturally understand it.  By using a shared secret (which we will configure across all applications) we will allow other applications to read the authentication information.  They should be able to read the username from this cookie, though any extra information (e.g., full name, email) must be queried from Zope (via some HTTP/API call).  This extra information should be heavily cached, but of course authentication itself cannot be cached.

When an application needs a user to login, they must redirect the user to the Zope instance where the login will occur.

A Little Further Off (post 1.0)

We may put the authentication logic in the core stack in the future, giving authentication and user information through HTTP headers.  From there we may move the authentication out of Zope, if there's some useful reason to do so.  We don't have anything in mind that would cause us to do this.

Open ID

Open ID changes a lot.  We definitely want to support Open ID in a rich manner, but it may change our architecture significantly.

The easy first step is to become an Open ID server.  Each user's homepage would be Open ID enabled (and users could potentially move this information to other external pages and then have those pages authenticated by our Open ID server).  We will need to be cautious about phishing, but otherwise making ourselves into an Open ID server is relatively simple.  We may do this before 1.0.

The second step (which is more interesting) is to support Open ID clients.  Open ID provides simple identification, but with many caveats.  New users do not naturally register in this sort of system.  The Open ID identity may be only a URL, though we may request more information (but that request can be denied).  We will need to support user accounts that change Open ID URLs (e.g., if they migrate from livejournal to another provider).  We will need to keep extra information about users that we store persistently.  This effects the user system significantly.

From there we may consume our own Open ID identities.  Or maybe we won't.  What that means to user experience is a little unclear at this time.