Proxy requires a seperate URL for the pgtUrl #19
Comments
|
Hello Ravindra, As I understand it, here is what should be happening when a request comes in with a PGTIOU:
I'm not sure what is going on that would prevent your initial
If you are still stuck try using |
|
Are you using the examples we are supplying with phpCAS? If not please share the code with us. Please post the debug log as Adam has already suggested. This is pretty much the only way we might be able to track this issue down and may even be able to reproduce the error on our end. Have you tried running the examples we ship with phpCAS? |
|
Thanks to both of you for the quick response. I think I may not have explained my issue correctly. phpCAS works properly when it receives the The culprit is the second call which is This call is made by the CAS server to validate that the proxy exists and is having a valid SSL certificate. Instead of sending a The issue is not with SSL certificates. Because when I patched the phpCAS code to send a Following is an extract from http://www.jasig.org/cas/protocol We also ran the step by step CAS instructions at https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough, and again when the CAS server tried to do a simple GET request to the pgtUrl, phpCAS did the redirect, and the process fails. The code that does not work is the example that is supplied with phpCAS. I will trim the real server names from the phpCAS log and attach. We are using CAS 2 protocol with a CAS 3.4.11 server. |
|
I apologize, by mistake I closed the issue. Reopening now. |
|
Please find the phpCAS debug log below. Thank for the support and your effort in developing and maintaining a php library for CAS. |
|
I think a wrong decision is taken in Client.php line 2743. A proxy() does not have to have an allow proxy chain to choose the proxyValidate Url. I think is should be something like (proxy || (service && begingProxiedAllowed)). Will investigate further tomorrow unless someone else figures it out. |
|
Mmh somehow i can't reproduce your problem and my last post seems to be wrong. I have commited a small patch to give us a bit more debug output in one of the functions that might be relevant. Please try the lastest version to get me a bit more info. In your debug.log im definately missing a callback from the server and that is very strange. |
|
After having another quick look at your logs: In the server response (Response Body) you "should" also get a: At the same time the callback should come back from the cas server to the proxy and deliver a matching pair of PGTIOU and PGT. Since both is not happening the question is really why this call is redirected according to your log. For this we definately need your code (send by mail if you want) or some info what you are using. In the current state i can't reproduce. |
|
I will post the phpCAS code usage we have. It is not much different to the example. However, I think I did not get my point through. The callback which Joachim investigated works fine if we get to that step. CAS server performs two calls to the pgtUrl
In terms of CAS server, when I inspect the By adding the following few lines of code before we run the phpCAS example code, we managed to have the CAS server issue the PGTIOU and the PGT. Then through the browser we call Then the browser is redirected the CAS server, we enter the user name and password. CAS server validates against the database, then tries to validate the pgtUrl Because of the if condition we added, we prevent phpCAS from executing, and simply return "done". If we do not have that switch then phpCAS would perform a redirect to CAS server, and CAS server decides that it could not validate the pgtUrl. Now CAS server is happy that pgtUrl sent a 200 response, it generates the PGT and PGTIOU, and calls back the pgtUrl with those values. And then CAS server redirects the browser back to the calling application with the service ticket What I am trying to say is that, it is the simple GET request to validate the pgtUrl that fails. Everything before and after works, if we get the validation step correct. May be to clear my point I will ask a question. What would phpCAS do if CAS server does a simple (without any PGT or PGTIOU) GET request to the pgtUrl? |
|
Following is the code that fails CAS server validation. Thus CAS server does not issue PGT or PGTIOU |
|
By simply adding as in the following example, CAS server validates the pgtUrl. Thus CAS serve issues the PGT and PGTIOU. |
|
Sorry but somehow you server behaviour is different than mine. My CAS server (jasig 3.4.11 i believe) does deliver a PGT even after a 302 "error" (see a log one of my tests). What version and server are you running? Somehow it also does not fit your described situation when hardcoding the callback url works. phpCAS will always deliver a 302 to any anonymous request.
The first call a is a pure dummy call to validate your proxy ssl cert against the trusted certstore on the cas server side. If it fails a valdiation (trust, dns or ip, validity) no PGT will be transmitted. Usually this is the problem when a PGT is not transmitted in the callback and no PGTIOU is added to the server answer. The log excerpt from the cas server however suggest some other validation failure on the cas server side. No idea what it could be but a quick look at the cas server source indicates to me it could be something is not correct with your registered services? Is your service allowed for proxy? Is there maybe an error in the ant regexp? Are there any other messages in the cas server log around this entry? Please also refrain from cutting your logs to bits and pieces. If we can't reproduce errors on our side the only way to figure stuff out is to see full logs/traces of the problems in question and not by you selectively sharing single lines of info you feel relevant and describing the situation. Especially proxy mode is very tricky business and not something where guessing on our part really helpfull. Can you please show a full debug scenario of a single proxy test (apache access and error log, cas log, phpcas debug log). That might give us some more info to work with. |
|
Thanks a lot for the detailed response. So there is a difference in how your CAS server behaves and mine. Mine does not like the 302, and yours works fine. I am now going to look at CAS server configuration again. Meanwhile I will post all the logs as you mentioned. |
|
I apologize for the delay in posting the log files. First the phpCAS log |
|
Next the apache access log & error log Access Log Error Log |
|
I had to replace all certificate related info from |
|
I also forgot to reply to the following point by Joachim In this custom solution with the hard coded callback URL, I did not use phpCAS in the custom call back PHP script. I only used the pgt storage code from phpCAS. |
|
The phpCAS log is clean and works as expected. The cas server is simply not delivering the PGT/PGTiou in either the xml answer or in a callback. The apache access log does not register the callback from the cas server which can only mean the request does not even hit the apache server and must fail before (SSL layer, network, cas server etc.)
Maybe this might give you some pointers but i strongly suspect there is something wrong in your environment. I hope this helps a bit... |
|
Thanks again for your time and effort. I do have SSL debugging on for the tomcat server. There is no apache entry for the callback with PGT/PGTiou because, earlier the pgtUrl validation failed due to the 302 redirect. Initially I also thought that the culprit is SSL and the environment. But with the slight modification to the phpCAS example code or with the hard coded pgtUrl to prevent the 302 redirect, everything works fine. I will close this issue for now, and instead ask CAS server community why the CAS server hates the 302 response in my case. I would like to thank the phpCAS community for being very supportive, and I hope to give back with our development efforts. |
|
Yes, i think switching to the cas-user list might help. Maybe a greater audience is able to shed some light on the situation. |
|
ravids I am also using the same code and not able to get the PGT after PGTiou is transmitted, I have made pgtCallback change in the code and in php logs I can see the PGTiou, but code doesn't works further. I am working on the example example_pgt_storage_db.php. what further code changes you have done to make it work. 8685 .=> phpCAS::forceAuthentication() [example_pgt_storage_db.php:50] |
|
I am new to CAS I fought the same error for hours - at the end it turned out that at some point I have commented in deployerConfigContext.xml. After I have uncommented it, everything began working and PGT Iou is now transmitted to the configured URL. |
|
Has this already been resolved? I'm looking at the same issue. Is there a way to work around this without having to mess up the code? |
We tried to use the following method in CAS-1.2.2 as well in the commit number in the latest github code (commit number : SHA: ec3e935)
In this case, we had the above code in
client.example.com/proxy.phpand the CAS server iscas.example.com. By default phpCAS constructsclient.example.com/proxy.phpas the pgtUrl. The process failed when the CAS server tried to validate the pgtUrl.We finally got it working by giving a different pgtUrl,
client.example.com/proxycallback.php, and using thephpCAS::setFixedCallbackURLmethod.We also debugged why phpCAS default behavior does not work. Following is the apache log extract from the server that is serving
client.example.com, with the working solution using a different pgtUrl.The first call is where my browser tries to access the
proxy.php. It redirects me to the CAS server, where I provide my login credentials. Then CAS server tries to validate the pgtUrl. This is where the bug is. If CAS server calls backproxy.phpas in the default behavior of phpCAS, phpCAS would redirect back to the CAS server to login. why? because phpCASisAuthenticated()method return false. Since phpCAS has not received any service ticket back from the CAS serverisAuthenticated()returning false is justifiable. As I see there are two solutionsUse a different fixed pgtUrl (proxycallback.php) as we did. The script at this URL retrieved the
pgtIdandpgtIouand saved to the pgt storage. Later when CAS calls the calling url (proxy.php) with thepgtIou, thepgtIdis present in the pgt storage for the next steps.Modify phpCAS to return a 200 response, bypassing every other code when the CAS server simply calls it to validate the pgtUrl.
May be there is a configuration we are missing. But we have phpCAS working using both the above two solutions. Please let us know if it is just a missing configuration or what we are reporting is a known issue.
The text was updated successfully, but these errors were encountered: