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: Catalyst AuthTkt (was: Blogging about mod_auth_tkt)
(Peter Karman)
2. Re: Catalyst AuthTkt (Peter Karman)
3. Re: Catalyst AuthTkt (Jose Luis Martinez)
4. DSA/RSA based derivative of mod_auth_tkt (Manuel Kasper)
5. Re: DSA/RSA based derivative of mod_auth_tkt (Peter Karman)
6. Re: DSA/RSA based derivative of mod_auth_tkt (Manuel Kasper)
7. Re: DSA/RSA based derivative of mod_auth_tkt (Jose Luis Martinez)
8. Re: DSA/RSA based derivative of mod_auth_tkt (Manuel Kasper)
9. Re: DSA/RSA based derivative of mod_auth_tkt (Manuel Kasper)
----------------------------------------------------------------------
Message: 1
Date: Wed, 30 Jan 2008 14:50:59 -0600
From: Peter Karman <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] Catalyst AuthTkt (was: Blogging about
mod_auth_tkt)
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8
On 01/30/2008 02:33 PM, Jose Luis Martinez wrote:
>
> 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?).
>
Yes, I see the functionality overlapping somewhat with both the Session and
Authentication
plugin space. I'll ask on the Cat list what would be the best route to go.
Thanks for posting this.
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
------------------------------
Message: 2
Date: Wed, 30 Jan 2008 15:52:24 -0600
From: Peter Karman <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] Catalyst AuthTkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8
On 01/30/2008 02:50 PM, Peter Karman wrote:
>
> On 01/30/2008 02:33 PM, Jose Luis Martinez wrote:
>
>> 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?).
>>
>
> Yes, I see the functionality overlapping somewhat with both the Session and
> Authentication
> plugin space. I'll ask on the Cat list what would be the best route to go.
>
As I composed an email to the Cat list about this, it became clear (at least to
me) about
the proper approach.
All the points you make above are correct, except for one: $c->login() is
deprecated now
in favor of $c->authenticate().
The only thing you mention that the current ::AuthTkt implementation does not
do is to
extend the cookie expiration time at each request. I will implement that in the
next
version as something like extend_ticket(). extend_ticket() needs to be
implemented
independently of from_session() in case a C::P::Session::Store is not
available, but
from_session() should also call extend_ticket() and re-save the new ticket in
the User
object in the session. That has the added benefit of allowing the ticket to be
handled as
a param instead of a cookie if the application wants to do it that way. So in
your View
you could do:
<input name="auth_tkt" value="[% c.user.ticket %]" type="hidden" />
and pass it around that way.
You ask:
>> 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?).
It appears to be so. A quick grok of the C::P::A source indicates that
returning undef
from from_session() will result in $c->user returning undef. However, we'll
want some
tests to verify that.
::AuthTkt is a little trickier than most auth plugins because of the whole
session-expiration feature. Looks like most of the work to be done is in
::Store::AuthTkt.
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
------------------------------
Message: 3
Date: Thu, 31 Jan 2008 10:12:31 +0100
From: Jose Luis Martinez <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] Catalyst AuthTkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
One thing that I left out:
the IgnoreIP Option:
ip_addr => ($c->config->{...}->{'ignore_ip'}?'0.0.0.0':$c->req->address)
in the constructor of the tickets. In this application it was not used,
but it has come in handy in the past.
Other things that the module supports: guest login (this one is
deprecated), and this can be handled more conveniently by Catalyst (only
taking decisions based on $c->user_exists. I suppose this was a
limitation of the module due to having to autenticate all requests.
The optional RequireSSL option for the cookie (-secure option of
CGI::Cookie in login.cgi)
- CookieSecure option: don't know what it is (I've been searching
through login.cgi and AuthTkt.pm and can't find any code that treats it).
Jose Luis Martinez
[EMAIL PROTECTED]
------------------------------
Message: 4
Date: Sun, 3 Feb 2008 23:02:54 +0100
From: Manuel Kasper <[EMAIL PROTECTED]>
Subject: [modauthtkt-users] DSA/RSA based derivative of mod_auth_tkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hello,
while looking for a simple web single sign-on solution for the company
that I work for, I stumbled upon mod_auth_tkt, and soon knew that this
was the way to go for our needs. However, the fact that it uses a
shared secret with MD5 (thus putting the master secret in each
participating web server's config) prevented us from actually
deploying it.
I've therefore decided to modify mod_auth_tkt and create a new module
(named mod_auth_pubtkt) that can use either DSA or RSA to verify the
ticket - thus only the login server needs the private key, while the
other web servers can work with just the public key.
While I assume that most of those on this mailing list are happy with
mod_auth_tkt, I thought that some might be interested in my module,
and so I decided to share it here. My big thanks go out to the authors
of mod_auth_tkt; it was very helpful to have a working module to start
with, and I was able to reuse a lot of code.
Here's the web page with a detailed description, instructions and the
download:
https://neon1.net/mod_auth_pubtkt
It currently mandates the use of domain cookies, which still poses the
(smaller) problem of cookie/ticket theft by rogue web servers under
the same domain.
I've successfully deployed the module on a few Apache 2.0 servers in
one domain, and I've also done some cursory testing under Apache 1.3
and 2.2 - but only under FreeBSD and Mac OS X. Feedback is welcome, of
course.
Regards,
Manuel
------------------------------
Message: 5
Date: Mon, 04 Feb 2008 08:07:26 -0600
From: Peter Karman <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] DSA/RSA based derivative of
mod_auth_tkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8
On 02/03/2008 04:02 PM, Manuel Kasper wrote:
> I've therefore decided to modify mod_auth_tkt and create a new module
> (named mod_auth_pubtkt) that can use either DSA or RSA to verify the
> ticket - thus only the login server needs the private key, while the
> other web servers can work with just the public key.
>
sounds like a cool idea. I especially like not needing to keep the secret in
multiple places.
Any plans to offer alternate implementations (a'la Apache::AuthTkt perl module)?
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
------------------------------
Message: 6
Date: Mon, 4 Feb 2008 19:28:32 +0100
From: Manuel Kasper <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] DSA/RSA based derivative of
mod_auth_tkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On 04.02.2008, at 15:07, Peter Karman wrote:
> Any plans to offer alternate implementations (a'la Apache::AuthTkt
> perl module)?
It should be pretty easy to implement the ticket generation/signing in
another script language (e.g. by directly calling the openssl binary,
as in my PHP example); it's possible that I'll eventually provide a
ready-made Perl module for this purpose, but I won't make any promises
yet. ;)
- Manuel
------------------------------
Message: 7
Date: Tue, 05 Feb 2008 09:40:40 +0100
From: Jose Luis Martinez <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] DSA/RSA based derivative of
mod_auth_tkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Looks like a great module.
One thing that would be nice is a method for ticket refreshing (the
login server would only have to extend a valid ticket for more time).
Users tend to get frustrated if a system logs them off suddenly for no
apparent reason. This makes you put big validity times on the tickets.
Jose Luis Martinez
[EMAIL PROTECTED]
------------------------------
Message: 8
Date: Tue, 5 Feb 2008 16:32:46 +0100
From: Manuel Kasper <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] DSA/RSA based derivative of
mod_auth_tkt
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On 05.02.2008, at 09:40, Jose Luis Martinez wrote:
> One thing that would be nice is a method for ticket refreshing (the
> login server would only have to extend a valid ticket for more time).
> Users tend to get frustrated if a system logs them off suddenly for no
> apparent reason. This makes you put big validity times on the tickets.
Sure - there's no reason why this cannot be implemented in the login
server. mod_auth_pubtkt isn't involved in that (and aside from the
example in PHP, it doesn't aim to provide a login server solution -
just the verification module for Apache). If anybody volunteers to
provide such an extension for the PHP example, I'll gladly include it
in the distribution. :)
- Manuel
------------------------------
Message: 9
Date: Tue, 5 Feb 2008 20:53:44 +0100
From: Manuel Kasper <[EMAIL PROTECTED]>
Subject: Re: [modauthtkt-users] DSA/RSA based derivative of
mod_auth_tkt
To: Christian Folini <[EMAIL PROTECTED]>
Cc: modauthtkt-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On 05.02.2008, at 20:42, Christian Folini wrote:
> But what happens at the end of refresh.php? A redirect back
> like in the back-cookie during the login? Not feasible, as the
> initial request hitting the refresh limit might have been a POST
> request and there is no redirect for post-requests, where you could
> keep the request body. A follow-up to a post request is always a get
> request or you have to do some javascript stunts. As far as I can
> tell.
Yes, you're right - it wouldn't work for POSTs of course. Personally,
I don't find ticket refreshing a terribly important feature - if it
wasn't for the possibility of stealing (by rogue servers under your
domain) or sniffing (if using plain HTTP) tickets, you might just as
well use a longer lifetime.
If you're concerned, then I'd suggest not using domain cookies (being
able to do so would require backporting the GET ticket processing
stuff from mod_auth_tkt, but I'm probably going to do that anyway for
the next version - see https://neon1.net/mod_auth_pubtkt/
install.html#domain_cookies) and forcing the use of HTTPS.
> However, if you manage to provide mod_auth_pubtkt including
> refreshing, then it would be really cool.
Well, if you have an idea on how to best implement that, let me know.
> How does the decryption compare to the shared secret decryption
> performance-wise?
This is explained in detail here:
https://neon1.net/mod_auth_pubtkt/install.html
#dsa_or_rsa - but the gist is that a modern CPU can do > 4000
verifications per second (with 1024-bit RSA), and mod_auth_pubtkt
caches verified tickets so that it's not even necessary to do a
verification for each request.
- Manuel
------------------------------
-------------------------------------------------------------------------
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 16, Issue 1
***********************************************
