Download & Extend

"Authentication failed" error

Project:CAS
Version:6.x-3.1
Component:CAS
Category:support request
Priority:normal
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

Hey,

I'm having some trouble setting up CAS login. I keep getting an "authentication failed" error. The problem is pretty hard to pinpoint, as I don't know the entire workflow and I don't have access to the server (except to log in) to play around.

One path is that it doesn't even work outside of Drupal:
I've tried the files as given here:
http://drupal.org/node/1390204#comment-5439092
and the result is that, in client.php (line 2606), it tries to load the redirect page in as XML. That obviously gives errors. I don't know why it tries to do that, though. Somehow, I doubt it even should do that. So if this is the right path for this problem, what should I look into in order to fix it?

Another path I got, is that it doesn't work from within Drupal.
This is the debug log:
http://pastebin.com/aqbu0cR6
(I did a search & replace for both the server's hostname and my client's name, to protect any data I might not be allowed to give away for some reason or others. Hostname is myCASServer, client is myCASClient)
The specific part of that that worries me, is this line:
https://myCASServer/cas/proxyValidate?service=http%3A%2F%2F127.0.0.1%2Fm...
So it authenticates, redirects to the client with the ticket, then redirects back to the server with as redirect path the client + ticket already in there? I don't know if I'm reading this right, or if it's normal.

Any help would be appreciated, as I'm quite stuck on it and don't know which path of the two to delve deeper into, nor where to start digging next.

Edit: Ok, if I just show that redirect HTML and manually click on the redirect URL, I get an XML containing valid login info. The thing is, though, that it's on the CAS server, not the client. So in other words, after logging in, I'm being sent back to the server, not the client. That's not supposed to happen! Maybe the first and the second paths to solve this problem are linked.

Comments

#1

Raf: The issue here is with either the CAS server, or somehow your configuration of the CAS client in how it refers to the CAS server.

Your debug log (http://pastebin.com/aqbu0cR6) is quite telling --- after you, the user, authenticates with the CAS server you are redirected back to your Drupal site with a ticket, e.g.:
PT `ST-976480-TbBzQDLRviUFPhW415yuedv5D908vtMnEOF3zV8YVU3G-wkGjxchnStjMueiTZpKjZG-EsS81adS3Bc9CB2NbpCGp0' is present [Client.php:1093]

The CAS client then validates this ticket with the CAS server to get your login name (and any other attributes the server cares to return):

7EA7 .|    |    |    |    <= 'https://myCASServer/cas/proxyValidate?service=http%3A%2F%2F127.0.0.1%2FmyCASClient%2Fcas%3Fdestination%3Dhome'

However the CAS server seems to be sending back an HTTP redirect instead:

7EA7 .|    |    |    |    => CAS_CurlRequest::_sendRequest() [AbstractRequest.php:191]
7EA7 .|    |    |    |    |    Response Body:
7EA7 .|    |    |    |    |    <HTML><HEAD>
7EA7 .|    |    |    |    |    <TITLE>Redirect</TITLE>
...

Instead of an actual response which would look something like:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>USERNAME</cas:user>
</cas:authenticationSuccess>
</cas:serviceResponse>

To debug, I'd ty to manually authenticate:

(1): Open your webbrowser and go to https://myCASserver/cas/login?service=http://localhost:9999/ You'll be asked to authenticate and will be redirected to
http://localhost:9999/?ticket=...STUFF... Copy the ticket to the clipboard, we'll need it in a second.
(2): Now go visit https://myCASserver/cas/proxyValidate?service=http://localhost:9999/&tic......
and see the response.

Lastly, my hunch is the following: The webserver wants you to use https://www.myCASserver/ but instead you are using https://myCASserver.

#2

Status:active» fixed

Since we haven't heard back, I will assume that you've managed to get your CAS client (and CAS server) properly configured.

#3

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.