Hi Richie, I'm looking forward to it.
Andreas On 31 Oct 2002 at 14:15, Unger Richard wrote: > Hi Everyone! > > I am back from my little holiday in England, and ready to bother > you all with more messages about security and users in slide... > > I have my implementation nicely underway. I now wnat to attack > the problem of storing the users in slide using my > SlideStoreUserDatabase implementation of the SlideUserDatabase > (see older message at the end of this one if you do not know what > I am talking about). > > My specific proposal for doing this is the following: > > * Create a new interface 'RoleContainer'. A RoleContainer > contains a list of roles, and allows adding and removing roles > from the list. * Make ObjectNode implement this interface. > ObjectNodes always return only the 'nobody' role, and don't > permit adding new roles. * Extend SubjectNode to implement > RoleContainer properly, allowing adding and removing of roles, > and returning more than just the nobody role. * Drop the classes > in slideroles.basic.* (UserRoleImpl, etc...) > > Henceforth, nodes in the slidestructure would be one of LinkNode, > ActionNode, GroupNode (for the groups), SubjectNode (for users) > or ObjectNode (for all other nodes). Since the roles are stored > in the RoleContainer part of the respective node class, there is > no need to subclass SubjectNode to create new roles. By virtue of > ObjectNode's rolecontainer implementation all nodes in the system > have the nobody role by default. > > Other user properties (password, group membership, etc) are > stored in the NodeRevisionDescriptors. > > In my eyes this has several advantages: > * Roles become mutable at runtime (at least for Subject- and > GroupNodes) * The node structure is simplified/clarified. > ObjectNode can still be subclassed to create new types of nodes > with different meanings for slide, but slide does not have to > cope with nodes having arbitrary class-types because of some role > the node needs. At the moment, nodes will have one of five > different types: Action-, Link-, Group-, Subject- or ObjectNode. > * It's cleaner this way: The roles, really a 'user' or > administrator concern, are seperated from the node class types, > really a slide developer concern. > > > Concerns? Comments? Does anyone love or hate this? > > > > Richie > > > > > > > > > > -----Urspr�ngliche Nachricht----- > > Von: Unger Richard [mailto:runger@;camino.at] > > Gesendet: Dienstag, 22. Oktober 2002 14:01 > > An: 'Slide Developers Mailing List'; Hilgers Michael > > Betreff: AW: AW: While List is Alive: Roles !! > > > > > > Hi! > > > > Ok, after several rounds of email, and quite a bit of > > thinking, I think I > > have settled on the following. If everyone agrees I would like > > to revamp the users code as follows: > > > > * Create some new classes and interfaces: > > interface org.apache.slide.security.SlideUserDatabase > > This interface specifies the functionality of a > > SlideUserDatabase - > > the abstract representation > > of slide users, roles and groups. The > > SlideUserDatabase provides an > > API for retrieving and > > storing users, groups and roles. The API encapsulates > > and abstracts > > dealing with the users, it > > is similar to the structure, content and security > > helpers in this > > way. > > class org.apache.slide.security.SlideStoreUserDatabase > > This is a concrete implementation of > > SlideUserDatabase that stores > > the users, groups and roles > > in a slide namespace. Basically this will be the user > > storage as we > > had it so far, with the > > important difference that roles can be added at > > runtime. > > class org.apache.slide.security.SlideUser > > class org.apache.slide.security.SlideGroup > > class org.apache.slide.security.SlideRole > > These classes encapsulate the information about the > > respective > > entity they represent. They are > > provided by the SlideUserDatabase, and intended for > > short term use > > (eg: a user object is > > retrieved from the database, used for some > > operations, and then > > discarded. The next time it is > > needed it is loaded again from the database, it is > > not saved, for > > example, in the session.) > > Users, Roles and groups can be changed or created by > > retrieving a > > user object changing it and > > requesting the SlideUserDatabase to save it. > > > > The idea behind this approach should be obvious: someone > > could, for > > example, write an > > LDAPSlideUserDatabase class, for LDAP authentication. > > After reading the > > discussion on this list, > > it seems the consensus is that the slide stores are not > > flexible enough > > to accomodate all user > > systems, hence an API for dealing with the users. At the > > same time, this > > approach still allows > > abstracting the user system using the stores by useing the > > SlideStoreUserDatabase class and a > > specially written store. > > > > At the same time having a clean API for working with the > > users (setting > > passwords, adding roles, > > etc) should be an improvement. > > > > * Integrate the new system into slide > > * The NamespaceAccessToken should be extended with a > > getSlideUserDatabase() method, which returns > > the SlideUserDatabase for the namespace. This is > > analogous to the > > getContentHelper() method. > > * The xml configuration for a namespace will be extended > > with a section > > that identifies the > > SlideUserDatabase to use with the namespace. By default > > this will be > > org.apache.slide.security.SlideStoreUserDatabase > > * The namespace initialization will be modified to read > > the userdatabase > > configuration from the xml > > and initialize the userdatabase. > > * The slide code will be audited for user related calls, > > and they will > > be migrated to use > > the SlideUserDatabase. > > > > * Add support for this to the wrappers. > > * Update the wrappers.catalina.SlideRealm to use a > > SlideUserDatabase > > * Create a wrappers.catalina.SlideUserDatabaseWrapper class > > which > > implements the > > org.apache.catalina.UserDatabase interface so that the > > Tomcat 4.1 > > authentication mechanisms can > > be used. > > > > That's the main idea, below are some more details for the > > really interested. What I would like to know is whether there > > are any major objections or problems that you can see with this > > approach that would prevent its acceptance into slide? Let me > > know. > > > > I will be away for about 5 days starting tomorrow, but I have > > already started implementation, and should have something > > useable by the end of next week. > > > > More Details: > > > > * General Notes > > - While the SlideUserDatabase API largely abstracts users, I > > think > > keeping the notion that the URI > > /<usersPath>/<username> refers to a user is useful. > > > > * Details on the SlideStoreUserDatabase: > > - In envision the default slide conf to be something like > > this: > > <userdatabase > > className="org.apache.slide.security.SlideStoreUserDatabase" > > usersPath="/users" > > groupsPath="/groups" rolesPath="/roles" /> > > - User, group and role names are alphanumeric, case > > sensitve and begin > > with a letter. > > - The usersDir can contain only users, users can only live > > in the > > usersDir. Same for roles and > > groups and their respective directories. > > - The roles 'root' (=superuser), 'nobody' (=anyone, > > authenticated or > > unauthenticated), > > 'user' (=any authenticated user) and self (=the current > > authenticated > > user) are always > > available by default. > > > > Some Questions I still have on all this: > > > > - Should the roles be stored within the ObjectNode of the > > user or group, > > or should there be a > > system of links within the rolesDir? > > - Should the group membership be stored as links as it has > > been, or > > should group membership > > be stored in the user or group ObjectNodes? > > - Should groups be allowed to log in? Should they have a > > password? - Should user and group properties be stored as > > NodeRevisionProperties, > > or perhaps within the > > ObjectNode of the user. > > If no one has any other input, I would propose storing the > > group and role > > membership information, > > as well as the user's properties, in the user's > > ObjectNode, rather than > > as links or > > NodeRevisionProperties. > > I would store group membership information in both the > > users and the > > groups. While this requires > > writing both the user and the group when membership > > changes, and could > > lead to inconsistencies, > > it allows fast answers to all type of questions. (Eg: I > > don't need to > > enumerate all users or groups > > to get a list of group members or group memberships). > > The role membership information would be stored in the user > > only. > > > > One question that remains for me is the permissions > > required to change > > the userdatabase. The way I > > see it by setting the write permissions on the groups it can > > be > > controlled who can add to a given > > group. For roles I plan to check that the user has write > > permission for > > the role before it can > > be assigned, even though the role does not have to be > > written to. > > Obviously write access is > > required for the user to be modified in order to modify > > him. A different > > SlideUserDatabase (eg > > LDAPSlideUserDatabase) could not use the ACLs to control > > who can set > > groups and roles. It would be > > up to the individual database implementation to check that > > the current > > user has the right to do what > > he is doing... > > > > I think that if this is all implemented as described > > above, the user and > > group stuff should > > be dropped from the data section of the namespace > > initialization, since > > the users and groups are not > > necessarily stored in the namespace. Instead the xml to > > create users > > could be put within the > > tag that specifies the slideuserdatabase for the namespace. > > > > Ok, that's all for now. Stop me if anything here seems wrong or > > dangerous... > > > > Thanks Everyone! > > > > Richie > > > > > > > > > > > > > > -----Urspr�ngliche Nachricht----- > > Von: Jim Myers [mailto:jimmyers@;verizon.net] > > Gesendet: Freitag, 11. Oktober 2002 16:38 > > An: Slide Developers Mailing List > > Betreff: Re: AW: While List is Alive: Roles !! > > > > > > 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:batien.duong@;dbgroups.com] > > > 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:slide-dev-unsubscribe@;jakarta.apache.org> > > > > > For additional commands, e-mail: > > > > <mailto:slide-dev-help@;jakarta.apache.org> > > > > > > > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > <mailto:slide-dev-unsubscribe@;jakarta.apache.org> > > > > For additional commands, e-mail: > > > <mailto:slide-dev-help@;jakarta.apache.org> > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:slide-dev-unsubscribe@;jakarta.apache.org> > > > For additional commands, e-mail: > > > <mailto:slide-dev-help@;jakarta.apache.org> > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:slide-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: > <mailto:slide-dev-help@;jakarta.apache.org> > > > > -- > To unsubscribe, e-mail: > <mailto:slide-dev-unsubscribe@;jakarta.apache.org> For additional > commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org> > > -- > To unsubscribe, e-mail: > <mailto:slide-dev-unsubscribe@;jakarta.apache.org> For additional > commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org> > > -- > To unsubscribe, e-mail: > <mailto:slide-dev-unsubscribe@;jakarta.apache.org> For additional > commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org> > -- To unsubscribe, e-mail: <mailto:slide-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org>
