Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

web authentication 2008

by cutlass2006 (Pilgrim)
on Jan 15, 2008 at 10:58 UTC ( [id://662447]=perlquestion: print w/replies, xml ) Need Help??

cutlass2006 has asked for the wisdom of the Perl Monks concerning the following question:

I am seeking wisdom about the current 'state of the art' with respect to user authentication in a typical mod_perl (v1 or v2) environment.

this has been a question, oft asked by other brothers of the monastery, for example;

http://www.perlmonks.org/?node_id=464495

here is a sample of stock (and very good) response;

  • investigate CGI::Session
  • read CGI::Session::Tutorial
  • investigate Apache::Session
  • investigate Mason w/ Apache::Session
  • session cookbook at http://search.cpan.org/~sherzodr/CGI-Session-3.95/Session/CookBook.pm
  • other modules at cpan e.g. http://search.cpan.org/author/LDS/HTTPD-User-Manage-1.6
  • should I even contemplate Google's AuthSub or YAhoo BBAuth or *gasp* AOL OpenAuth / MS Live Contacts API?

my particular need is further complicated by the requirement to manage users across the following;

unix user/groups: enforcement of perms on files and execution

svn repository: enforcement of svn groups and users

database: integrate with db users

apache users: integrate with http auth

I know that its unlikely that there exists any single approach to solving this problem ... any top tips ?

some ruminations;
  • should I opt to for a single svn or linux user to represent application then have the notion of application users / groups?
  • probably should define user/groups in data layer then transform from there
  • is there any specific module/framework that is more appropriate
  • there maybe more authentication schemes later on to integrate.

thx in advance, Jim Fuller


Update: In the end I decided to go with LDAP and was pleasantly surprised

Replies are listed 'Best First'.
Re: web authentication 2008
by Joost (Canon) on Jan 15, 2008 at 11:40 UTC
    Some ramblings:

    Sessions aren't really about authentication, and most of the session modules should work fine. Sessions aren't rocket science. If you're using a database abstraction layer, you may want to choose based on how well the module integrates with that layer.

    Linux and solaris and probably other Unix-like systems support PAM for authentication, which integrates with shell logins, ssh, some FTP servers, and more. There's also Authen::Simple::PAM which does mod_perl HTTP (and direct) authentication via PAM.

    PAM can get fairly complex, but it's very flexible, not all that hard to understand, and if you really want to integrate a lot of different services it's probably a good bet.

Re: web authentication 2008
by misc (Friar) on Jan 15, 2008 at 13:21 UTC
    Hi, I don't have a answer, it's more kind of a question/suggestion..

    I've got a quite similar problem:
    Integration of user permissions into samba, email server, database, and a mod_perl webinterface.

    So I'd like to describe what I'm most possibly going to do/already have done:
    The webinterface/authentication mechanism was the first task, is already finished and uses postgresql as backend.
    Because users are managed from within the webinterface and the permissions structure is quite complex, I'll stay with this.
    Writing an apache handler for authentication was quite simple and didn't take long.
    If someone is interested I can post the code here.

    After this there was the need to integrate the users´ fax numbers and emails into a device which is able to scan, fax and send emails.
    The device has a ldap interface, so I wrote a ldapserver with Net::LDAP::Server which accesses the postgresql database.

    Getting the server to work has also been a matter of one day.

    Now I still have to integrate the users into samba and the emailserver.
    There are already ldap backends for emailservers, so I'm most possibly going to adapt my own ldap server.

    Samba has also a ldap backend, but I'm thinking about writing a fuse fs for the quite sophisticated permissions of file access/preventing the users from editing files at the same time.

    I believe ldap has some advantages: It's mature, spreaded widely, and very many programs can access ldap servers already.

    That's however just a suggestion, you might wan't to google for ldap yourself.

    And I'm really interested in how you solve this task/What others think about the ldap approach.
      Getting OT: At a former place of employment, I used LDAP as a sort of modern-day NIS. PAM allowed us to use the LDAP for authentication and NSS caused users/groups to be looked up in the LDAP (if they couldn't be found in the files). Our Samba server was plugged into the LDAP in such a way, and that alleviated us from having to do anything special to manage permissions. We simply set the typical user and group permissions the way we would have if the users were local, and it worked like a charm.

      Perl was involved, of course. Since we never found anything that allowed us to manage users and groups in a pleasant way, I used Net::LDAP and Gtk2 to put something together that I could hand off to the IT staff and not worry about. Last I heard, they were still using it to good effect.

      Trying to bring this back on-topic, as cutlass2006 writes, LDAP can be an excellent solution to multi-faceted authentication. The only warning I can give is that you may be rolling-your-own on a lot of things, as we had to. Those are the two sides of the same coin: LDAP is extremely flexible, and as such you have to bend it to do your bidding.

Re: web authentication 2008
by perlfan (Vicar) on Jan 15, 2008 at 17:28 UTC
    I never stopped liking challenge-response systems that send a locally computed hash of (username,password) over the 'net instead of the password itself. The only difference is that I use SHA1 or one of the "new" hashing algorithms.

    I've been playing with CGI::Session lately as well, and I mostly like it - though it was not immediately obvious to me how to enforce a session at the top of a page...I figured out a hacky approach, but I intend on changing it.

    I hope that helps.

Re: web authentication 2008
by kirillm (Friar) on Jan 15, 2008 at 13:04 UTC

    Hi Jim,

    Please provide a more precise question. What exactly do you want to achieve, what is the goal and where would you like some assistance. Just asking for some wisdom about the current "state of the art" will probably not give you many answers.

    Some examples. Where do you want the authentication to take place: do you want to use authentication methods provided by HTTP or do it in the application (with some fancy graphics, password reminders and whatever else). You should not only thing about authentication (as "whom should I allow to come in"), but also about authorization (as "who should be allowed to do what").

    Oh, wait. That's not 2008. That's not even 2007 or 2006 for that matter. That's pretty old stuff.

    Greetz :-)

Re: web authentication 2008
by bastard (Hermit) on Jan 15, 2008 at 23:20 UTC
    Jim,

    Not sure how much help my comments will be but this is how I would attack what I perceive your challenge to be:

    1. Go with LDAP (or perhaps just a database) as a central user/group backend. Connect as many of the applications/apps to LDAP as possible.
    2. Build routines to export LDAP user data to apps that cannot natively use LDAP for authentication.
    3. Be sure to limit the ability to update user data from the systems that are not the "master" location.
    4. If LDAP isn't going to be used identify which system will be considered the "master" system and start with #2 to export the data to the other systems.

    Things to consider:
    1. User/group creation/deletion/modification - these are circumstances that will need to trigger updates to systems that don't directly use the master location.
    2. Are you looking for single sign on - thats a totally different animal and will likely require a token server where a cookie will be checked against currently active session token and possibly other information, etc... Each app will likely need work to integrate.
    3. Does the target unix platform support ACLs? Its a much more complicated method of permissions for files and directories, but will likely mesh better with application groups where each group is a sub/superset of another.
    4. Does disabling an account need to equate to an immediate denial of access (through currently active sessions?) this can be tricky and a royal pain.
    5. How do you handle failed user/group synchronization attempts? Do you roll all systems back or try to push the changes through again?

    If you can stray outside the realm of perl there are applications like Jitterbit that can wire together applications in various ways, but the learning curve may not be worth it when much can be done in perl as well.

    As far as state of the art for mod_perl webapps goes, my vote is with Catalyst. Its an application server for perl that lets you trivially integrate things like svn, databases, http auth, ldap, Plucene, Mason and more. It covers session management as well as a mechanism for authentication via a plethora of means.

    Hope my babble helps!

    dratsab
Re: web authentication 2008
by sundialsvc4 (Abbot) on Jan 18, 2008 at 04:00 UTC

    There are actually three distinct and unrelated(!) issues here:

    • Persistence:   This is actually the only thing that “sessions” do. By themselves, sessions know how to retrieve and store a vector of state-information, given a session-ID key, but do not validate the correctness of that key.
    • Authentication:   Determining, to your satisfaction, that the user actually is who he claims to be.
    • Authorization:   Given that you have determined that the user actually is who he claims to be, what can the user do?

    Many web sites make the serious error of confusing “knowledge of a currently-valid (or even just properly formatted...) session-ID” with “being the properly-authenticated legitimate owner of that session-ID.” They also honor valid-looking GET-request URIs without first verifying that the claimed presenter of such a URI is in fact currently logged-in. It is painfully obvious that the owners and designers of such sites never stopped to “talk like a pirate... arrrrr!!!”

    They never stopped to consider: “what if the person submitting an HTTP-request to my site was intentionally and willfully attempting to commit a felony?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://662447]
Approved by moritz
Front-paged by moritz
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others sharing their wisdom with the Monastery: (3)
As of 2024-03-29 06:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found