On 12 Aug 2009, at 13:56, Ryan Fox wrote:
----- "Matt Hamilton" <[email protected]> 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 [email protected]
Netsight Internet Solutions, Ltd. Understand. Develop. Deliver
http://www.netsight.co.uk +44 (0)117 9090901
Web Design | Zope/Plone Development & Consulting | Co-location | Hosting
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
