Thomas LOUBRIEU wrote:
Hi John,
I am not sure of the exact content of the CAS server but I think the
redirect order is sent through a specific http error code (302). You can
do "wget -S 'http://..."; in order to see what happens.
I think the client which does not manage HTML form will have to parse
the needed information (a ticket value I think) in it and send a https
request containing the "name" and "password" parameter. That is what we
planned for our opendap to netcdf client.
The problem then is that you will only interoperate with your particular
client, but not with other opendap clients.
I have looked at your specifications for thredds restriction. I agree
with you when authentification if made at the Tomcat level.
But in our case, the authentification is made at the CAS level (because
in our project it has to be centralized so that the user logs in only
once and is known everywhere with that login). Then the authorization
process should stay at the application level (thredds here) and there is
not point to configure it in a shared file at the tomcat level.
One of the goals is to try to specify which datasets are resticted right in the catalogs. Then this can apply to not just the opendap service, but other services like wcs, etc.
Anyway the "role" concept at tomcat level or at the application level is
interesting but in our case the number of users is very short that is
why I didn't plan to use it.
I will try to be at the developper meeting in Boulder. I hope we will be
able to discuss it further then.
That would be very nice.
Thomas
John Caron a écrit :
Hi Thomas:
Thank you very much! I was able to get it working finally (I had the
certificate installed in the wrong JVM!)
In looking at how CAS works with TDS, it appears that a user will get
sent to the CAS login page. However, it may be that the user is not in
a browser, but in another application or even a web service that does
not process HTML FORMs. I am wondering if you know if its possible to
configure CAS to do a HTTP 401 challenge instead of a login page?
I am concerned that some OPeNDAP clients may not be able to work with
a TDS server protected by CAS. I am trying to make recomendations to
the OPeNDAP conference next month on how to create interoperable
OPeNDAP clients and servers that implement security. Do you have plans
to attend that conference? Any thoughts that you have about these
issues would be helpful to me.
John
Thomas LOUBRIEU wrote:
Hi John,
Perhaps you can test your CAS-ification with our CAS authentification
server (https://auth.ifremer.fr). To do so, you'll have to configure
your TDS web.xml file as follow :
<filter>
<filter-name>CAS Filter</filter-name>
<filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
<param-value>https://auth.ifremer.fr/login</param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https://auth.ifremer.fr/proxyValidate</param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
<param-value>your application server dns:your port</param-value>
</init-param>
</filter>
You can download the convenient cas.keystore (the public certificate
for our server) at :
http://secure.globalsign.net/cacert/sureserverEDU.crt
And then use the jvm options :
JAVA_OPTS="-Xms2048m -Xmx2048m -XX:MaxPermSize=256m
-Djavax.net.ssl.trustStore=sureserverEDU.cert"
to launch the tomcat server.
I have created a login for you, it is :
login : jc1eed0
passwd : aze321
I hope this will help you,
Thomas
John Caron a écrit :
Thomas LOUBRIEU wrote:
Hi Jon,
up to now it is what we are using "as this". Our project, in the
coming weeks, is to extend the 'filter' functions (I don't know yet
which they are) so that we can't check the CAS-authentification (as
it now is) AND if the user login if authorized to access the
current URL according to a configuration file as follow (in XML or
java properties) :
URL_pattern1
login2
login3
login4
URL pattern2
login1
login5
...
where URL_patternX are base URL under which the access is restricted
and loginY are the authorized CAS logins.
otherwise access is free.
It a very simple authorization configuration but we have short
delays to built a demonstration system for an European operational
project.
Hi Thomas, im having trouble getting CAS to work, i keep getting the
following errors. I think Ive installed a certificate correctly in
both tomcat keystore and in JRE cacert. So you have any advice?
edu.yale.its.tp.cas.client.CASAuthenticationException: Unable to
validate ProxyTicketValidator
[[edu.yale.its.tp.cas.client.ProxyTicketValidator proxyList=[null]
[edu.yale.its.tp.cas.client.ServiceTicketValidator
casValidateUrl=[https://localhost:8443/cas/proxyValidate]
ticket=[ST-2-rduetdijO1DSxhaUv6EPioZdgItQERr7ufZ-20]
service=[http%3A%2F%2Flocalhost%3A8080%2Fthredds%2FdodsC%2FtestCAS%2FtestData.nc.html]
renew=false]]]
at
edu.yale.its.tp.cas.client.CASReceipt.getReceipt(CASReceipt.java:52)
at
edu.yale.its.tp.cas.client.filter.CASFilter.getAuthenticatedUser(CASFilter.java:455)
at
edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:378)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building
failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
at
com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1518)
at
com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
at
com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:848)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:106)
at
com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
at
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:818)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1057)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1041)
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:170)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:938)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
at edu.yale.its.tp.cas.util.SecureURL.retrieve(SecureURL.java:84)
at
edu.yale.its.tp.cas.client.ServiceTicketValidator.validate(ServiceTicketValidator.java:212)
at
edu.yale.its.tp.cas.client.CASReceipt.getReceipt(CASReceipt.java:50)
... 17 more
Caused by: sun.security.validator.ValidatorException: PKIX path
building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable
to find valid certification path to requested target
at
sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:221)
at
sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:145)
at sun.security.validator.Validator.validate(Validator.java:203)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:172)
at
com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:841)
... 31 more
Caused by:
sun.security.provider.certpath.SunCertPathBuilderException: unable
to find valid certification path to requested target
at
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:236)
at
java.security.cert.CertPathBuilder.build(CertPathBuilder.java:194)
at
sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:216)
... 36 more
