Hi Jean > I'm using Slide 2.0 within Tomcat 5.0.19, JDK 1.4.2_03. I > would like to use a custom (SSO) authentication mechanism to > control access to the Slide server. Actually, I want to > totally get rid of the simple HTTP auth mechanism and use an > external tool - for information, the Central Authentication > Service (CAS - https://www.yale.edu/tp/cas). > > Is there any roadmap to follow / featured API to help with this task ?
I integrated CAS support into the Acegi Security System (http://acegisecurity.sourceforge.net), which I've also integrated into Slide, so hopefully I can offer some pointers. Slide has a utility class, org.apache.slide.webdav.util.WebdavUtils, which has a method, getSlideToken(). This method obtains the principal from the web container using the normal request.getUserPrincipal() method, or, failing that, from a session attribute named "org.apache.slide.webdav.method.principal". This is your magic bridge between third party authentication systems and Slide. :-) For this to work, you DON'T authenticate using standard web container services. So disable web.xml <security-constraint>s etc. You'll need a filter that detects requests to the WebdavServlet from a user that hasn't got a HttpSession attribute with the above name. When the unauthenticated user is detected, you'll redirect them to the CAS server. After login, CAS will post back to another one of your filters which validates the CAS service ticket and sets up a valid Principal implementation in the HttpSession attribute named above. From that point forward, the WebdavUtils class will be able to extract the Principal. Slide only uses Principal.getName(), and then relies on its own authorization store to determine the ACLs that apply. The most work is in the filters/servlets that tie in the CAS login. Also, of course, you'll have a problem in that non-web-browser clients cannot obtain the CAS ticket as they use BASIC authentication which doesn't understand HTTP redirects (which is central to how CAS works). There are some ways you can approach it, though: - Forget about non-browser clients. Ouch... - Write a filter that detects the BASIC authentication request, then posts it through to CAS on behalf of the BASIC authentication client, and then processes the resulting opaque service ticket as described above. - Have dual authentication methods. For web browsers use native CAS. For BASIC authentication clients, directly validate against the backend database from your BASIC authentication processing filter. This is the cleanest model. Acegi Security might be worth a look for some code samples. It does BASIC authentication, CAS integration etc. You could also use it natively to perform most (if not all) of the above. Hope this helps. Ben --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
