Hello, everyone. I'm afraid tg.ext.repoze.who only supports the repoze.who SQL/form plugin(s), and thus I'd like to know if we can make it support more so-called identifier, metadata and authentifier plugins under the same API? Better yet, why not support all of the repoze.who plugins? This would make TG both scale up and scale down in authentication.
I think it would be great if developers could choose what authentication method(s) they want to use, while keeping the great, simple, current API for authorization. It would be _really_ _easy_ for a TG developer to develop applications for the following scenarios: - A company already uses LDAP for managing its users and groups, so TG applications would re-use the users' login data and the groups they belong to, instead of creating a database to duplicate this information. We'd only need to create a table to assign the permissions of every LDAP group in the web app. - A small team of software developers maintain one or more Htpasswd and Htgroup files to store login data and groups, respectively. - A website uses OpenId and its groups are stored in a LDAP (or database) server. Also, other metadata such as homepage, real name, country, etc., is also stored in the LDAP/database server. - A company with employees spread around the globe uses client-side SSL certificates to authenticate them in internal websites that serve sensitive information. The groups to which these employees belong are stored in an LDAP server and the company wants to re-use this data. - Say Red Hat runs a TG application and manages its developers' data in a LDAP server and the login data for non-employed Fedora developers in a htpasswd file. When somebody logs in, TG should first try authentication in the LDAP server (which would succeed if s/he is a RH employee), and if it fails, try with the htpasswd file. The best solution I have in mind for this to come true, is that tg.ext.repoze.who stops dealing with authentication and focus on authorization only (then there would be no reason to call it "tg.ext.repoze.who" though; "tg.authorization" would be more accurate). This way authentication would be _fully_ customizable by using repoze.who directly. tg.ext.repoze.who would deal with repoze.who MetaData plugins to get groups and permission data - this is, authorization related data. Its authorization API (with features such as groups/permissions) need not be changed. We can still get the current result, where we have three tables (User, Group and Permission), if we move the authentication-related bits from tg.ext.repoze.who to the default TG2 template. What do you think about this? I'm willing to work on this soon (once I finish the LDAP and OpenId plugins for repoze.who). Cheers. -- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/
signature.asc
Description: This is a digitally signed message part.
