[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Authentication in CGIs via PAM

On Mon, 20 Dec 1999, Enrico Zini wrote:

> I'm writing a system administration tool with, among many things, a CGI
> frontend.  This CGI needs to authenticate users before allowing them access to
> certain functions.

> To be compatible with whatever password database I'm going to use on my system,
> I would like to use PAM to do the authentication, but the concept of the
> conversational function badly fits with the stateless approach of CGI
> interaction.

> I have two problems right now:
>  1) The conversational function would need to write an HTML form and exit, to
>     find its data in the next invocation of the program, and it seems
>     impossible to me to code that;
>  2) In the conv. function, I know how to prompt the user for input, but I don't
>     know what input I'm prompting for; this makes things difficult for two
>     things: 
>      a) it's difficult to provide user friendly or internationalized forms, or
>         forms with a little help on what are they asking about;
>      b) if I work around problem 1) asking for data on a special form before
> 	calling the conversational function, I don't know how to associate user
> 	fields with the appropriate PAM questions, besides using the PAM prompt
> 	as a key; this approach could solve many things, but what warranties do
> 	I have that the prompts will never change?

One way around this, as Andrey stated, is to have some sort of daemon
running on the server which processes requests/responses from the CGIs.
This would probably mean saving state in cookies.

Another possibility that a colleague and I had been investigating for use
with PHP would be to have a long-lived CGI process which uses JavaScript
to spawn pop-up windows which prompt the user for information.  The form
data is submitted back to the server using a secondary CGI which
communicates via IPC with the original CGI process, providing a true
conversation as intended by the PAM interface.

This second design seems feasible, but we unfortunately never got past the
design phase, because I wasn't able to dedicate the time needed to add
full PAM support to PHP.  

WRT internationalization issues:  this came up for discussion here not too
long ago, and I believe the verdict was that the application which invokes
libpam should decide what locale to use, and expose this information to
libpam (and, therefore, to all of the modules); the modules themselves
will decide what strings to pass to the conversation function, based on
the locale they are given.
Of course, I don't think any of the current PAM modules have been
internationalized yet.

-Steve Langasek
postmodern programmer

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []