You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Andreas Probst <an...@gmx.net> on 2002/11/02 16:43:23 UTC
Re: AW: AW: While List is Alive: Roles !!
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" <ru...@camino.at>
> > To: "'Slide Developers Mailing List'"
> > <sl...@jakarta.apache.org>; "Jim
> > Myers" <ji...@verizon.net>
> > 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" <ji...@verizon.net>
> > > To: "Slide Developers Mailing List"
> > > <sl...@jakarta.apache.org> 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" <da...@flashline.com>
> > > > To: "'Slide Developers Mailing List'"
> > <sl...@jakarta.apache.org>
> > > > 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:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org> For additional
> commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org> For additional
> commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org> For additional
> commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>