Hi Maciej. Thank you for your reply and outlining the authentication
process. This does make things clearer. There are a variety of backends,
I read that something as simple as reading fom a file is possible.
ldappas and dl.ldapauth provide some good hints for plugins and user
management from infrae's documentlibrary. I became aware of these
packages working on documentlibrary recently.
I want to be clear that https enters into the picture as soon as
authentication is required or someone were to click on a login link. I
am seeing links such as this in the docs I have been reading:
Reading the plone code, I noticed a replacement for login portlet (to
replace it with a link to CAS server) so I am assuming at this point
folks would be coming to portal unauthenticated and no https until you
were to login or attempt to gain access to an area where you need
authorization (then you are redirected - and now https on CAS server)
Have I got this right?
I thought sessions should be used but maybe there are some other
opinions. I realize there were some issues with sessions some years back
with z2. I have not heard anything negative about sessions in z3.
I was also thinking to some extent about the url redirection etc for
this CAS activity and it made me wonder whether some of this should not
be occurring as part of a WSGI middleware (but this is just a random
thought at the moment).
I am interested in setting up a project for this shortly. I'll likely
get this going in the next day or so and will be grateful for your help
since you have experience with this. I'll provide details for the
project as soon as I have them but will likely put it in zif collective
on sourceforge in svn.
BTW, I recently noticed that the authentication server need not be java
so long as it complies with the CAS protocol. In fact I was reading code
for rubyCAS server earlier today. It makes me wonder why the
authentication server itself could not be written in python and served
using zope or twisted. Gives me something to think about for later if
things work. Many thanks,
Maciej Wisniowski wrote:
Hi Maciej. I have been reading quite a bit about CAS today. It looks
like a good way to go. Couple of questions with how you having it
working in z2. Are you using LDAP as a user store with CAS.
We're not using LDAP. We have propertiary system to manage user
accounts in our applications (user data and permissions in
specific applications). This system uses RDBMS to store its data so
for CAS it is just external database with user names and passwords.
Our CAS server authenticates users against this database with just one
simple select statement I think.
I have downloaded a few of the z2 products to study the code
in the interim since a plugin for z3 would be a good thing. I've got to
look at how this works with users and groups code particular with
additional info you need for an app.
In fact i think that default plugin for CAS can't do more than just
So first step should be to rewrite CAS4PAS to zope3 PAU which should be
rather easy. Only thing I'm not sure obout is if this should use session
or maybe cookies? Sessions are nasty in Zope...
Another thing is a second plugin for user management. But this depends
your user database is. This plugin may enumerate users, set roles for users
etc. Depending on specific solution this plugin may connect to LDAP
or RDBMS to get user data, roles and permissions from and map them to
In our system we have a special permission in database that is mapped into
user role in Zope. In fact our plugin has parameter that says what is
for this role so it is easy to customize that via ZMI.
Not sure if you already realised how CAS works (I had some problems to
realise that at the begining) so a quick description is at the bottom of my
post. Important thing to note is that all addresses have to be https ones.
Anybody out there interested in helping with something like this? I'm
likely to start a project for this for z3 package but with zpl or mit
licensing since something this generic should have few barriers to
anyone using Yale's system. Many thanks.
I'm interested in helping you with that.
Order of actions in CAS authentication
1. User tries to enter into Zope application via url like https://xyz/myapp
2. CAS4PAS checks if there is a special object in session
that says user is already authenticated
3. If there is no object in session CAS4PAS checks if there is a 'ticket'
parameter in request
4. If there is neither special object in session nor 'ticket' in request
redirects user to CAS login page with 'service' parameter in redirect URL
which is address of zope application itself (CAS4PAS has to know address
of CAS login page)
5. User authenticates at CAS login page
6. CAS checks credenitals in RDBMS (LDAP etc)
7. If everything is OK CAS sets secure cookie in browser that indicates
user is authenticated
8. CAS redirects user to 'service' URL with additional 'ticket' parameter
9. Zope (which is under 'service' URL) checks again if there is a special
object in session, and if not, checks if there is a 'ticket' parameter
10. CAS4PAS in Zope gets data form the 'ticket' in request and goes to
'service url' (with
'ticket' and 'service' parameters) at CAS server to confirm authentication
(CAS4PAS has to know 'service url'):
11. CAS confirms user authentication and responds with name of
12. CAS4PAS sets special object in session to indicate user authentication.
Now another application (in short)
13. User tries to enter to another application that is protected by CAS.
14. Application redirects to CAS login page.
15. CAS finds that there already is secure cookie set so this user is
16. CAS redirects user back to application with 'ticket' parameter in
Zope3-users mailing list