We have requirements in some research projects to be able to use 'Grid' certificates for authentication and to use various external policy based authorization schemes (e.g. only people who are employees, are current in their ethics training, and are part of the project team can see the data related to computations related to chemistry in a specific engine design).
We've been thinking about how to modify Slide /create APIs in Slide that would provide enough flexibility to configure whether certificate/external authorization mechanism or username/password/ACL controls are used. Our implementation is probably a few months away and I don't know if it will be light-weight enough to be of general use, but if people are redesigning the user/security mechanisms, I'd be happy to compare notes and inject some suggestions (i.e. hide the actual data type of the user ID in the API (currently a string, but for us a certificate) behind an interface such as the JAAS Principal). Jim ----- Original Message ----- From: "David Keyes" <[EMAIL PROTECTED]> To: "'Slide Developers Mailing List'" <[EMAIL PROTECTED]> Sent: Thursday, October 10, 2002 10:32 AM Subject: RE: AW: While List is Alive: Roles !! > I think that it is important that whatever approach is taken should not > PRECLUDE the integration of slide with another source for user information. > It is possible (and in fact is true in our case) that the user information > will need to be pulled from a completely external system (e.g., LDAP or some > other proprietary source). > > Using the slide file system to store the information would allow us to write > our own store that acts as a facade to whatever backend datasource we wanted > to use... > > Dave Keyes > > > > > Proposal One: Use the Slide File System > > This is basically what I proposed last time: Move the roles onto the file > > system, store the groups in their own collection, and user link-nodes to > > create the associations. > > To me this has the advantage of consistency. All the user related > > information is stored in a logical way on the file-system. Additionally, > it > > may be possible to manipulate the groups and roles simply using the webdav > > protocol, also practical. On the other hand, storing this security > > information in the same place as the content can be a security hazard too. > > Perhaps it would be better to prevent all webdav access to the groups... > > Another big advantage of this proposal is that all the storage mechanisms > > are already in place, and a core part of slide, much tested. The users are > > stored with the same flexibility as the content, and the slide > administrator > > does not need to worry about aditional setup. An different way of storing > > the users would require its own code, introduce new bugs and presumably > add > > to slide's configuration. > > > Proposal Two: Use a new storage system > > Since the users, groups, roles and actions have little to do with the > > content, there is no pressing reason (other than the practical ones listed > > above) to store this information on the slide file-system. In fact it may > be > > more secure to put it elsewhere. A specific proposal might be to create a > > kind of 'userdatabase' object and store all users, groups and roles in > this. > > The entire object could just be serialized to disk (or the slide fs), and > > loaded again in one piece. The problem with this approach occurs when > there > > are tens of thousands of users, and the userdatabase object gets too > large. > > However, this might be an acceptable trade-off, since I would assume that > > installations with more than 10000 webdav users are rare. > > > It is worth thinking about... My instincts tell me that the slide > > file-system is a good way to go. It is all there for us, and gets tested > by > > the test-suite all the time. And it is easy for people to understand and > > use. > > > In either case, I would propose an API for reading users and user > > properties, checking role and group membership, and adding and removing > > users, roles and groups. I don't think it is a good idea to manipulate the > > node structure directly when creating a new user, and if such an API were > > used, it would allow slide to change the way the users are stored without > > too much trouble. The org.apache.catalina.UserDatabase is a good starting > > point, and I already have some parts implemented. > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
