Send modauthtkt-users mailing list submissions to
modauthtkt-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of modauthtkt-users digest..."
Today's Topics:
1. Re: Blogging about mod_auth_tkt (Jose Luis Martinez)
2. Re: Blogging about mod_auth_tkt (Christian Folini)
3. patch for Apache 2.2 (Peter Karman)
4. Re: Blogging about mod_auth_tkt (Peter Karman)
5. Re: patch for Apache 2.2 (Jose Luis Martinez)
6. Re: Blogging about mod_auth_tkt (Jose Luis Martinez)
7. Re: Blogging about mod_auth_tkt (Jose Luis Martinez)
----------------------------------------------------------------------
Message: 1
Date: Sat, 26 Jan 2008 19:10:30 +0100
From: Jose Luis Martinez <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] Blogging about mod_auth_tkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Peter Karman escribi?:
>
> The assumption right now is the same as I outlined earlier in this thread:
> that
> mod_auth_tkt still performs the ticket validation before Catalyst ever
> touches it.
> However, once the verify_ticket() patch is released to cpan, I'll update
> C::P::A::AT to
> use that instead of parse_ticket(). (I probably also should remain the module
> to remove
> the ::Plugin part since that naming convention is now deprecated.)
>
I saw the module too (search.cpan.org returns it when you search
"authtkt" ;) ) I'm with you on extending it to handle validation. It
would be sweet if it detected ticket expiry, handled ticket renewal,
and would accept the ticket through GET too... that way it would be
fully independant from the C module.
I'll post how we handled expiry and renewal (wouldn't want everyone
working on the same bits).
> cheers,
> pek
>
------------------------------
Message: 2
Date: Mon, 28 Jan 2008 09:55:46 +0100
From: Christian Folini <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] Blogging about mod_auth_tkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=utf-8
Hi Jose,
nice group of posts on mod_auth_tkt.
You are asking about ways to forward REMOTE_USER to the backend
in your blog.
I have been using an extended http header. X-REMOTE-USER so to
speak. Then you grab that header in the backend. (-> mod_header)
A 2nd interesting point is group tokens. Say your application
does granulary authorization itself. You need a way to pass these
group tokens into the application. This can be done via an extended
http header just as easily.
In both cases, the application has to be able to handle these
extended headers.
In the case of the REMOTE-USER there is an alternative: Many
applications accept HTTP Basic-Authorization. What you can do
is assemble a HTTP Basic-Auth header on the reverse proxy and
forward it to the backend. You need the user password to do
this. But mod_auth_tkt can help here too. The ticket format
leaves room for "user data". It is possible to instruct your
login server to encrypt and store the user password into the
ticket.
The reverse proxy takes it out of the envelope and assembles
the basic auth header for backend access.
Unfortunately, http does not provide a default way to pass
group tokens within the protocol.
This is not my idea, but I have seen it in practice and it
looked quite performing.
Now the embedding of the password in the cookie leaves a bad
taste in my mouth. And I would like to hear some opinions
on the safety of this practice. I for one feel a bit uneasy,
but I see the need for easy backend integration.
regs,
Christian
On Fri, Jan 25, 2008 at 09:15:53PM +1100, Gavin Carr wrote:
> Hi Jose,
>
> On Fri, Jan 25, 2008 at 09:36:24AM +0100, Jose Luis Martinez wrote:
> > I've been blogging about mod_auth_tkt these days, so maybe you would
> > like to visit my blog to have a look.
> >
> > I would like Gavin to confirm that I'm not leaving anything important
> > out on the ticket validation part.
> >
> > The link is: http://pplusdomain.net/cgi-bin/blosxom.cgi
> >
> > Hope you like it.
>
> Looks pretty good to me. I especially like the movie metaphor - it's
> a good one.
>
> Just so you know, your valid_ticket patch is still in my queue and
> looks pretty good. I've got a deadline mid-next week to meet, so
> probably won't get to it till after that though.
>
> FWIW, since you ask in your lastest post about other ways of getting
> REMOTE_USER to the backend server, you should be able to do this
> with some mod_rewrite magic on the frontend. There's a discussion here
> by the webauth guys about how to do it:
>
> https://mailman.stanford.edu/pipermail/webauth-info/2006-May/000064.html
>
> which seemed to work for them in the end.
>
> A working example of that for mod_auth_tkt would make a nice post. ;-)
>
> Cheers,
> Gavin
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> modauthtkt-users mailing list
> modauthtkt-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
------------------------------
Message: 3
Date: Tue, 29 Jan 2008 16:28:33 -0600
From: Peter Karman <[EMAIL PROTECTED]>
Subject: [modauthtkt-users] patch for Apache 2.2
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8
I ran into some oddness when testing under Apache 2.2, where the whole
authentication/authorization API has been reworked from previous Apache
versions. The
symptoms I was seeing were that the mod_auth_tkt functions would work
correctly, but
Apache wasn't registering the authorization correctly, and mod_authz_default
would throw
an error at the end of the auth process.
error: require directives present and no Authoritative handler.
which is just a generic error that means that no other authz module handled the
request
correctly.
It seems that mod_auth_tkt was correctly handling the authn, but not the authz.
I only saw the issue when I was running with several other mod_auth* modules in
the same
Apache instance (the defaults plus ldap, svn, etc). Even then, I could not
duplicate the
error on a different box with the same modules but different 2.2.x version.
The patch below fixes this issue (and a couple of compiler warnings). I am not
sure if it
is optimal or not, since it means that auth_tkt_check() is called twice for
each request
under Apache 2.2. Without a lot of refactoring to reflect the authn/authz split
in 2.2,
I'm not sure how better to accomplish this.
In any case, this patch does not break any of the tests for me (the same ones
are failing
as I reported before). So it doesn't seem to introduce any *new* problems.
Finally, if anyone knows of a good set of docs about writing for the new Apache
auth API,
I would appreciate a link. Google did not help me much, and for a one line fix,
this took
me several days to track down...
=== modified file 'src/mod_auth_tkt.c'
--- src/mod_auth_tkt.c 2007-06-21 10:37:22 +0000
+++ src/mod_auth_tkt.c 2008-01-29 22:02:00 +0000
@@ -1128,8 +1128,13 @@
int guest_user_length;
apr_uuid_t *uuid;
char *uuid_str, *uuid_length_str;
+#ifdef APACHE22
+ ap_regex_t *uuid_regex;
+ ap_regmatch_t regm[UUID_SUBS];
+#else
regex_t *uuid_regex;
regmatch_t regm[UUID_SUBS];
+#endif
int uuid_length = -1;
char *uuid_pre, *uuid_post;
#endif
@@ -1311,7 +1316,7 @@
}
if (! guest) {
ap_log_rerror(APLOG_MARK, APLOG_INFO, APR_SUCCESS, r,
- "TKT: no valid ticket found - redirecting to login url");
+ "TKT: no valid ticket found for %s - redirecting to login url",
r->unparsed_uri);
return redirect(r, conf->login_url);
}
}
@@ -1398,6 +1403,9 @@
{
ap_hook_post_config(auth_tkt_version, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_check_user_id(auth_tkt_check, NULL, NULL, APR_HOOK_FIRST);
+#ifdef APACHE22
+ ap_hook_auth_checker(auth_tkt_check, NULL, NULL, APR_HOOK_FIRST);
+#endif
}
/* Declare and populate the main module data structure */
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
------------------------------
Message: 4
Date: Tue, 29 Jan 2008 21:00:49 -0600
From: Peter Karman <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] Blogging about mod_auth_tkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Jose Luis Martinez wrote on 1/26/08 12:10 PM:
>
> I'll post how we handled expiry and renewal (wouldn't want everyone
> working on the same bits).
>
yes, please do, either here or to me offlist.
cheers,
--
Peter Karman . http://peknet.com/ . [EMAIL PROTECTED]
------------------------------
Message: 5
Date: Wed, 30 Jan 2008 12:52:49 +0100
From: Jose Luis Martinez <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] patch for Apache 2.2
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
We are using mod_auth_tkt in Apache 2.2 without problems (for the
moment). I can't get to remember if it passed all the tests, though (it
was quite some months ago).
Basically we took a Debian Etch Apache 2.2, installed the apache dev
package too and compiled auth_tkt. I can't remember if the tests where
all OK...
One thing that we noticed is that we had to compile one version for the
default worker mpm that debian installs, and another one for the
preforked mpm.
Maybe it has to do with the way Debian is compiling Apache that it works
for us.
Here is an apache2ctl -V of one of the installations:
Server version: Apache/2.2.3
Server built: Mar 27 2007 14:59:52
Server's Module Magic Number: 20051115:3
Server loaded: APR 1.2.7, APR-Util 1.2.7
Compiled using: APR 1.2.7, APR-Util 1.2.7
Architecture: 32-bit
Server MPM: Worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/worker"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT=""
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
-D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf"
Hope it helps.
Jose Luis
------------------------------
Message: 6
Date: Wed, 30 Jan 2008 13:07:34 +0100
From: Jose Luis Martinez <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] Blogging about mod_auth_tkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I have been using an extended http header. X-REMOTE-USER so to
> speak. Then you grab that header in the backend. (-> mod_header)
>
> A 2nd interesting point is group tokens. Say your application
> does granulary authorization itself. You need a way to pass these
> group tokens into the application. This can be done via an extended
> http header just as easily.
>
> In both cases, the application has to be able to handle these
> extended headers.
>
Nice solution. Thanks for the feedback. I'm going to try to post on the
mod_rewrite and the mod_header solutions.
> In the case of the REMOTE-USER there is an alternative: Many
> applications accept HTTP Basic-Authorization. What you can do
> is assemble a HTTP Basic-Auth header on the reverse proxy and
> forward it to the backend. You need the user password to do
> this. But mod_auth_tkt can help here too. The ticket format
> leaves room for "user data". It is possible to instruct your
> login server to encrypt and store the user password into the
> ticket.
> The reverse proxy takes it out of the envelope and assembles
> the basic auth header for backend access.
>
> Unfortunately, http does not provide a default way to pass
> group tokens within the protocol.
>
> This is not my idea, but I have seen it in practice and it
> looked quite performing.
>
> Now the embedding of the password in the cookie leaves a bad
> taste in my mouth. And I would like to hear some opinions
> on the safety of this practice. I for one feel a bit uneasy,
> but I see the need for easy backend integration.
I think the safety of this practice is subedited to the safety of the
method of storing the password you use. You need to keep the secret that
can reverse the password at good store, and the crypto system that you
use reliable, so that the attacker can't reverse the data easily.
auth_tkts hash has the tokens included, so the encripted data will be
reliable (not tampered with) when you pick it up.
I would, however, try to store a sessionid in the tokens of the ticket,
and use the sessionid as a key to the userid and password data on the
frontend server (so that way it is never "publicly available", and then
proxy with the basic auth. But that is quite more complex, and I don't
know if it could be done with standard Apache modules. Mod_perl would
come handy, buy maybe it's an overkill...
Jose Luis
------------------------------
Message: 7
Date: Wed, 30 Jan 2008 21:33:22 +0100
From: Jose Luis Martinez <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] Blogging about mod_auth_tkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
This code is from the actual migration of an app to mod_auth_tkt, so
please take that into account (we where trying to do as little changes
as possible).
Notes:
- ticket renewal time in this code should be read as "past x seconds
of the ticket generation time, we will extend the ticket for another
session_timeout seconds"... The Apache module treats renewal as a factor
1 for allways renew, 0 for never renew, 0.5 for past half of the
expiration time -> renew the ticket. I think the Catalyst version should
respect that concept (to make thinks homogeneous).
All the controllers that need the user to be authenticated call one
method on the Root controller 'authenticate', that then decides if the
user needs to login or not, so we tried to do all changes there:
sub authenticate : Private {
my ( $self, $c ) = @_;
my $need_login = 1;
# validate_ticket is the controller method that controls
# if the user session is valid, renews if necessary, etc
if ($c->forward('/validate_ticket')){
$need_login = 0;
}
if ($need_login) {
#... show the login screen ...
$c->forward('login');
}
return !$need_login;
}
The login screen then posts the user provided credentials and the back
parameter via POST against the /authticket
sub authticket : Local {
my ( $self, $c ) = @_;
my $username = delete $c->req->params->{login_username};
my $password = delete $c->req->params->{login_password};
if ( $c->login( $username, $password ) ) {
# If Catalyst authentication is succesfull, we extend a ticket, and
redirect them to the original URL.
$c->forward('/extendticket');
$c->res->redirect($c->req->params->{'back'} ||
$c->request->referer());
} else {
$c->stash->{'login_error'} = 'Username or password mismatch';
$c->forward('/login');
}
}
The logic for ticket expiration and ticket renewal is here:
sub validate_ticket : Private {
my ( $self, $c ) = @_;
if (not defined $c->request->cookies->{'auth_tkt'}){
$c->log->debug('No auth_tkt found');
return 0;
};
$c->log->debug('auth_tkt ticket found');
my $tkt = Apache::AuthTkt->new(
secret => $c->config()->{'session'}->{'shared_secret'}
);
# here we were using the parse_ticket before patching the module.
my $info =
$tkt->valid_ticket($c->request->cookies->{'auth_tkt'}->value());
if (not defined $info){
$c->log->warn('auth_tkt detected an invalid ticket');
return 0;
}
# calculate if we can renew the ticket AND its not expired
if (($info->{'ts'} + $c->config->{'session'}->{'expires'}) < time){
# ticket has expired
$c->log->debug('auth_tkt ticket expired');
return 0;
} else {
if (($info->{'ts'} +
$c->config->{'session'}->{'renew_ticket_after'}) <= time){
$c->log->debug('auth_tkt ticket can be renewed');
# valid ticket, but can renew
return 0 unless ($c->user_exists);
$info = $c->forward('/extendticket');
}
# if Catalyst has not logged the user in (first time logging
in), the $c->user object does not exist. We compare the tickets uid to
the user that Catalysts session claims.
return ($c->user_exists() and ($info->{'uid'} eq
$c->user->name()));
}
}
# extend a ticket to the user, and return the info contained in it.
sub extendticket : Local {
my ( $self, $c ) = @_;
my $tkt = Apache::AuthTkt->new(
secret => $c->config()->{'session'}->{'shared_secret'}
);
$c->response->cookies->{'auth_tkt'} = { 'value' => $tkt->ticket(
uid =>
$c->user->name,
ip_addr =>
$c->req->address,
),
'path' => '/' };
$c->log->debug('auth_tkt ticket extended to ' . $c->user->name);
return (
$tkt->parse_ticket($c->response->cookies->{'auth_tkt'}->{'value'}) );
}
I think it should still be the application's responsability to check if
the user is logged in, but when it calls $c->login(user, pass) the
system should extend the ticket transparently. Then, automagically, on
other requests, the ticket should be validated and extended, (I think
the from_session method is the place to do this (do you think so,
Peter?). If the ticket is expired, then from_session should not return
the unserialized user (is this the correct way to tell Catalyst that the
users session expired?).
Hope it helps ;) Don't hesitate to discuss possible design decisions
(that way we can try to make the Catalyst module as standard as possible).
Best Regards,
Jose Luis Martinez
[EMAIL PROTECTED]
------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
------------------------------
_______________________________________________
modauthtkt-users mailing list
modauthtkt-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
End of modauthtkt-users Digest, Vol 15, Issue 4
***********************************************
