Reverse proxy with CAS and wrong service name in ticket

[Matt Hamilton]

[Firstly, any chance list admins could add the actual list posting  
address in the welcome email when you subscribe? I subscribed through  
the web, and no-where does it say what the actual list address is. The  
list seems to have moved several times in the past year, so I've taken  
a guess at the list address... hopefully it is right]

I'm trying to get CAS to work in a reverse proxy configuration. The  
setup is:

1) A cas-ified application running on host: app.example.com
2) A reverse proxy (and xslt transform) server running on  
external.example.com
3) I don't have control over app.example.com and can't really change  
anything on there
4) I have full control of the reverse proxy
5) I have admin login to the CAS server

The reverse proxy (at the moment) has no involvement with CAS itself,  
just rewrites requests going back and forth (incl 301 locations).

The situation I have is that when the app sends the 301 redirect back  
to direct the browser to the CAS login server, the proxy rewrites the  
URL so that the service listed is external.example.com. The user then  
authenticates to the CAS server fine and is redirected back to  
external.example.com with the ticket.

The problem then occurs that the app in the backend (which is fairly  
unaware of the proxy in front) then tries to contact the cas validate  
url with the ticket issued to external.example.com but with the  
service app.example.com. And of course CAS then fails the  
authentication:

2009-08-11 15:51:21,685 ERROR  
[org.jasig.cas.CentralAuthenticationServiceImpl] \
- ServiceTicket [ST-37-W1ekgiXQW0UpwmZ5azMq-cas] with service [http://external.example.com/secure/WebPortal.aspx?module=117AD0B4-063B-4f05-AAE9-B78104ADD 
\
FDF&coll=aa09s202d02j022m0s0odbanana0asd0 does not match supplied  
service [http\
://app.example.com/WebPortal.aspx?module=117AD0B4-063B-4f05-AAE9-B7\
8104ADDFDF&coll=aa09s202d02j022m0s0odbanana0asd0]

Which of course makes sense ;)

The question is: Is there anything I can do to get this to work  
(without changing app.example.com)? I've read up on the proxy  
authentication stuff for CAS and wondering if I can use that in some  
way... but not quite sure how exactly (and getting my head in a twist  
as its talking about proxying authentication, not necessarily proxying  
http requests)

Another workaround I thought of... although I'm aware it could raise  
some security issues.... if a *single* entry in the CAS server matched  
both app.example.com and external.example.com would that make CAS  
happy and accept a ticket from one for the other?

-Matt

--
Matt Hamilton                                       [hidden email]
Netsight Internet Solutions, Ltd.           Understand. Develop. Deliver
http://www.netsight.co.uk                             [phone]
Web Design | Zope/Plone Development & Consulting | Co-location | Hosting


--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Ryan Fox]

----- "Matt Hamilton" <[hidden email]> wrote:

> The reverse proxy (at the moment) has no involvement with CAS itself,
> just rewrites requests going back and forth (incl 301 locations).


I don't know if it's a recommended practice... but I've solved this by cas enabling the proxy, and restricting access to the web server to only allow requests from the proxy.  Best if it can be done on a network layer (web server only attached to network with the proxy, not a network with clients), but the web server can just be set to allow requests only from certain ip's too.  Both methods require some amount of control of the web server, which you've said you don't have, but I wanted to make you aware of the option.

Thanks,
Ryan


--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Matt Hamilton]

On 12 Aug 2009, at 13:56, Ryan Fox wrote:

>
> ----- "Matt Hamilton" <[hidden email]> wrote:
>
>> The reverse proxy (at the moment) has no involvement with CAS itself,
>> just rewrites requests going back and forth (incl 301 locations).
>
>
> I don't know if it's a recommended practice... but I've solved this  
> by cas enabling the proxy, and restricting access to the web server  
> to only allow requests from the proxy.  Best if it can be done on a  
> network layer (web server only attached to network with the proxy,  
> not a network with clients), but the web server can just be set to  
> allow requests only from certain ip's too.  Both methods require  
> some amount of control of the web server, which you've said you  
> don't have, but I wanted to make you aware of the option.

Unfortunately that isn't really an option here. I need the CAS to be  
done on the application server, not the proxy. I'm hacking around at  
the moment, and I think I'm getting close, as I think I've just about  
managed to work out how the CAS authentication proxying works and  
added some code to my front end proxy to get it to work. I managed to  
get it to work when I manually stepped through the process and just  
pasted urls into the browser, but for some reason can't get it to work  
on my code now.

In this particular example the service I am sending to serviceValidate  
is almost the same as the callback url.. they are the same hostname,  
but one is http the other (the callback url) is https. I'm not getting  
back a PGT when I do this, so I'm wondering if the CAS server is not  
allowing a PGT in this scenario?

-Matt

