Hi, I''m porting/rebuiling an existing PHP application to Rails and I''m looking for a way to not write my own role-based authentication & authorization subsystem. It''s a simple scheduling application which should have: - a guest (unauthenticated) role which can read schedules and register - a registered role allowing users to change their own contact info, and mark themselves as available to be scheduled - a scheduler role for users trusted to create schedules, and - an administrator role to set user roles and change anything else that needs changing. My application doesn''t need fine-grained access control, but it needs something more than what LoginGenerator provides. I''ve spent a few days poking around the RoR wiki and rummanging through the mailing list archives and I''ve found the following: * ModelSecurity: http://perens.com/FreeSoftware/ModelSecurity/ * ActiveRBAC: https://rbaconrails.turingstudio.com/trac/wiki * SaltedHashLoginGenerator: http://wiki.rubyonrails.org/rails/pages/SaltedHashLoginGenerator * LoginGeneratorACLSystem: http://wiki.rubyonrails.com/rails/pages/LoginGeneratorACLSystem * LoginGenerator: http://wiki.rubyonrails.com/rails/pages/LoginGenerator ---- Of those, I believe ActiveRBAC offers more than I need and (for now) is less stable than I want; not a complaint - it''s the downside of very active development. The same may be true of ModelSecurity. I have not installed or tested either of these. SaltedHashLoginGenerator has some internationalization features I don''t need but am not opposed to, provided they don''t get in the way. Otherwise it looks like it does what I need. I have not installed or tested this either. As mentioned before, LoginGenerator handles authentication just fine but falls short of my authorization needs. However, I have installed and tested this and it seems to work fine in its intended role. I tried extending this with LoginGeneratorACLSystem but I had a lot of trouble following the instructions on the wiki. For example: "To Install: 1. Follow the directions in HowToQuicklyDoAuthenticationWithLoginGenerator 2. Create the database schema described in AccessControlListExample 3. Follow the instructions below: ..." Step 1 creates the users table in MySQL with: CREATE TABLE users ( id int(11) NOT NULL auto_increment, login varchar(80) default NULL, password varchar(40) default NULL, PRIMARY KEY (id) ); while Step 2 (re)creates the users table in MySQL with: CREATE TABLE users ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, nick VARCHAR(40) NOT NULL, name VARCHAR(40), pswd VARCHAR(40) NOT NULL, modified_at DATETIME, created_at DATETIME, access DATETIME, PRIMARY KEY(id) ); Or more clearly: # Step 1 | # Step 2 CREATE TABLE users ( | CREATE TABLE users ( id int(11) NOT NULL auto_increment, | id INTEGER UNSIGNED NOT NULL | AUTO_INCREMENT, login varchar(80) default NULL, | | nick VARCHAR(40) NOT NULL, | name VARCHAR(40), password varchar(40) default NULL, | pswd VARCHAR(40) NOT NULL, | modified_at DATETIME, | created_at DATETIME, | access DATETIME, PRIMARY KEY(id) | PRIMARY KEY(id) ); I never make it to step 3 because: * The id fields are different/incompatible integer types (''int(11)'' vs ''integer unsigned''.) This is easy enough to fix to make compatible with the roles_users table. * I assume that ''login'' and ''nick'' are meant to perform the same function but they are of different names and types so it''s not clear which should take preference. And using ''login'', ''nick'', and ''name'' seems redundant; one of the three seems superfluous. * The same name/DDL mismatch occurs between ''password'' and ''pswd'' I''m willing to help update the documentation or create a tutorial but it''s not clear what I need to do to make this work. I''m not sure if this is even the right forum to suggest changes to the wiki, but keeping this to myself is guaranteed not to help any. :) Regardless, my main question is which access control module or scheme should I use? Thanks much, -- Bob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 13, 2005, at 12:02 PM, Bob Apthorpe wrote:> Regardless, my main question is which access control module or scheme > should I use?I can''t answer your question, but it brings up one of my irritations with Rails'' opinions. I know (despite not being able to find the relevant blog entry on loudthinking.com) DHH has said Rails should be slim and not do application level stuff like authentication/ authorization. But. *How many people are deploying Rails applications that don''t have some form of login?* I imagine there''s a few, but the vast majority of Rails apps have similar user requirements. I''d like to see users integrated into the Ruby core. It doesn''t have to force people into as complete a solution as ActiveRBAC as long as it''s pluggable. Just like you can start off with WebBrick/SQLite and move to Lighttpd/#{Winner of DB flamewar} why not have a package that lets you start off by generating a user model, then when you need it being able to add permissions, roles, groups, LDAP, etc.? Being opinionated about how users and permissions should be implemented will make 90% of Rails projects easier and more fun to develop. How much fun is building yet-another-authorization-system? OK, now that I have that off my chest you can reply telling me it should stay out of the core because you need your user model to support octopods. George - -- George Hotelling GPG: 0x8175D485 ] http://george.hotelling.net ] _ _ _ ___ _ _ _/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDTpCsgXVRXIF11IURAoYxAJ9dQms4OebBAOmBbr0RFrryJLbkvACgrO81 R4yS2ipn1olL09r8a278UAU=ejAJ -----END PGP SIGNATURE-----
On Thu, 2005-10-13 at 12:51 -0400, George Hotelling wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Oct 13, 2005, at 12:02 PM, Bob Apthorpe wrote: > > > Regardless, my main question is which access control module or scheme > > should I use? > > I can''t answer your question, but it brings up one of my irritations > with Rails'' opinions. I know (despite not being able to find the > relevant blog entry on loudthinking.com) DHH has said Rails should be > slim and not do application level stuff like authentication/ > authorization. > > But. *How many people are deploying Rails applications that don''t > have some form of login?* > > I imagine there''s a few, but the vast majority of Rails apps have > similar user requirements. I''d like to see users integrated into the > Ruby core. > > It doesn''t have to force people into as complete a solution as > ActiveRBAC as long as it''s pluggable. Just like you can start off > with WebBrick/SQLite and move to Lighttpd/#{Winner of DB flamewar} > why not have a package that lets you start off by generating a user > model, then when you need it being able to add permissions, roles, > groups, LDAP, etc.?Is it me or do you seem to contradict yourself here. You want it as part of the core, but you want it pluggable? Are you suggesting something like activerecord with pluggable backends? If so I think you run into the problem of the many different authentication backends being too differing to be brought under one API. I think it has been mentioned else where here that something like this should be developed as a module(?) that can be put into place as you wish. As an example, you have the security piece that Bruce Perens wrote and there is the minimalistic security via the SaltedLoginGenerator and minor changes to the user object. And yet again, we at my work are close to finishing off a SELinux style(both pure rails and possibly integrated to the systems policy) security system with a policy reader, and a web enabled editor. I do not know if you could sufficiently consolidate that many differing APIs into one pluggable super API that could hide the complexity below it. Don''t take that as a reason to not want this though. I do not see the authentication/authorization APIs as needing to be consolidated. Just made available so one may make the decision as to what they want to use from the get go. If you have several prebuilt libraries to choose from, there shouldn''t be too much worry about building a new one. But that also plays to the side that it should not be core to rails. -- Steven Critchfield <critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org>
Hi, Steven Critchfield wrote:> On Thu, 2005-10-13 at 12:51 -0400, George Hotelling wrote: >>On Oct 13, 2005, at 12:02 PM, Bob Apthorpe wrote: >> >>>Regardless, my main question is which access control module or scheme >>>should I use? >> >>I can''t answer your question, but it brings up one of my irritations >>with Rails'' opinions. I know (despite not being able to find the >>relevant blog entry on loudthinking.com) DHH has said Rails should be >>slim and not do application level stuff like authentication/ >>authorization. >> >>But. *How many people are deploying Rails applications that don''t >>have some form of login?* >> >>I imagine there''s a few, but the vast majority of Rails apps have >>similar user requirements. I''d like to see users integrated into the >>Ruby core.[...]> I do not know if you could sufficiently consolidate that many differing > APIs into one pluggable super API that could hide the complexity below > it. > > Don''t take that as a reason to not want this though. I do not see the > authentication/authorization APIs as needing to be consolidated. Just > made available so one may make the decision as to what they want to use > from the get go. If you have several prebuilt libraries to choose from, > there shouldn''t be too much worry about building a new one. But that > also plays to the side that it should not be core to rails.My original concern was that in a quick survey of 4 authentication/authorization schemes, it wasn''t clear which was appropriate for my project, which were considered ''bleeding edge'', and which were deprecated, un(der)documented, favored, etc. I think an "80% solution" incorporated in the core, with documentation and a tutorial would do a lot to cut down on confusion, but given that I''ve been on this mailing list for about three days and working with Ruby for a week and a half, I don''t expect my vote counts for much. :) What I mean by an 80% solution is a simple user-role-permission model which uses the application database to store passwords, roles, and priveleges designed to easily addresses the cases of: 1) open use (no authentication; conversely, full authorization) 2) registered/anonymous users (authentication = authorization) 3) admin/role/registered/anonymous users 1) and 2) are subsets of 3), so focussing on a clear API for 3) allows you to get 1) & 2) essentially for free. It would be nice if external authentication schemes could inherit from a common parent, but I would not be surprised if that were prohibitively difficult to create. Personally, I don''t care if this in the core or not; it''s easy enough to install modules and generators. However, putting it in the core makes it canonical and ensures it''s tested, documentented, and maintained (presuming that things don''t go into the core without being tested, documentented, and maintained. QED) Maybe this is not the right time for this; maybe 6-12 months is required for the auth code to stabilize and mature enough that it could be considered for inclusion in the core. As I said, I found at least four authentication/authorization schemes, each with different goals and degrees of consistency or compatibility. As someone unfamiliar with the framework, but with some experience developing web applications, it''s a little confusing and frustrating trying to Do The Right Thing and reuse the right piece of code rather than (badly) writing yet another auth subsystem. Don''t take this as a complaint about what''s in or not in the core. I''m most concerned that I don''t write my own broken incompatible auth system and that I pick an appropriate, workable one that I probably won''t have to rip out and replace later. Advice is cheerfully accepted. Thanks, -- Bob
Ive been heavily testing the code for model_security that Bruce perens has written. And Id say it fits the 80% class. Most web apps ive developed (been doing it for 12+ years) that are on the internet, are really anonymous,registered and admin users. model_security fils this nciely as well as letting you protect certain parts of your model from being viewd buy the different user classes. It works well now and is what Ive been looking for. So there are my .02 Sam On 10/14/05, Bob Apthorpe <apthorpe+rails-agmD+G9TtWrk1uMJSBkQmQ@public.gmane.org> wrote:> Hi, > > Steven Critchfield wrote: > > On Thu, 2005-10-13 at 12:51 -0400, George Hotelling wrote: > >>On Oct 13, 2005, at 12:02 PM, Bob Apthorpe wrote: > >> > >>>Regardless, my main question is which access control module or scheme > >>>should I use? > >> > >>I can''t answer your question, but it brings up one of my irritations > >>with Rails'' opinions. I know (despite not being able to find the > >>relevant blog entry on loudthinking.com) DHH has said Rails should be > >>slim and not do application level stuff like authentication/ > >>authorization. > >> > >>But. *How many people are deploying Rails applications that don''t > >>have some form of login?* > >> > >>I imagine there''s a few, but the vast majority of Rails apps have > >>similar user requirements. I''d like to see users integrated into the > >>Ruby core. > [...] > > I do not know if you could sufficiently consolidate that many differing > > APIs into one pluggable super API that could hide the complexity below > > it. > > > > Don''t take that as a reason to not want this though. I do not see the > > authentication/authorization APIs as needing to be consolidated. Just > > made available so one may make the decision as to what they want to use > > from the get go. If you have several prebuilt libraries to choose from, > > there shouldn''t be too much worry about building a new one. But that > > also plays to the side that it should not be core to rails. > > My original concern was that in a quick survey of 4 > authentication/authorization schemes, it wasn''t clear which was > appropriate for my project, which were considered ''bleeding edge'', and > which were deprecated, un(der)documented, favored, etc. > > I think an "80% solution" incorporated in the core, with documentation > and a tutorial would do a lot to cut down on confusion, but given that > I''ve been on this mailing list for about three days and working with > Ruby for a week and a half, I don''t expect my vote counts for much. :) > > What I mean by an 80% solution is a simple user-role-permission model > which uses the application database to store passwords, roles, and > priveleges designed to easily addresses the cases of: > > 1) open use (no authentication; conversely, full authorization) > 2) registered/anonymous users (authentication = authorization) > 3) admin/role/registered/anonymous users > > 1) and 2) are subsets of 3), so focussing on a clear API for 3) allows > you to get 1) & 2) essentially for free. It would be nice if external > authentication schemes could inherit from a common parent, but I would > not be surprised if that were prohibitively difficult to create. > > Personally, I don''t care if this in the core or not; it''s easy enough to > install modules and generators. However, putting it in the core makes it > canonical and ensures it''s tested, documentented, and maintained > (presuming that things don''t go into the core without being tested, > documentented, and maintained. QED) > > Maybe this is not the right time for this; maybe 6-12 months is required > for the auth code to stabilize and mature enough that it could be > considered for inclusion in the core. As I said, I found at least four > authentication/authorization schemes, each with different goals and > degrees of consistency or compatibility. As someone unfamiliar with the > framework, but with some experience developing web applications, it''s a > little confusing and frustrating trying to Do The Right Thing and reuse > the right piece of code rather than (badly) writing yet another auth > subsystem. > > Don''t take this as a complaint about what''s in or not in the core. I''m > most concerned that I don''t write my own broken incompatible auth system > and that I pick an appropriate, workable one that I probably won''t have > to rip out and replace later. Advice is cheerfully accepted. > > Thanks, > > -- Bob > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >