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>
