in reply to RFC: Authentication/Authorization System

I can see the value of this. It's the reverse of most of the Auth/Authz modules on CPAN, which actually perform authentication against a pre-existing store. Having something to manage that data seems like a useful thing to have.

Some quick notes:

At first, I had some reservations against must(), and can(), but if you do drop performing auth, then those would be moot :) If you do want to implement it, I'd suggest must_have_role() and has_role() (or maybe may() or something like that, but can() is already used for OO purposes, and carries too much of that meaning).

Bottom line: I'd like to see a nice framework for user and role data management. I don't know if it'll be easy for you to make it such that it can target PAM, SASL, Kerberos, Active Directory etc., but I bet there's demand for such a beast.

Update: I rummaged around CPAN some more, and found Aut. Seems fairly similar to your scope. There's also Tree::Authz, which looks fairly comprehensive as well. If you haven't done so yet (but I bet you have), I recommend searching CPAN for "authentication" and/or "authorization". There's a lot to wade through, but that'll give you a good idea what's out there, and what's still missing.

Replies are listed 'Best First'.
Re^2: RFC: Authentication/Authorization System
by eric256 (Parson) on Jul 19, 2006 at 19:45 UTC

    Good ideas. I just want to make sure I don't run into the "too many options" problem while trying to get around it. Basicaly I just want a place I can start, and then link to the other modules that do better or have better options. In addition I'm not sure how i'd go about making a program dynamic enough to be able to write to all of those different authentication systems. So I was hoping to make an Authentication/Authorization System in a box, then point people to more powerfull solutions that could be customized to different needs. Does that make more sense? Kinda user managment with training wheels, i'd fully expect people to ditch the training wheels eventualy, but some projects never get off the ground enough to worry about that. At least thats been my experience, which is why i'm meditating on this, to see if i'm alone or if others have similar experiences. ;)


    ___________
    Eric Hodges
      I can sympathise with you not wanting to aim too high just yet :)

      The typical solution to talking to different backends is usually by adding a driver layer (similar to the DBD::* modules for DBI). I've been browsing through the source for Authen::Simple, and the basic design looks very good. It uses Adaptor classes which implement the backend-store specific code behind the public, common API. It may be too abstract for your needs, but I think I can recommend it. It's interesting and educational at least :)