This subject has significant interest to us. We use JAAS (with password and certificate) and adapter to achieve container-neutral authentication. We are looking at Slide for authorization services and content management. An abstract layer independent of data sources is the key. Keep the good works rolling :-)
----- Original Message ----- From: "Jim Myers" <[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 !! > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
