Peter Schober wrote:
Ross et al.,
I agree, and that is what I was trying to tell Ross, although apparently
not as clearly :
You should not try to do the authentication at the level of one
application, and then "pass it up to Apache" for other applications to
use. That will always give you problems (*).
Instead, you should have one authentication method on top, at the level
of Apache.
That means, as soon as the user hits Apache, it is asked for
authentication, before it even goes further to the application level.
There are a nultitude of schemes to achieve this, starting with the
various mod_auth* modules that come standard with Apache itself, and
extending to all the "non-standard" external add-on modules that can do
authentication vis-a-vis a number of different back-end systems.
Then you should have that authentication "passed down" to all
applications that run under Apache.
That is where the real difficulty arises.
Apache must store that authenticated user-id, in some place(s) where
each individual application can get it. That depends on the individual
capabilities of each application, to access this in some commonly-agreed
place(s).
One such place, accessible to cgi-bin type applications, is the
REMOTE_USER environment value, which Apache will automatically set up if
the user is known to Apache.
Another such place is the internal Apache request record's user-id
field. That is certainly accessible to applications written as Apache
add-on modules, but it would not be as easily accessible to, for
example, a cgi-bin program written as a shell script.
Another way would be that the Apache authentication module adds a custom
HTTP header to each request, containing the user-id, before passing on
the request to an application. (Since it is internal to Apache, there
would be no security issue involved). But it depends on the capability
of the application to obtain the content of this specific HTTP header of
the request.
The above by the way applies to any authentication and SSO scheme,
whether they are free or commercial.
So now when each application gets called, it can (theoretically) obtain
the authenticated user-id of the caller.
Now it is up to the application to do the "authorization" bit, which is
to decide, in function of this already-verified user-id, what
functionalities of the application this user gets access to, if any.
(*) One trivial example is if the user first hits another application,
before accessing the one that is supposed to do the authentication.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
