[Zope3-Users] Re: Remote authentication

[David Pratt]

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:

https://secure.its.yale.edu/cas/login?service=http://my/url

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,

Regards,
David


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
> authentication.
> 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
> on where
> 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
> Zope ones.
> 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
> the name
> 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
> CAS4PAS
> 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)
> https://casserver/login?service=https://xyz/myapp
> 
> 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
> https://xyz/myapp?ticket=PT-838288428348284
> 
> 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
> in request.
> 
> 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'):
> https://casserver/serviceValidate?ticket=PT-8838828388...&service=https://xyz/myapp
> 
> 11. CAS confirms user authentication and responds with name of
> authenticated user.
> 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
> authenticated!
> 16. CAS redirects user back to application with 'ticket' parameter in
> URL... etc.
> 
>