Re: [Slashcode-development] Slash::Apache::User on PerlAuthzhandler?

[Clifton W. <cli...@gm...>]

Ah, you make a good point, here.  It's probably easier to think about
things in this manner, and it's been a while since I've done mod_perl
1 so I think I might have missed critical differences in each of the
necessary handlers -- there are *3*, not 2. Presented in the order
they execute (I hope I have this right):

PerlAccessHandler - Determine if the client is to have access to a
specific resource, this is generally used to deal with IP banning as
such and doesn't require the need for specific credentials (usually
indicated by directives like "AuthType", "AuthName", and "require").
THIS is why Slash uses this handler. Really, Slash::Apache::User is
probably doing too much, but since there is an IP ban list in Slash,
it was probably just easier to handle everything in one piece of
monolithic code. If other Slash sites needed the extra security, they
could handle those pieces on their own. As it is, the only
"authentication" necessary is handled by Slash's perl scripts and need
*not* be handled by specific client/server interaction. (as is the
case with PerlAuthenHandler and PerlAuthzHandler). The only
distinction that Slash cares about at this point is "logged in" and
"not logged in", and this is handled by the presence of a specific
cookie. All other security measures are handled by the script code,
not by specific server code.

PerlAuthenHandler - Handles authorization, ala verifying user
credentials and the like. You would think that this would be the
natural place for your code, but it isn't, as it would require  an
"AuthType", "AuthName" and "require" directive, which Slash doesn't
use. Since Slash has already done it's magic in PerlAccessHandler,
this also makes this handler redundant.

PerlAuthzHandler - Determins if an *authenticated user* is to have
access to specific site resources. This assumes that a client *has
already authenticated* based on the results of PerlAuthenHandler and
is intrinsically linked to that particular phase. Since
PerlAuthenHandler isn't used for Slash, neither is PerlAuthzHandler.

Slash doesn't need $REMOTE_USER to do it's magic, you do. What you
might want to try is to use stacked PerlAccessHandlers to check
$REMOTE_USER. You would perform this check and automatically generate
a properly formatted Slash cookie for that user, then let Slash's
existing code run afterwards to do that voodoo that it do.

For your purposes, your code would need to run first, and then the
existing Slash handler would run last.

    PerlAccessHandler Slash::Apache::User::RemoteUserCheck Slash::Apache::User

Here's an outline on how I think your PerlAccessHandler should work:
   - Check $REMOTE_USER. Robust code says you should do this. Do not expect it
     to exist. If it doesn't, fail out ("return
Apache::Constants::FORBIDDEN" --
     Apache::Constants::AUTH_REQUIRED might work here, too.).
   - [optional] If it exists, perform a check to see if the Kerberos
credentials are valid.
   - Do a query on the $REMOTE_USER user in the database, if she does not exist,
     create an account with your default password.
   - If any errors, return "Apache::Constants::SERVER_ERROR".
   - If you get to this point with no problems, bake a properly formed
Slash cookie,
     and send it to the client.
   - Done. "return Apache::Constants::OK"

I *think* this is how it should work. I had to go back to the mod_perl
1.0 docs and check my assumptions and this is maybe the 3rd or 4th
version of this email since I got several things wrong! ;-)  -- I'm
sure that probably doesn't instill great confidence in what I've
written above, but it's the best I've got to offer at this time. If
anyone else can correct any errors or misconceptions in the above,
please do. I know I ain't perfect and am not arrogant enough to push
forward that assertion. ^_^

Hope this helps!

- Cliff

>On 5/14/07, Faye Gibbins <fgi...@st...> wrote:
> Hi,
>
> Disclaimer:
>              Please forgive a slashcode novice if this discussion covers
> well trod land.
>
> The default install of slashcode attaches Slash::Apache::User to
> PerlAccessHandler.
>
>   PerlAccessHandler is run before PerlAuthenHandler which is in turn
> runs before PerlAuthzHandler.
>
>   So if using Apache external authentication the REMOTE_USER env var is
> not available at the "PerlAccessHandler" but _is_ available at the
> "PerlAuthzHandler" phase. This makes it difficult to setup accounts
> based upon the Authentication phase.
>
>   So to gain finer control over user access would it not make sense to
> move Slash::Apache::User to the PerlAuthzHandler phase?
>
> Yours
> Faye
>
> --
> ---------------------------------------------------------
> Faye Gibbins, Computing Officer (Infrastructure Services)
> GeoS KB; Linux, Unix, Security and Networks; 0131 6506426
> ---------------------------------------------------------