Have two server instances, one for the main website and one for the cas server (using the cas_server). All tables are seperate except for users, role, authmap which are shared between the two sites (so we can manage everything, including accounts, from the main site).
Clicking CAS login takes to cas server, login is successful (get ticket, etc) but return to main site gives CAS authentication failed. Returning to cas server shows we are logged in.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | cas_server_956108.patch | 736 bytes | metzlerd |
| #9 | casserver.txt | 7.08 KB | testbed |
Comments
Comment #1
testbed commentedAdditional info from debug--when the main site (www) checks the ticket against the cas server (cas), get this:
https://cas:443/cas/proxyValidate?service=http%3A%2F%2Fwwwt%2Fctmlpi&tic...
The requested page could not be found
Comment #3
metzlerd commentedDo you have the "initialize cas as proxy" box checked on your cas client configuration. It seems like you shouldn't for this configuration. I don't have proxy support built into the cas server yet.
Comment #4
testbed commentedNo--Initialize CAS as proxy is not set.
Comment #5
testbed commentedFurther info--we use the same CAS client configuration for a JASIG server and that works fine. Changing the name to the
Drupal CAS server results in that error.
Comment #6
metzlerd commentedReally? That's odd,since the CAS server should never redirect to proxyValidate unless that's set, or it should be going to validate , Not proxyValidate.
Did you end up modifying code or settings in the phpCAS library to force PGT storage/acquisition or are you using an unmodified base version? As I said. I haven't implemented yet the proxy granting ticket issuance/validation into the drupal cas server yet. It was meant to be a lite/minimal version of the cas protocol.
Finally, are you really using 6.x-1.x? Any reason to not upgrade to the current released rev to check this out?
Comment #7
testbed commentedNo--haven't hacked anything but the install script (varchar(255) from 256).
Yes, really using that release--I'll be happy to upgrade, though, to rule out any issue like that.
Comment #8
metzlerd commentedJust to be clear, I was asking about phpCAS library, not the drupal module. I'm just trying to figure out why proxyValidate would be called instead of validate.
Comment #9
testbed commentedI apologize--I did have proxy turned on when I pulled the debug info. I was trying different things and that was one.
I've set everything back so that it works fine with our jasig server but when I just change the hostname of the drupal cas server, it fails.
I've attached debugging output from that session.
Sorry for the confusion.
Comment #10
metzlerd commented/casserver:443/cas/proxyValidate
In your log file continues to suggest that for some reason that your cas Client is being initialized as a proxy. I've tried a couple of ways to get that to happen without "Initialize CAS as proxy" being set in the cas module, but I've been unable to do so.
Looking at the phpCAS library, it seems like there may be some bugs in phpCAS as you can see it's clearly indicating a PT proxy ticket when an ST proxy ticket has been passed. This patch might work around the bug. Remember to clear your caches on your cas server site, after you apply this patch.
Comment #11
bfroehle commentedOne issue here is the proper function to set the callback to -- is it 'cas_server_validate' or 'cas_server_service_validate'.
6.x-3.x had it set to 'cas_server_validate', 7.x-1.x had it set to 'cas_server_service_validate'. Reading through the phpCAS source code, it's clear that calls to proxyValidate expect the CAS server to return XML -- therefore the proper callback is 'cas_server_service_validate'.
I've added that menu item in 6.x-2.x, and fixed 6.x-3.x to use the proper callback function.
Comment #12
bfroehle commentedBy the way, the issue with proxyValidate being called (instead of serviceValidate) has to do with phpCAS -- it seems to always call proxyValidate, regardless of if there is a proxy there or not. This caused me some initial frustration when developing test routines for 7.x-1.x in #1011848: Add Testing Routines.