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. Re: mod_auth_tkt & mod_proxy...reverse proxy removes query
string? (Brian Macauley)
2. Re: mod_auth_tkt & mod_proxy...reverse proxy removes query
string? (Brian Macauley)
3. single-signon across completely unrelated domains (Matteo Balasso)
4. Re: mat 2.1.0: Bug and Patch for TKTAuthBackCookieName
(Christian Folini)
5. A feature bugfix/request? (Steffen Yount)
----------------------------------------------------------------------
Message: 1
Date: Tue, 18 Oct 2011 11:34:31 +0100
From: Brian Macauley <brian.macau...@gmail.com>
Subject: Re: [modauthtkt-users] mod_auth_tkt & mod_proxy...reverse
proxy removes query string?
To: Brian Macauley <brian.macau...@gmail.com>,
modauthtkt-users@lists.sourceforge.net
Message-ID:
<caebrghcbedfosy_8aqxvazurbh+2iztfortbxzmsrtc8we5...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Gavin,
Unfortunately, I haven't progressed any further with the debugging.
As we were up against a tight timeline, we converted the backend
application to use PATH_INFO as well as QUERY_STRING and it is all
working very well in production
My hunch is that it could one of 2 things...
(1) Apache mod_proxy with CentOS 5.6 has a subtle bug or
incompatibility with mod_auth_tkt. Looking through the mod_proxy bug
tracker suggests that there have been QUERY_STRING issues in the past.
If we had not succeeded with the PATH_INFO approach my plan was
download the mod_proxy source to either debug the issue or add a
custom environment variable with the QUERY_STRING
(2) The way we are using mod_auth_tkt is a little non-standard. We are
processing a federated login call from Salesforce to generate the
secure cookie using a Python routine. One thing I noticed was that
when we used the 'Require valid-user' config, was that we get a basic
authentication login screen. Without the 'Require valid-user' it works
perfectly. I thought this approach might be causing an issue in either
mod_auth_tkt or mod_proxy
If I get some time, I will investigate further
Brian M
Brian Macauley
email: brian.macau...@gmail.com
mob: 07968124660
On 18 October 2011 05:20, Gavin Carr <ga...@openfusion.com.au> wrote:
> Hi Brian,
>
> Sorry for the slow reply.
>
> This is a pretty weird problem. I can't reproduce it on my laptop,
> which is pretty similar to your setup - CentOS 6, Apache 2.2,
> mod_auth_tkt 2.1.
>
> I used the following config (pretty much cut-and-pasted from yours):
>
> ?<Location /sledge>
> ?AuthType None
> ?Require valid-user
> ?TKTAuthLoginURL http://nox/auth/login.cgi
> ?TKTAuthBackCookieName back
> ?TKTAuthTimeout 2h
> ?TKTAuthCookieExpires 2h
> ?TKTAuthDebug 0
> ?</Location>
>
> ?ProxyRequests on
> ?ProxyPass ? ? ? ? /sledge/ http://localhost:3005/
> ?ProxyPassReverse ?/sledge/ http://localhost:3005/
>
>
> I'm seeing query strings go straight through to the backend app just
> fine, as expected.
>
> Have you got any further debugging this since you posted?
>
> Cheers,
> Gavin
>
>
>
> On Tue, Oct 04, 2011 at 11:57:13AM +0100, Brian Macauley wrote:
>>
>> I have an issue with mod_auth_tkt when used with mod_proxy in a
>> reverse proxy setup.
>>
>> I used this previous mod_auth_tkt thread as reference...
>>
>> http://sourceforge.net/mailarchive/forum.php?thread_name=07A4A9EC53C2B841A7015A2E2FAFD19506C8CA58%40flybe06.flybe.local&forum_name=modauthtkt-users
>>
>> Any URL with a query string has the query string removed when it is
>> proxy'ed to the backend application.
>>
>> eg
>>
>> https://config.mycompany.com/app1/csdmain.vmgw ...works
>> http://app1.mycompany.com:8080/csdmain.vmgw sent
>>
>> https://config.mycompany.com/app1/csdsrch.vmgw ...works
>> http://app1.mycompany.com:8080/csdsrch.vmgw sent
>>
>>
>> https://config.mycompany.com/app1/csdshow.vmgw?mode=text&fname=HIGHPT&ftype=AB1234
>> ..doesn't work
>> http://app1.mycompany.com:8080/csdshow.vmgw is sent to the backend
>> application
>>
>> I am using...
>>
>> CentOS 5.6
>> Apache 2.2
>> mod_auth_tkt 2.1
>>
>> My config is as follows...
>>
>> ServerName config.mycompany.com
>> ServerAlias config.mycompany.com
>>
>> TKTAuthSecret "secret"
>>
>> # all requests for /back/* must be authenticated
>>
>> #AuthType Basic
>> Require valid???user
>> TKTAuthLoginURL https://www.salesforce.com/secur/login.jsp
>> TKTAuthCookieName GBTicket
>> TKTAuthCookieSecure on
>> TKTAuthDomain .mycompany.com
>> #TKTAuthBackArgName
>> TKTAuthBackCookieName back
>> TKTAuthTimeout 2h
>> TKTAuthCookieExpires 2h
>> TKTAuthDebug 0
>>
>>
>> ProxyRequests off
>> ProxyPass /app1/ ??http://app1.mycompany.com:8080/
>> # RewriteEngine on
>> # RewriteRule ^/app1/?$ http://app1.mycompany.com:8080/ [P,L]
>> # RewriteRule ^/app1/(.+)$ http://app1.mycompany.com:8080/$1 [P,L]
>> ProxyPassReverse /app1/ http://app1.mycompany.com:8080/
>>
>> WSGIScriptAlias /login
>> /var/www/public_html/config.mycompany.com/login/adapter.wsgi
>> The application receives a federated login from a salesforce app, and
>> a Python wsgi app creates the GBTicket secure cookie.
>>
>> I have tried both mod_proxy and mod_rewrite for the reverse proxy,
>> with the same result. I have also tried to add the query string back
>> in to the request using mod_rewrite, but it still gets removed.
>>
>> When I disable mod_auth_tkt, the reverse proxy works as normal, and
>> the query string is passed through to the backend application.
>>
>> Do you have any idea why this is happening?
>>
>> Thanks,
>> Brian M
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> modauthtkt-users mailing list
>> modauthtkt-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
>
>
------------------------------
Message: 2
Date: Tue, 18 Oct 2011 11:39:56 +0100
From: Brian Macauley <brian.macau...@gmail.com>
Subject: Re: [modauthtkt-users] mod_auth_tkt & mod_proxy...reverse
proxy removes query string?
To: Brian Macauley <brian.macau...@gmail.com>,
modauthtkt-users@lists.sourceforge.net
Message-ID:
<caebrghabzeg2zxi29q3unpx00+xfgutpb4suuyurftl0evv...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Slight mistake in the last email...
> (2) The way we are using mod_auth_tkt is a little non-standard. We are
> processing a federated login call from Salesforce to generate the
> secure cookie using a Python routine. One thing I noticed was that
> when we used the 'AuthType Basic' config, was that we get a basic
> authentication login screen. Without the 'AuthType Basic' it works
> perfectly. I thought this approach might be causing an issue in either
> mod_auth_tkt or mod_proxy
Brian Macauley
email: brian.macau...@gmail.com
mob: 07968124660
On 18 October 2011 11:34, Brian Macauley <brian.macau...@gmail.com> wrote:
> Gavin,
>
> Unfortunately, I haven't progressed any further with the debugging.
>
> As we were up against a tight timeline, we converted the backend
> application to use PATH_INFO as well as QUERY_STRING and it is all
> working very well in production
>
> My hunch is that it could one of 2 things...
>
> (1) Apache mod_proxy with CentOS 5.6 has a subtle bug or
> incompatibility with mod_auth_tkt. Looking through the mod_proxy bug
> tracker suggests that there have been QUERY_STRING issues in the past.
> If we had not succeeded with the PATH_INFO approach my plan was
> download the mod_proxy source to either debug the issue or add a
> custom environment variable with the QUERY_STRING
>
> (2) The way we are using mod_auth_tkt is a little non-standard. We are
> processing a federated login call from Salesforce to generate the
> secure cookie using a Python routine. One thing I noticed was that
> when we used the 'Require valid-user' config, was that we get a basic
> authentication login screen. Without the 'Require valid-user' it works
> perfectly. I thought this approach might be causing an issue in either
> mod_auth_tkt or mod_proxy
>
> If I get some time, I will investigate further
>
> Brian M
>
>
>
>
> Brian Macauley
> email: brian.macau...@gmail.com
> mob: 07968124660
>
>
>
> On 18 October 2011 05:20, Gavin Carr <ga...@openfusion.com.au> wrote:
>> Hi Brian,
>>
>> Sorry for the slow reply.
>>
>> This is a pretty weird problem. I can't reproduce it on my laptop,
>> which is pretty similar to your setup - CentOS 6, Apache 2.2,
>> mod_auth_tkt 2.1.
>>
>> I used the following config (pretty much cut-and-pasted from yours):
>>
>> ?<Location /sledge>
>> ?AuthType None
>> ?Require valid-user
>> ?TKTAuthLoginURL http://nox/auth/login.cgi
>> ?TKTAuthBackCookieName back
>> ?TKTAuthTimeout 2h
>> ?TKTAuthCookieExpires 2h
>> ?TKTAuthDebug 0
>> ?</Location>
>>
>> ?ProxyRequests on
>> ?ProxyPass ? ? ? ? /sledge/ http://localhost:3005/
>> ?ProxyPassReverse ?/sledge/ http://localhost:3005/
>>
>>
>> I'm seeing query strings go straight through to the backend app just
>> fine, as expected.
>>
>> Have you got any further debugging this since you posted?
>>
>> Cheers,
>> Gavin
>>
>>
>>
>> On Tue, Oct 04, 2011 at 11:57:13AM +0100, Brian Macauley wrote:
>>>
>>> I have an issue with mod_auth_tkt when used with mod_proxy in a
>>> reverse proxy setup.
>>>
>>> I used this previous mod_auth_tkt thread as reference...
>>>
>>> http://sourceforge.net/mailarchive/forum.php?thread_name=07A4A9EC53C2B841A7015A2E2FAFD19506C8CA58%40flybe06.flybe.local&forum_name=modauthtkt-users
>>>
>>> Any URL with a query string has the query string removed when it is
>>> proxy'ed to the backend application.
>>>
>>> eg
>>>
>>> https://config.mycompany.com/app1/csdmain.vmgw ...works
>>> http://app1.mycompany.com:8080/csdmain.vmgw sent
>>>
>>> https://config.mycompany.com/app1/csdsrch.vmgw ...works
>>> http://app1.mycompany.com:8080/csdsrch.vmgw sent
>>>
>>>
>>> https://config.mycompany.com/app1/csdshow.vmgw?mode=text&fname=HIGHPT&ftype=AB1234
>>> ..doesn't work
>>> http://app1.mycompany.com:8080/csdshow.vmgw is sent to the backend
>>> application
>>>
>>> I am using...
>>>
>>> CentOS 5.6
>>> Apache 2.2
>>> mod_auth_tkt 2.1
>>>
>>> My config is as follows...
>>>
>>> ServerName config.mycompany.com
>>> ServerAlias config.mycompany.com
>>>
>>> TKTAuthSecret "secret"
>>>
>>> # all requests for /back/* must be authenticated
>>>
>>> #AuthType Basic
>>> Require valid???user
>>> TKTAuthLoginURL https://www.salesforce.com/secur/login.jsp
>>> TKTAuthCookieName GBTicket
>>> TKTAuthCookieSecure on
>>> TKTAuthDomain .mycompany.com
>>> #TKTAuthBackArgName
>>> TKTAuthBackCookieName back
>>> TKTAuthTimeout 2h
>>> TKTAuthCookieExpires 2h
>>> TKTAuthDebug 0
>>>
>>>
>>> ProxyRequests off
>>> ProxyPass /app1/ ??http://app1.mycompany.com:8080/
>>> # RewriteEngine on
>>> # RewriteRule ^/app1/?$ http://app1.mycompany.com:8080/ [P,L]
>>> # RewriteRule ^/app1/(.+)$ http://app1.mycompany.com:8080/$1 [P,L]
>>> ProxyPassReverse /app1/ http://app1.mycompany.com:8080/
>>>
>>> WSGIScriptAlias /login
>>> /var/www/public_html/config.mycompany.com/login/adapter.wsgi
>>> The application receives a federated login from a salesforce app, and
>>> a Python wsgi app creates the GBTicket secure cookie.
>>>
>>> I have tried both mod_proxy and mod_rewrite for the reverse proxy,
>>> with the same result. I have also tried to add the query string back
>>> in to the request using mod_rewrite, but it still gets removed.
>>>
>>> When I disable mod_auth_tkt, the reverse proxy works as normal, and
>>> the query string is passed through to the backend application.
>>>
>>> Do you have any idea why this is happening?
>>>
>>> Thanks,
>>> Brian M
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>> _______________________________________________
>>> modauthtkt-users mailing list
>>> modauthtkt-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
>>
>>
>
------------------------------
Message: 3
Date: Tue, 18 Oct 2011 13:29:16 +0200
From: Matteo Balasso <m.bala...@scsitaly.com>
Subject: [modauthtkt-users] single-signon across completely unrelated
domains
To: modauthtkt-users@lists.sourceforge.net
Message-ID:
<CALZ262fUKQeOo17baDYcuwEHOC8o1UBTT=xqptnkrzd3gcu...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Dear Gavin,
As for mod_auth_tkt documentation, it supports:
Cross-domain authentication support: (as of version 1.3.8) although
cookies are domain specific, the newest version of mod_auth_tkt allows
initial tickets to be passed via URLs, allowing single-signon across
completely unrelated domains (www.foo.com and www.bar.com).
I was able to set i t up for multiple subdomains, but despite my
efforts, I was unable to set it up correctly for unrelated domains. Is
there an example, tutorial or more detailed documentation I can read
to set up the desired feature?
Thanks for your help.
Best Regards,
Matteo
--
Matteo Balasso
BioComputing Competence Center
SCS s.r.l. Via Parini 1, 40033 Casalecchio di Reno, Italy
Map: http://bit.ly/czAFT3
www: http://www.scsitaly.com
<http://www.scsolutions.it/>Tel: +39 051 590199
Fax: +39 051 19901095
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 4
Date: Tue, 1 Nov 2011 22:00:50 +0100
From: Christian Folini <christian.fol...@netnea.com>
Subject: Re: [modauthtkt-users] mat 2.1.0: Bug and Patch for
TKTAuthBackCookieName
To: Christian Folini <fol...@netnea.com>,
modauthtkt-users@lists.sourceforge.net, dune73
<dun...@localhost.netnea.com>
Message-ID: <20111101210050.GC18192@localhost>
Content-Type: text/plain; charset=utf-8
Hi Gavin,
On Mon, Oct 17, 2011 at 03:06:25PM +1100, Gavin Carr wrote:
> Thanks for the patch, finally got to it today.
You see, I am not much faster. :)
> I think TKTAuthBackCookieName is okay here (apart from the error message) -
> if it's not set you don't get a back cookie at all.
Maybe I did something wrong then. It did not work for me.
> TKTAuthBackArgName should be able to be turned off though, and can't be
> in 2.1.0 - I think that's the core bug here.
If that is the intended behaviour, that's ok with me.
> I've pushed an update to https://github.com/gavincarr/mod_auth_tkt that
> should fix this - you can now set 'TKTAuthBackArgName None' to turn off
> the back argument altogether. Can you check if that does what you need?
Yes it does. Perfect. Problem solved for me. Thank you.
Best,
Christian
--
The horizon of many people is a circle with zero radius
which they call their point of view.
-- Albert Einstein
------------------------------
Message: 5
Date: Fri, 4 Nov 2011 01:25:13 -0700
From: Steffen Yount <stef...@yount.name>
Subject: [modauthtkt-users] A feature bugfix/request?
To: modauthtkt-users@lists.sourceforge.net
Message-ID:
<caobh0xbrtyqzoxbidxvlak_nestqst+aofuznxhxiiibsyb...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Here's what I'm trying to do:
User A logs in and checks the "remember me" box on my login form
I set the mod_auth_tkt cookie with an "expires" value sometime in the
semi-distant future
User B logs in and doesn't check the "remember me" box on my login form
I set the mod_auth_tkt cookie with no "expires" value making it a session
cookie
When these 2 cookies are presented to the mod_auth_tkt module after their
TKTAuthTimeoutRefresh timeout has been triggered, I'd like to see:
User A's cookie refreshed with the same "expires" value set leaving it as a
persistent cookie.
User B's cookie refreshed with no "expires" value set leaving it as a
session cookie.
I believe that implementing this would require the "expires" value to be
encoded into the cookie so that the mod_auth_tkt module has enough
information at renewal time to make this work.
Is this something one of you could implement pretty easily?
Is this something that already works and I just missed it?
Would one of you be willing to implement this?
Thanks,
-Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
------------------------------
_______________________________________________
modauthtkt-users mailing list
modauthtkt-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/modauthtkt-users
End of modauthtkt-users Digest, Vol 28, Issue 1
***********************************************
