Phil, thanks so much for your quick response. Based on your analysis, it is clear that mod_auth_cas is doing the right thing.
I need to think a bit more about what to do here. I think that the RESTful client probably needs to treat the service parameter as a redirect and use that authority (host:port) going forward for both getting the service ticket and then accessing the protected resource. More inline: > > Hi, > The information that mod_auth_cas has at its disposition is what can > be accessed via Apache's request_rec structure: > > http://www.temme.net/sander/api/httpd/structrequest__rec.html > > Within this structure, there is an apr_uri_t member, 'parsed_uri'. > > http://apr.apache.org/docs/apr-util/0.9/structapr__uri__t.html > > However, the parsed_uri that is in the request_rec does not contain > fields such as 'hostname', 'scheme', or 'port', so mod_auth_cas takes > a stab at determining that information Based on on what you said, and thinking about this a bit more, I realize that what apache has nothing to do with this (e.g. see this post from 2000: http://markmail.org/message/t4tahmuwv6uooxrz#query:apache%20unparsed_uri+page:1+mid:phi6fe2chzcug6vp+state:results). The original scheme and authority (host:port) is resolved by the client and not sent with the request except in the Host header of HTTP 1.1. So apache doesn't get the orginal scheme or authority except in the HOST header and by knowing what protocol was used (to get the scheme). [...] > > This most likely works well for everyone using mod_auth_cas to > interface with browsers, as mod_auth_cas constructs the service URL > using the logic above to both generate the initial redirect as well as > perform the ticket validation. Unfortunately, since you are using a > RESTful interface, the two may not match. > I agree with your analysis. > I do not believe there is a way within Apache to determine the exact > URL the user initially specified, as Apache only will know the local > port the user connected to. If the 'Host' header sent by the client > contains the port number, you may be able to use that value instead, > however I believe that opens a security risk by trusting the value > sent by the client(see > http://www.ja-sig.org/wiki/display/CASC/CASFilter). Yes, you are right about the security risk. The original authority information was obliterated on the client slide and anything can be sent in the Host header. With small > modifications you could force mod_auth_cas to include the port number > with all service requests by tweaking the getCASService function(set > the 'printPort' boolean value to TRUE always), but this may not be > sufficient for your needs. > > Hope this helps, > -Phil > > On Wed, Mar 11, 2009 at 6:57 PM, <[email protected]> wrote: > > I'm using mod_auth_cas along with CAS RESTful interface to provide > > authentication for my application. We noticed that when > generating the > > "service" parameter for both forwarding to CAS as well as ticket > > validation, mod_auth_cas doesn't use the URL that is given (suitably > > escaped), but rather reconstructs the URI based on various > parameters > > that it gets from Apache. > > > > For example, suppose I reference the following URI: > > > > http://www.example.com:80/foo?ticket=ST-footicket > > > > When mod_auth_cas goes to validate the ticket, it is going > to use this > > in the ticket parameter: > > > > http:/www.example.com/foo > > > > The ticket validation will fail because the ":80" is missing. > > > > This probabably doesn't cause a problem for browser clients > because the > > initial forwarding to the CAS login page will already have > a rewritten > > URI, so that the ticket is issued against the rewritten URI, and the > > forwarding back to mod_auth_cas will happen with the > rewritten URI and > > everything will work. However, since we are using the CAS > restful API > > to prefetch a ticket, the URI rewriting does cause a problem. > > > > Is there a reason for this rewriting behavior? Is there a way to > > disable it? > > > > Thanks, > > > > David Ohsie > > EMC Corporation > > > > > > > > > > -- > > 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 > > > > -- > 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 > > -- 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
