Hi There! Yes, I have the basic version of the interface I am implementing against. It is not yet final...
For one thing, each function is missing a parameter, the SlideToken to check against for security. This I plan to add in a second iteration of coding. I'll enclose the basic API and the SlideUser.java class with this mail, but it should be more ready next week. Richie -----Urspr�ngliche Nachricht----- Von: Jim Myers [mailto:jimmyers@;verizon.net] Gesendet: Dienstag, 22. Oktober 2002 15:16 An: [EMAIL PROTECTED] Betreff: Re: AW: While List is Alive: Roles !! Richie, Do you have a draft of the SlideUserDatabase API at this point? Jim ----- Original Message ----- From: "Unger Richard" <[EMAIL PROTECTED]> To: "'Slide Developers Mailing List'" <[EMAIL PROTECTED]>; "Hilgers Michael" <[EMAIL PROTECTED]> Sent: Tuesday, October 22, 2002 8:01 AM Subject: 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> >
userAPI_firstversion.tgz
Description: Binary data
-- To unsubscribe, e-mail: <mailto:slide-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org>
