On Tue, 2005-01-18 at 15:40 +0100, [EMAIL PROTECTED] wrote: > 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.
LDAP is a good candidate for this. It is a standard and fairly well supported, so integrating third-party applications should be easier than with a custom solution. > > 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. Very good idea. > I guess I have to keep track of which user/role is allowed to do which > action on which > repository resource also? No. Leave this information in the same repository with the data if at all possible. The principal -> capability -> data mapping is very unique to an application, and it is unlikely you could meaningfully reuse it. As an example, why would a payroll system care that user X can write to /slide/files/meeting_minutes? And why would Slide care that user Y can sign user X's timecard? If all of your permissions utilize roles (a good practice), and if you can meaningfully extract business functions into roles, then you should have enough abstraction to make the central repository useful. As it is, my LDAP repository has a fair mix of generic role-type groups that are used by many systems, and specific "these four people" groups that are only used once. > > First of all, is this possible? Yes. > 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? If you can store your user and role information in a location Slide understands, that will make your life easier. If not, you'll need #1 for authentication to the app server and #2 to make Slide aware of role memberships. #3 has nothing to do with permissions in Slide, so you shouldn't need that. #4 is to provide you're own implementation of the Security interface. This can be very useful if, for instance, you have some complicated logic driving your role memberships that makes it much faster to calculate a user's memberships rather than a role's members. If you go this route you'll still need #1, and if you want WebDAV compliance you'll need #2 as well. -James > > Thanks in advance! > > David. > -------------------------------------------------- > Inventive Designers' Email Disclaimer: > http://www.inventivedesigners.com/email-disclaimer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
