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
modauthtkt-users-requ...@lists.sourceforge.net
You can reach the person managing the list at
modauthtkt-users-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of modauthtkt-users digest..."
Today's Topics:
1. PHP login script (Charles Bueche)
2. Re: PHP login script (Peter Karman)
3. ticket time out and http post handling (Jan Smets)
4. Re: ticket time out and http post handling (Christian Folini)
5. Re: ticket time out and http post handling (Jan Smets)
6. Re: ticket time out and http post handling (Christian Folini)
7. Re: ticket time out and http post handling (Jan Smets)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Aug 2014 22:47:16 +0200
From: Charles Bueche <cbli...@bueche.ch>
Subject: [modauthtkt-users] PHP login script
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <53ee71d4.9060...@bueche.ch>
Content-Type: text/plain; charset=ISO-8859-1
Dear tkt-issuers and list members,
After 7 years without any appropriate need for it, I'm back into the
"SSO world" and did notice that mod_auth_tkt is still the workhorse of
choice for small infrastructures and budgets. Even better, it's now
integrated in Ubuntu. Great work !
My particular project is on Ubuntu 14.04, with 3 parallel and
independent Apache reverse-proxies that must be behind mod_auth_tkt and
sharing the same login, ticket, etc. The login server is a distinct
Apache instance.
For diverse reasons, I don't want perl/mod_perl for the login server and
scripts, but PHP. I have successfully written a very small login.php
which uses the auth_ticket.inc.php code from the contrib directory.
However, before I reverse-engineer and recode the perl CGI stuff into
PHP, did someone already do the job and code something solid and modular
? Sharing it would be very generous !
My auth back-end is LDAP, but I can adapt code.
If I end up with something modular and not too project-specific, I will
be glad to submit some code to contrib.
TIA and best regards,
Charles
------------------------------
Message: 2
Date: Fri, 15 Aug 2014 16:30:26 -0500
From: Peter Karman <pe...@peknet.com>
Subject: Re: [modauthtkt-users] PHP login script
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <53ee7bf2.2080...@peknet.com>
Content-Type: text/plain; charset=ISO-8859-1
Charles Bueche wrote on 8/15/14 3:47 PM:
> For diverse reasons, I don't want perl/mod_perl for the login server and
> scripts, but PHP. I have successfully written a very small login.php
> which uses the auth_ticket.inc.php code from the contrib directory.
> However, before I reverse-engineer and recode the perl CGI stuff into
> PHP, did someone already do the job and code something solid and modular
> ? Sharing it would be very generous !
>
We developed a mod_auth_tkt PHP class of our own to mirror the Perl version, and
have relevant login code here:
https://github.com/publicinsightnetwork/audience-insight-repository/blob/master/lib/shared/Apache_AuthTkt.php
https://github.com/publicinsightnetwork/audience-insight-repository/blob/master/app/libraries/AirUser.php
https://github.com/publicinsightnetwork/audience-insight-repository/blob/master/app/controllers/login_controller.php
It's not a clean port of the Perl login.cgi code, but it might help get you
started. The Apache_AuthTkt.php class should ease most of the logic.
--
Peter Karman . http://peknet.com/ . pe...@peknet.com
------------------------------
Message: 3
Date: Mon, 20 Oct 2014 11:57:05 +0200
From: Jan Smets <jan.sm...@alcatel-lucent.com>
Subject: [modauthtkt-users] ticket time out and http post handling
To: <modauthtkt-users@lists.sourceforge.net>
Message-ID: <5444dc71.5090...@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Hi!
I'm new to mod_auth_tkt and I've been using it for a couple of weeks
now. Great stuff.
I was wondering if there is a way to improve transparent http post
handling whenever a ticket timeouts and needs to get renewed.
I have a authentication portal that automatically validates and
renews/refreshes the tickets every 4 hours. It works great and is
completely transparent for GET requests. HTTP POST requests are a bit
annoying... Currently it would (more or less) require the user to
re-submit his form after refreshing the ticket.
I was wondering if it would be possible to store the POST data securely
in a cookie. This could be done by the 'remote' webserver that redirects
the client to the authentication portal. Then the portal could
validate/renew the ticket and redirect the client back, which would
result in a GET request to the original location.
Now, afaik, there is no way to have the browser re-post it's form data,
correct?
Could we have mod_auth_tkt transparently change the GET request into a
POST one if that one cookie is found (and valid)?
If there are any other methods for handling such POST cases please let
me know.
Thanks!
- Jan
------------------------------
Message: 4
Date: Mon, 20 Oct 2014 20:51:51 +0200
From: Christian Folini <christian.fol...@time-machine.ch>
Subject: Re: [modauthtkt-users] ticket time out and http post handling
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <20141020185151.GB23279@elias>
Content-Type: text/plain; charset=utf-8
Jan,
This sounds like a bad hack.
I suggest you work with TKTAuthTimeout and TKTAuthTimeoutRefresh.
If your TKTAuthTimeout is 4h and you set the TKTAuthTimeoutRefresh
to 0.75, thy cookie will be refreshed after one hour, or three
hours before the timeout is reached.
In my experience it is very rare, that users fall into the
"POST after timeout" trap is configured properly. If you can safeguard
your application so that navigating back to the form restores their
entered data, then that is certainly convenient for those users who
stumble nevertheless.
Best,
Christian
On Mon, Oct 20, 2014 at 11:57:05AM +0200, Jan Smets wrote:
> Hi!
>
> I'm new to mod_auth_tkt and I've been using it for a couple of weeks
> now. Great stuff.
>
> I was wondering if there is a way to improve transparent http post
> handling whenever a ticket timeouts and needs to get renewed.
>
> I have a authentication portal that automatically validates and
> renews/refreshes the tickets every 4 hours. It works great and is
> completely transparent for GET requests. HTTP POST requests are a bit
> annoying... Currently it would (more or less) require the user to
> re-submit his form after refreshing the ticket.
>
> I was wondering if it would be possible to store the POST data securely
> in a cookie. This could be done by the 'remote' webserver that redirects
> the client to the authentication portal. Then the portal could
> validate/renew the ticket and redirect the client back, which would
> result in a GET request to the original location.
> Now, afaik, there is no way to have the browser re-post it's form data,
> correct?
>
> Could we have mod_auth_tkt transparently change the GET request into a
> POST one if that one cookie is found (and valid)?
>
> If there are any other methods for handling such POST cases please let
> me know.
>
> Thanks!
>
> - Jan
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> modauthtkt-users mailing list
> modauthtkt-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
------------------------------
Message: 5
Date: Mon, 20 Oct 2014 22:44:38 +0200
From: Jan Smets <jan.sm...@alcatel-lucent.com>
Subject: Re: [modauthtkt-users] ticket time out and http post handling
To: <modauthtkt-users@lists.sourceforge.net>
Message-ID: <54457436.1040...@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Hi!
Thank you for your reply.
I have TKTAuthTimeoutRefresh set to 0 because I want the portal to renew
the session, not any random webserver. So the 'POST after timeout'
happens quite frequently.
Unfortunately I do not control the applications and it would be really
an added value if this situation could be handed transparently.
A bad hack is still a feature if solves a problem ;-)
Thanks
Jan
Christian Folini schreef op 20/10/2014 20:51:
> Jan,
>
> This sounds like a bad hack.
>
> I suggest you work with TKTAuthTimeout and TKTAuthTimeoutRefresh.
>
> If your TKTAuthTimeout is 4h and you set the TKTAuthTimeoutRefresh
> to 0.75, thy cookie will be refreshed after one hour, or three
> hours before the timeout is reached.
>
> In my experience it is very rare, that users fall into the
> "POST after timeout" trap is configured properly. If you can safeguard
> your application so that navigating back to the form restores their
> entered data, then that is certainly convenient for those users who
> stumble nevertheless.
>
> Best,
>
> Christian
>
> On Mon, Oct 20, 2014 at 11:57:05AM +0200, Jan Smets wrote:
>> Hi!
>>
>> I'm new to mod_auth_tkt and I've been using it for a couple of weeks
>> now. Great stuff.
>>
>> I was wondering if there is a way to improve transparent http post
>> handling whenever a ticket timeouts and needs to get renewed.
>>
>> I have a authentication portal that automatically validates and
>> renews/refreshes the tickets every 4 hours. It works great and is
>> completely transparent for GET requests. HTTP POST requests are a bit
>> annoying... Currently it would (more or less) require the user to
>> re-submit his form after refreshing the ticket.
>>
>> I was wondering if it would be possible to store the POST data securely
>> in a cookie. This could be done by the 'remote' webserver that redirects
>> the client to the authentication portal. Then the portal could
>> validate/renew the ticket and redirect the client back, which would
>> result in a GET request to the original location.
>> Now, afaik, there is no way to have the browser re-post it's form data,
>> correct?
>>
>> Could we have mod_auth_tkt transparently change the GET request into a
>> POST one if that one cookie is found (and valid)?
>>
>> If there are any other methods for handling such POST cases please let
>> me know.
>>
>> Thanks!
>>
>> - Jan
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://p.sf.net/sfu/Zoho
>> _______________________________________________
>> modauthtkt-users mailing list
>> modauthtkt-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> modauthtkt-users mailing list
> modauthtkt-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
------------------------------
Message: 6
Date: Mon, 20 Oct 2014 22:56:58 +0200
From: Christian Folini <christian.fol...@time-machine.ch>
Subject: Re: [modauthtkt-users] ticket time out and http post handling
To: modauthtkt-users@lists.sourceforge.net
Message-ID: <20141020205658.GA28012@elias>
Content-Type: text/plain; charset=utf-8
Hello!
On Mon, Oct 20, 2014 at 10:44:38PM +0200, Jan Smets wrote:
> Thank you for your reply.
You are welcome.
> I have TKTAuthTimeoutRefresh set to 0 because I want the portal to renew
> the session, not any random webserver.
You should not use mod_auth_tkt to build a trust relationship based on a
shared secret with a random webserver. If you trust that server, then
the design favors having that server renew the session. It works like a
charm, and mod_auth_tkt has a very convenient way to support rolling
update of the shared secret.
> So the 'POST after timeout'
> happens quite frequently.
With TKTAuthTimeoutRefresh set to 0, I am not surprised.
> A bad hack is still a feature if solves a problem ;-)
Sorry, I do not get your reasoning.
It is a problem you have built yourself. I really think you should stick
to the default design of mod_auth_tkt here.
If you take the other road, you are likely to be eaten by dragons.
Ahoj,
Christian
--
We used to think that if we knew one, we knew two, because one and one
are two. We are finding that we must learn a great deal more about 'and'.
-- Sir Arthur Eddington
------------------------------
Message: 7
Date: Mon, 20 Oct 2014 23:13:44 +0200
From: Jan Smets <jan.sm...@alcatel-lucent.com>
Subject: Re: [modauthtkt-users] ticket time out and http post handling
To: <modauthtkt-users@lists.sourceforge.net>
Message-ID: <54457b08.2060...@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
The problem with that is that I don't have a good control over expired
accounts. In theory a user could tamper with the cookie and keep on refreshing
his ticket, and so keep his account valid indefinitely.
Yes, I know it's unlikely to happen, but you never know ...
How do I efficiently check for expired accounts or for changed roles? At some
point I would like the user to pass through the ticketing application to
'refresh' it's permissions, etc ... and I kind of force that by setting
TKTAuthTimeoutRefresh to 0.
An option to have the ticket portal do a refresh would also help.
Ps, I have also reported a bug in Apache::AuthTkt :
https://rt.cpan.org/Public/Bug/Display.html?id=98991 I'm interested to know
if there are any free auth_tkt portals out there (besides auth_tkt-cgi) that I
could use as source of inspiration.
Thanks
Jan
Christian Folini schreef op 20/10/2014 22:56:
> Hello!
>
> On Mon, Oct 20, 2014 at 10:44:38PM +0200, Jan Smets wrote:
>> Thank you for your reply.
> You are welcome.
>
>> I have TKTAuthTimeoutRefresh set to 0 because I want the portal to renew
>> the session, not any random webserver.
> You should not use mod_auth_tkt to build a trust relationship based on a
> shared secret with a random webserver. If you trust that server, then
> the design favors having that server renew the session. It works like a
> charm, and mod_auth_tkt has a very convenient way to support rolling
> update of the shared secret.
>
>> So the 'POST after timeout'
>> happens quite frequently.
> With TKTAuthTimeoutRefresh set to 0, I am not surprised.
>
>> A bad hack is still a feature if solves a problem ;-)
> Sorry, I do not get your reasoning.
>
> It is a problem you have built yourself. I really think you should stick
> to the default design of mod_auth_tkt here.
>
> If you take the other road, you are likely to be eaten by dragons.
>
> Ahoj,
>
> Christian
>
>
------------------------------
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
------------------------------
_______________________________________________
modauthtkt-users mailing list
modauthtkt-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
End of modauthtkt-users Digest, Vol 30, Issue 1
***********************************************
