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>
