Hi, > I think it will be better if I summarize what I am trying to do: > -Thousands of users and roles/groups are already defined at ldap. > -There is an application using slide as backend, it accesses slide > using webdav. Users can't access slide directly. Users are > authenticated in this application, and we don't want to authenticate > them again for slide. > - We want to pass current user info from our application to slide, and > this user info must be used for acl mechanisms etc.
I'm faced with a similiar problem. We have different applications (servlets) which need authentication and authorisation. The Slide webdav repository is one of them. We don't want to duplicate authentication and authorisation information for all the users, we want a centralized user store which contains all needed information. What I want to do is to create a centralized store which contains usernames, passwords and roles. These should be used (among other things) to access the slide repository. I guess I have to keep track of which user/role is allowed to do which action on which repository resource also? First of all, is this possible? Second, what's the best way to do it? 1) Write my own JAAS login module: I've read the mails about the problems configuring a simple JAAS authentication login module since I had the same kind of problems... It can only be used when you want to replace authentication, but not authorisation, right? 2) Write my own security store, like the JNDIPrincipalStore. If this is the best choice, which interfaces are important? The are a lot of interfaces implemented, but the implementations of all the interface's methods are empty. 3) Write my own implementation of the storing system (with use of WCK). This seems overkill, since I only want to replace the authentication and authorisation. And since we're heavily making use of versioning, WCK is not the way to go, right? 4) Other? Thanks in advance! David. -------------------------------------------------- Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer
