[cas-dev][cas-user] Having trouble with the proxy cas walkthrough tutorial

[Auninda Rumy Saleque]

Hello,
i am apologizing beforehand for a lengthy message. I am having trouble generating proxy tickets following this tutorial:

https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough.

Heres my scenario:

my cas server link is this:
https://192.168.1.242:8443/cas

link of my web service using cas is:
https://192.168.2.95/cgi-bin/koha/opac-user.pl

while trying out the cas proxy tutorial, i executed the following link for getting back a validated pgt:

https://192.168.1.242:8443/cas/serviceValidate?ticket=ST-1-D5AfJ2wXKGW7boxQqdcD-cas&service=https://192.168.2.95/cgi-bin/koha/opac-user.pl&pgtUrl=https://192.168.1.242:8443/test.html

and the return xml gives me a successful authentication with only the user name but i could not find any PGT with it.

i traced back the cas.log file and i found the following error(part of the log is given in the following and the complete log is attached):

2011-12-20 12:33:03,817 ERROR [org.jasig.cas.util.HttpClient] - java.security.cert.CertificateException: No subject alternative names
present
javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No subject alternative names
present
       at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
       at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1639)
       at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:215)
       at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:209)
       at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1033)
       at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:146)
       at sun.security.ssl.Handshaker.processLoop(Handshaker.java:546)
       at sun.security.ssl.Handshaker.process_record(Handshaker.java:482)
       at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:904)
       at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1140)
       at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1167)
       at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1151)
       at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423)
       at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
       at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
       at org.jasig.cas.util.HttpClient.isValidEndPoint_aroundBody4(HttpClient.java:109)
       at org.jasig.cas.util.HttpClient.isValidEndPoint_aroundBody5$advice(HttpClient.java:44)
       at org.jasig.cas.util.HttpClient.isValidEndPoint(HttpClient.java:1)
----
apart from the above error everything else is working fine.

now my queries are:
-> are there any extra configurations i need to make for receiving back the PGTs?
- > the callback url (pgtUrl=https://192.168.1.242:8443/test.html) i  am using, is there anything wrong with it or does it have to be something specific?

i did add my cas server certificate to the cas server's jvm, so that the call back url does not fail authenticating but still i am getting  the error.

I am using cas server 3.4.11 and i am testing these setups using local ip. Any help will be greatly appreciated.

Thank you.

--
Auninda Rumy Saleque
Asst. System Programmer
Ayesha Abed Library
BRAC University
Dhaka, Bangladesh

-- 
You are currently subscribed to cas-...@lists.jasig.org as: jasig-cas-user...@googlegroups.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Andrew Petro]

Auninda,

I don't think this is going to work.

> pgtUrl=https://192.168.1.242:8443/test.html

You'll need to identify 192.168.1.242 by a hostname that its SSL certificate authenticates, so that when CAS attempts to itself do an HTTPS GET request to that URL it is able to successfully validate the SSL certificate. Currently CAS isn't coping with the SSL handshake with that callback URL, such that the callback is failing. Since CAS failed to vend a pgtIou, pgtId pair to that URL, it doesn't include the PGTIOU in the /cas/serviceValidate response.

You can either use a hostname and an SSL cert that authenticates that hostname, or you can disable the HTTPS requirement and exercise the whole thing over HTTP (for demo purposes only, since not using HTTPS is terribly insecure, of course).

Kind regards,

Andrew

> You are currently subscribed to cas-...@lists.jasig.org as: ape...@unicon.net

> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

> <cas.log>

[Auninda Rumy Saleque]

Thankx for the replies guys. yes, i do know the error is being caused for some certificate validation failure but i am not sure how to avoid it. well http is not an option for me coz i need the single sign on to work properly. at the moment cas is working fine with drupal and koha(a web based library management system). only trouble is, if someone logs inside drupal  using cas, he/she needs to click the login button again inside koha for logging in there, though no user/pass is required in that stage. so to avoid such situation, i am trying to work out the proxy granting ticket option and i am stuck with this right now. i did try making a certificate based on my hostname and adding it to the truststore, but in that case, the log error message tells me that there is no valid certificate found for the path. still i will try it out again tomorrow. i am not sure if i am getting these errors cause of my local ip/host names though.

Regards,
Auninda

You are currently subscribed to cas-...@lists.jasig.org as: nightsta...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

--
Auninda Rumy Saleque
Asst. System Programmer
Ayesha Abed Library
BRAC University
Dhaka, Bangladesh

