Is it possible to get a *list* of users and roles from JAAS? I think that's something that would be needed to be compatible with WebDAV ACL spec.
Mmm... I don't think it's possible. Maybe that's why it hasn't been suggested before ;-) But maybe it's possible to populate the store as people login. Also does the spec require the user/groups in an ACL to really exist? I know that user/roles are represented in WebDAV as URLs, but do they need to exist for an ACL to be valid or this is a requirenment of Slide implementation, at least during ACL creation. What happens in the current Slide when a user is deleted but there are still ACLs referring to it?
I don't think there's any security implication if a user/group referred in an ACL doesn't exist.
Carlos
-James
On Wed, 2005-01-19 at 00:34 +0900, Carlos Villegas wrote:
There seems to be the need for a JAAS store!
There is a Slide JAAS login module for use in Tomcat and it's also possible to configure an external JAAS module with tomcat and have Slide auto create users, though people seem to have problems with that and it doesn't take into account roles. However, my understanding is that there's no real store that takes user and role info from a JAAS login module, something similar to the LDAP stores but using JAAS instead of JNDI. With a JAAS store it will be possible to reuse the JAAS login modules already provided by the container like the ones in tomcat, jboss or weblogic which in turn extract user/role info form xml/property files, databases, ldap, etc.
Carlos
Robert r. Sanders wrote:
[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.
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
Somewhere between #3 and #4 : You might also want to take a look at: http://acegisecurity.sourceforge.net/ From what I've seen it looks pretty complete, and might offer some interesting features.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
