Hi Jean > Thank you so much ! I had not expected such a complete, > accurate - and fast ! - answear :) > > If I may go further, I have a few more questions. > > I want to allow users to access Slide from a web frontend > (actually a customized Jetspeed portal), from a 'heavy' > (client side) Java client AND from some non-browser clients > (e.g OpenOffice.org). I had this solution in mind: > > - The heavy client would access Slide after having > authenticated itself to the CAS. In this case, Slide would > only ask the CAS to check the validity of the ticket; > - The web portal would use CAS as its core authentication > service, so there is no problem here; > - The non-browser clients would access the resource in Slide > through an URL provided by the portal. This URL would contain > a portal-generated session ID and Slide - or the request > dispatcher - would detect it and use it to authenticate the client. > > > This is summarized in the following architecture (hope it > will be readable - please view with fixed width font): > > > *--------* *---------* *-----* > | Java | | Browser | | OOo | > | Client | *---------* *-----* > *--------* ^ ^ > ^ ^ | | > | \ v | > | v *--------* S.Id | > | *-----*<--->| Portal |------>o > | | CAS | *--------* | > | *-----* ^ | > | ^ | | > v v v v > *-------------------------------------* > | S L I D E | > *-------------------------------------* > > > If I understand well, this approach is quite similar to your third > proposition. Please correct me if not :) > > Where should I go for more doc about filters ? I was going to have a > look at Tomcat's documentation and/or J2EE docs at > java.sun.com, but it > would be great if I had some precise pointers :) > > Again thanks a lot !
My first thought is that getting Open Office and your Swing client to talk to CAS to obtain a token that can subsequently be validated is probably a lot of work. I would suggest using BASIC authentication for your Swing client and Open Office, using the native WebDAV HTTP protocol to access your Slide instance. Accordingly, you won't have any special software or procedures on the client-side, and indeed no special software on the server side apart from something that can handle your BASIC authentication requests. Your server-side will need a filter that can process a BASIC authentication request. I'd encourage you to look at Acegi Security as it has production-quality implementations of what you need. In fact, you could even use Acegi Security in your environment as follows: - Use say the JDBC provider with Acegi Security. You can also write your own if you want to access LDAP, NT, etc repositories. - Have Acegi Security as the provider in CAS. This means CAS delegates to Acegi Security when it is authenticating users on the CAS server. It saves you from writing your own CAS password validator. Acegi Security in turn delegates to its JDBC provider. - Have your web site use Acegi Security to detect HTTP requests. If a request is directly to your Slide servlet, this indicates a WebDAV client such as Open Office or Swing. Accordingly, launch the BASIC authentication process. Acegi Security will delegate the authentication decision directly to its JDBC provider. If on the other hand the HTTP request is not for the Slide servlet, you know it's for your "portlet front end". In that case launch the CAS login. The resulting CAS service token will be passed back to Acegi Security, which will then be validated against the CAS server. - Have the HttpSession integration filter add the resulting Authentication token (subclass of Principal) to org.apache.slide.webdav.method.principal. That way your authentication outcome (be it via CAS or directly via BASIC authentication) will be available to the Slide servlet when required. Slide will subsequently use its own ACL list obtained from its store. This should work. I must confess I haven't tested it. In our current project I decided it was simplest to not use CAS at all for anything to do with WebDAV. If I needed both to run concurrently, I'd try to approach it like the above. HTH Ben --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