-- 

[Marvin Addison]

> I don't think this is going to work.
>
>> pgtUrl=https://192.168.1.242:8443/test.html
>
> You'll need to identify 192.168.1.242 by a hostname that its SSL certificate authenticates, so that when CAS attempts to itself do an HTTPS GET request to that URL it is able to successfully validate the SSL certificate.

We may want to consider adding HostnameVerifier hooks to the proxy
callback. While this particular use case isn't something we'd be
interested in supporting, I can imagine that there could be valid
needs for more flexible hostname verification techniques on SSL
connections. For example, wildcard certificates that apply to
subdomains is one that comes to mind. (JSSE by default only supports
wildcards in the same domain scope.)

M

[Auninda Rumy Saleque]

Thanks a lot Andrew. this cleared a lot of troublesome questions i had. yes, i already solved my use case scenario without any problem but the problem is, i cannot completely restrict koha to anonymous users and i also needed to auto login when someone logs using drupal without the secondary check from cas. in any case, now i am assured that it is not possible the way i was trying to solve the problem. 

Regards,
Auninda

On Tue, Dec 20, 2011 at 7:47 PM, Andrew Petro <ape...@unicon.net> wrote:

Auninda,

This is a discussion of using the CAS software, rather than developing the CAS software.  It would therefore be more appropriate to conduct this conversation on cas-user@, rather than on cas-dev@.


Your use case does not require proxy tickets.

Proxy tickets are applicable when an application needs to itself, on behalf of the end user, authenticate to a backing service.  If Drupal needed to itself authenticate to Koha to go get some XML representing my library subscriber account, using this to inform a UI presented by Drupal, that would be a use case for Drupal to use Proxy CAS to authenticate to Koha.

Your use case requires only service tickets and applications appropriately configured to require/accept CAS service tickets.

If users are going to Koha from Drupal, then in Drupal try making your hyperlinks to Koha go through CAS login, as in

https://cas.example.com/login?service=https://koha.example.com/somepath

When users click these links, they're go to CAS, which will recognize their CAS SSO session, and send them on to Koha with a valid service ticket on the URL.  So long as that Koha URL is configured to accept that CAS service ticket, ta da! Users experience single sign on in navigating from Drupal to Koha.

If users are going to Koha directly, then try making the URL they access require CAS login.  If they already have a CAS SSO session, CAS will redirect them back immediately with a valid ticket.  If not, they'll have to log in.

If having to log in is unacceptable (you'd like to instead display a no-authentication-required guest page in the case where they're not yet logged in), then try the CAS gateway feature.

Your use case does not require proxy tickets.

Kind regards,

Andrew



On Dec 20, 2011, at 8:36 AM, Auninda Rumy Saleque wrote:

> Thankx for the replies guys. yes, i do know the error is being caused for some certificate validation failure but i am not sure how to avoid it. well http is not an option for me coz i need the single sign on to work properly. at the moment cas is working fine with drupal and koha(a web based library management system). only trouble is, if someone logs inside drupal  using cas, he/she needs to click the login button again inside koha for logging in there, though no user/pass is required in that stage. so to avoid such situation, i am trying to work out the proxy granting ticket option and i am stuck with this right now. i did try making a certificate based on my hostname and adding it to the truststore, but in that case, the log error message tells me that there is no valid certificate found for the path. still i will try it out again tomorrow. i am not sure if i am getting these errors cause of my local ip/host names though.
>
> Regards,
> Auninda
>

--
You are currently subscribed to cas...@lists.jasig.org as: nightsta...@gmail.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Scott Battaglia]

Can we pull out what we did for the client into its on lib and use it in both?

On Tue, Dec 20, 2011 at 9:18 AM, Marvin Addison <marvin....@gmail.com> wrote:

> I don't think this is going to work.
>
>> pgtUrl=https://192.168.1.242:8443/test.html
>
> You'll need to identify 192.168.1.242 by a hostname that its SSL certificate authenticates, so that when CAS attempts to itself do an HTTPS GET request to that URL it is able to successfully validate the SSL certificate.

We may want to consider adding HostnameVerifier hooks to the proxy
callback.  While this particular use case isn't something we'd be
interested in supporting, I can imagine that there could be valid
needs for more flexible hostname verification techniques on SSL
connections.  For example, wildcard certificates that apply to
subdomains is one that comes to mind.  (JSSE by default only supports
wildcards in the same domain scope.)

M

--
You are currently subscribed to cas-...@lists.jasig.org as: scott.b...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user