Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Authentication in web applications

by polettix (Vicar)
on Jun 07, 2005 at 23:37 UTC ( #464495=perlmeditation: print w/replies, xml ) Need Help??

Dear Masters,

please forgive my sillyness if you find any in the following text, but I think I've got something resembling a good idea and I would like to ensure that it may really work. I haven't seen this around, but if someone already had it please point me towards their solution. Moreover, I'm no expert in the field, but I tried to look around for a definitive solution and I did not find it.

The problem is quite simple: managing login of users from a web application. I've basically detected two broad families:

  • HTTP-based authentication, either Basic or Digest
  • CGI-based authentication, based upon some login form much like PerlMonk's
The first thing I understand is that all of them do not guarantee much confidentiality, so one would better use strong encription techniques by means of HTTPS/SSL. Noted.

A quick, bird's eye comparison boils down to the following for me:

  • HTTP-based authentication is cleaner with respect the application. It puts authentication outside the application logic, while still allowing the retrieval of the authentication data (notably the user's name) in order to provide differentiated services.
  • CGI-based authentication, OTOH, require much more attention to the programmer, which has to ensure that every execution path gets through the authentication process. While this is not a terribly difficult thing to do, it surely leaves much space to error or overlooked dark cases, which would open holes.
  • CGI-based authentication provides you with the ability to log out, while HTTP-based seems not (at least according to the PAUSE website).
Summing up, it seems that the HTTP-based solution should be the way to go if I want to be on the safe side (Using CGI::Application on, however a bit dated, seems to second this impression), but this logout-impossibility is really annoying. So, I finally came up with an idea for a solution.

When you authenticate using the HTTP-based approach, you're asking the permission to "explore" a specific realm. When you try to get into another realm, you're usually asked for a different username/password pair, even if they are pretty the same as the original realm. The idea is: why don't use a realm name that actually is a session token? In this way, I could guarantee a logout feature by simply expiring the realm - if the user wants to get in again, another token is generated to create a brand-new realm.

And now I ask myself: is it really this simple. Probabilities come in handy here: "dumb idea, it cannot work in real world for this, that and more" (80%), "there is something that does more than this, and quite better" (15%), "hey! this is a GREAT idea!" (1e-5%). The remainder of the cake is for a general "cases I've not thought about, but I had better do" entry.

I'd like to have a feedback before giving that 1e-5% a chance and dive into the various Apache modules to figure out how this could be accomplished. Thank you in advance for any counter-Meditation,

Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))')

Don't fool yourself.

Replies are listed 'Best First'.
Re: Authentication in web applications
by kirbyk (Friar) on Jun 07, 2005 at 23:44 UTC
    One thing that may or may not be a factor - multiple web servers. Once you make that architectural leap, apache-based models start failing you, as do a lot of session methods, and you're left with cookies (or a universally passed session ID param) on the user side, and database on the backend with info about sessions.

    Which isn't to say that there's not a better way, but this is a big factor to consider for any reasonably large web site. Which most sites aren't, so, there you go.

    -- Kirby,

      Using Apache:: modules doesn't imply any specific storage mechanism. It's about how you tie into the server's request pipeline, not about what you do once you're there.
Re: Authentication in web applications
by Chady (Priest) on Jun 08, 2005 at 07:20 UTC


    You argue that CGI-based authentication requires a lot of attention from the programmer, and that you need to ensure that you don't miss any execution path... But this all can be solved in the application desgin before you delve into the code.

    Here's one of the ways I would tackle this:

    You need users and groups of permission, even if you seem not to need groups, you need at least two groups: visitor, and user. The visitor group has the permission to read some pages only, it is the default group and only contains one user (the not-logged-in visitor). The "user" group has other types of permissions, and that's usually a logged in user.

    In order to apply this, you need to always populate the permissions of the user on each request, so it will look like this:

    # some initialization code. $object->login(); # then you continue your application $object->open_some_page(); # more stuff.

    The login() method will check for parameters/cookies/etc.. and handle the sessions, AND it will populate some objects regarding the user login. ex: $object->{user}->{permission} contains the permission of the user.

    Now wherever you need to perform operations that require permissions, you only need to check $object->{user}->{permission} cause you are sure that this contains the correct permissions wherever you are in the code, provided that you call login() as soon as you can.

    Hope this gives you some more ideas to consider.

    He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.
    Chady |
    Are you a Linux user in Lebanon? join the Lebanese GNU/Linux User Group.
Re: Authentication in web applications
by perrin (Chancellor) on Jun 08, 2005 at 02:05 UTC
    What's the problem with simple cookie-based auth? All the big sites work that way, and the existing modules like Apache::AuthTicket make it easy. If you need CGI compatibility, use one of the CGI::Application plugins.
Re: Authentication in web applications
by Qiang (Friar) on Jun 08, 2005 at 03:01 UTC
    cookie + session are the methods widely used on the web. use the Apache::* modules for mod_perl or CGI:: if not.

    here is a good resource on web security and it covers the stuff you discussed in great detail

Re: Authentication in web applications
by dorward (Curate) on Jun 08, 2005 at 10:42 UTC

    On CGI authentication:

    What you call CGI authentication, isn't. It is Query String or Post Data (usually with a Cookie for authentication of later requests) based. How the server deals with that data is up to the programmer, CGI is only one option. (Others include mod_perl).

    On putting authentication outside the application logic:

    While Basic/Digest authentication is typically handled outside the application, and Post/Get authentication is typically handled by the application, this isn't a hard and fast rule. Mod_perl, for instance, allows you to specify a Perl module to handle authentication, this is outside the application logic and handled on a seperate layer by the server.

    On the ability to log out:

    Post/Get based authentication doesn't provide the user with a way to log out. It provides the programmer with a way to log the user out. Basic/Digest authentication requires the browser programmer to provide a logout feature (and most don't, although I hear Opera does).

Re: Authentication in web applications
by mugwumpjism (Hermit) on Jun 09, 2005 at 01:34 UTC

    It might seem like more potential for security holes having Application-level users, but it's really easy to misconfigure the web server and ruin the web server level authentication. Especially if the web server's configuration file format is the one that sets the ease of management standard - at the bottom end, that is.

    As others have pointed out, the inability to logout of HTTP sessions without closing all your browser windows really sucks.

    $h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/." ."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://464495]
Approved by kvale
Front-paged by tlm
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2018-06-22 04:30 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (121 votes). Check out past polls.