--
Matt Hamilton                                       [hidden email]
Netsight Internet Solutions, Ltd.           Understand. Develop. Deliver
http://www.netsight.co.uk                             [phone]
Web Design | Zope/Plone Development & Consulting | Co-location | Hosting


--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Scott Battaglia-2]

By default CAS will not return a proxy granting ticket over HTTP.  You'd have to modify the configuration, which isn't recommended.

On Wed, Aug 12, 2009 at 9:48 AM, Matt Hamilton <[hidden email]> wrote:

On 12 Aug 2009, at 13:56, Ryan Fox wrote:

----- "Matt Hamilton" <[hidden email]> wrote:

The reverse proxy (at the moment) has no involvement with CAS itself,
just rewrites requests going back and forth (incl 301 locations).

I don't know if it's a recommended practice... but I've solved this by cas enabling the proxy, and restricting access to the web server to only allow requests from the proxy.  Best if it can be done on a network layer (web server only attached to network with the proxy, not a network with clients), but the web server can just be set to allow requests only from certain ip's too.  Both methods require some amount of control of the web server, which you've said you don't have, but I wanted to make you aware of the option.

Unfortunately that isn't really an option here. I need the CAS to be done on the application server, not the proxy. I'm hacking around at the moment, and I think I'm getting close, as I think I've just about managed to work out how the CAS authentication proxying works and added some code to my front end proxy to get it to work. I managed to get it to work when I manually stepped through the process and just pasted urls into the browser, but for some reason can't get it to work on my code now.

In this particular example the service I am sending to serviceValidate is almost the same as the callback url.. they are the same hostname, but one is http the other (the callback url) is https. I'm not getting back a PGT when I do this, so I'm wondering if the CAS server is not allowing a PGT in this scenario?

-Matt

--
Matt Hamilton                                       [hidden email]

Netsight Internet Solutions, Ltd.           Understand. Develop. Deliver
http://www.netsight.co.uk                             [phone]
Web Design | Zope/Plone Development & Consulting | Co-location | Hosting


--

You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Matt Hamilton]

On 12 Aug 2009, at 14:50, Scott Battaglia wrote:

> By default CAS will not return a proxy granting ticket over HTTP.  
> You'd have to modify the configuration, which isn't recommended.


I'm requesting it over https (both the pgtUrl and the url to the cas  
server) only the service itself is http. I think however I might have  
found an issue, the SSL cert for the pgtUrl is self-signed which it  
doesn't seem to like. I read this somewhere, but when I tried one of  
the other self signed urls it works... so I'm guessing someone might  
have manually put some certification chain on the CAS server.

-Matt

--
Matt Hamilton                                       [hidden email]
Netsight Internet Solutions, Ltd.           Understand. Develop. Deliver
http://www.netsight.co.uk                             [phone]
Web Design | Zope/Plone Development & Consulting | Co-location | Hosting


--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Stellan]

Hi Matt,

I have been able to set up CAS behind a reverse proxy, and hopefylly I will be able to help you towards solving the issue...

Matt Hamilton wrote:

The problem then occurs that the app in the backend (which is fairly  
unaware of the proxy in front) then tries to contact the cas validate  
url with the ticket issued to external.example.com but with the  
service app.example.com. And of course CAS then fails the  
authentication:

You should proxy the validate URL as well (assuming your proxy handles the SSL traffic) - i.e. assign it to external.example.com, which in turn proxies it back to your internal validation service. You may have to edit the hosts-file on the host running the CAS server in order to achieve this (in case your DNS is not able to resolve external.example.com to an internal address)

Matt Hamilton wrote:

I think however I might have  
found an issue, the SSL cert for the pgtUrl is self-signed which it  
doesn't seem to like.

If you are using self-signed certificates - you need to add it to the Java truststore used by the CAS server

I have written an article series on how to set up CAS with an Apache based reverse proxy and a Tomcat based back-end. You might find it helpful:

Part 1 – Setting up Apache2 for virtual hosting: http://steelmon.wordpress.com/2009/10/22/setting-up-cas-on-tomcat-with-apache2-and-ssl-on-ubuntu-part-1/


Part 2 – Adding SSL support to Apache2 virtual hosts: http://steelmon.wordpress.com/2009/10/22/setting-up-cas-on-tomcat-with-apache2-and-ssl-on-ubuntu-part-2/


Part 3 – Adding Tomcat behind an Apache2 reverse proxy: http://steelmon.wordpress.com/2009/10/22/setting-up-cas-on-tomcat-with-apache2-and-ssl-on-ubuntu-%e2%80%93-part-3/


Part 4 – Protecting resources with CAS: http://steelmon.wordpress.com/2009/10/23/setting-up-cas-on-tomcat-with-apache2-and-ssl-on-ubuntu-%e2%80%93-part-4/

Good Luck!
Stellan Soderstrom