We keep returning a few key concepts: Most of Slide (or any app) only needs to have a handle to a user without really having to know what is inside.
Somewhere (in Tomcat or Slide) the user handle must be dereferenced and authenticated once. In the case of certificates, the easiest way to authenticate is to use SSL/TSL which means that information to authenticate the user (their private key or something signed using the private key) is not easily available at the application level, so Slide or external authorization subsytems can't easily reauthenticate the user. Authorization decisions, whether they are ACL based or policy based, can be requested using a (user, action, resource) triple and getting back a yes/no answer. As with authentication, only the subsytem implementing that API has to know anything about the structure of user. (A really general API might need to pass additional information or have a callback - e.g. to decide whether to allow a put based on a space quota) As I said before, I don't know how much flexibility really needs to/can get get pushed into Slide before complexity goes up and efficiency goes down, but I think it would be easier for this flexibility to be added by other projects if general APIs rather than stores interfaces are considered primary in the design --> basically just arguing for things like passing a general user object to authentication/ authorization methods and letting any dereference to a node happen in the security subsystems.(Versus assuming user objects are always nodes and passing them around that way.) I don't think this would limit any plans to create different types of user stores as described by Richie, which might even be the preferred way for most implementations - same for ACL stores tied to external systems. But keeping the interfaces around and using pretty high level abstractions would make it possible for my project and others to switch to policy-based access etc. cleanly as well - a win-win. Thanks for the discussion! Jim ----- Original Message ----- From: "Unger Richard" <[EMAIL PROTECTED]> To: "'Slide Developers Mailing List'" <[EMAIL PROTECTED]>; "Jim Myers" <[EMAIL PROTECTED]> Sent: Friday, October 11, 2002 6:32 AM Subject: AW: AW: While List is Alive: Roles !! Hi! I'm glad to get so much feedback!! The user-stores seem to interest other people than myself... The problem of LDAP user database connections, or the use of other user repositories (NIS, Active Directory, Appletalk, Local Unix Users/PAM) in slide is indeed a very valid concern that I had not thought so much about in my previous emails. As you point out though, it should be of primary importance, and considered in the design from the beginning. My primary concern was adding 'proper' support for roles to slide, and cleaning up the storage. The LDAP, or external user database, considerations add a new level to the problem. The way in which slide stores its user information has to be designed more carefully, so that every piece of data could conceivably be loaded and stored to a different type of user database. In this scenario, it would be bad to store the role information in the structure nodes of the stores, since a special adaption layer would be necessary to intercept this information and read/write it to LDAP instead (or as well). In this light it would be much cleaner to write all user information to the slide store, and implement different stores for keeping the information in LDAP, on slide or on some other system. This seems a pretty clean way to implement the abstraction. At the front end, I think a clear definition of what information can and has to be stored to a user store would make it easier to implement the different user stores. A clean API for adding users, roles and groups to slide would also be a good idea (see org.apache.catalina.UserDatabase). One could also think about implementing the hook into the userdatabases 'in front' of the slide filesystem. Abstract the storage for users in the API for user access, so that this API connects to slide, LDAP or whichever user database is configured. Personally I prefer the abstraction via the stores than the front end API. This seems cleaner to me. The stores are already a well-defined abstraction, no need to create another. Has anyone written an LDAP userstore? Are there any requirements/parameters for users, groups or roles that LDAP needs but slide does not normally provide? Richie > -----Urspr�ngliche Nachricht----- > Von: BaTien Duong [mailto:[EMAIL PROTECTED]] > Gesendet: Donnerstag, 10. Oktober 2002 19:32 > An: Slide Developers Mailing List; Jim Myers > Betreff: Re: AW: While List is Alive: Roles !! > > > 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]> > -- 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]>
