[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Re: opendap restricted access]



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