Hi!
>From the beginning I hvae had a problem witht he slide user concept, and I'll
try to explan why. If people generally don't agree, I will drop the issue...
I've inlined my explanation:
Quoting Oliver Zeigermann <[EMAIL PROTECTED]>:
> Richard Unger wrote:
> > A filter is a powerful way to do the authentication, but I think the basic
>
> > problem is more where the users are stored (ie who's in charge?):
> >
> > a) Slide stores the users on the slide file system (a solution I personally
>
> > find horribly ugly)
>
> Why that?
>
Well, I just find it really inelegant to have the users lying round on the file
system, available to manipulation like the content being stored... I agree this
is a subjective view, and storing the users on slide (assuming it works well) is
theoretically equivalent to a database, or a flat file for that matter.
As for specific problems with going this way, I think there are a few:
* Having the users on the system exposed to webdav access adds security problems
we could pass on to, for example, a database.
* It also adds unnecessary design considerations -> What does it mean to lock or
version a user 'resource' using webdav methods?
* Answering these design considerations adds messyness to the code -> we need
'usernodes', which are exemt from versioning or something like that, its been a
while since I looked into that part...
> > -> Either each containser needs a wrapper to access the users
> > -> Or container based authentication is dropped, and security has to be
> > handled by slide
> >
> > b) Slide gets the users from the container
> > -> How to store additional properties (such as group membership) not
> directly
> > supported by the container but required by webdav?
> >
> >
> > If you examine what's going on I think there is a basic mismatch between
> the
> > servlet security model (which has users and roles) and webdav's (which also
>
> > seems to have groups). It woudl seem therefore, if we want to be true to
> the
> > spec and support groups (and any additional properties webdav users may
> have)
> > we should just drop the idea of container based authentication until the
> > security concepts better match and do the authentication ourselves. A
> filter
> > is a good way to do this I think.
>
> I thought groups match roles, so there is no mismatch, is there?
>
>From the Webdav ACL goals document, annoyingly I can't seem to access the spec
itself at the moment:
snip>>>>>>>>>>>>
8. Areas Out of Scope
8.1. Groups
Modeling groups is out of scope. There is currently no concept
of groups to deal with in HTTP [2] or DAV. The protocol draft
MAY support specifying (naming) groups which already exist on a
given underlying system. It is recommended that the protocol
draft avoid issues such as the enumeration of group members or
administration of groups.
<<<<<<<<<<<<<<unsnip
I don't know how current this is, I could look into it more deeply, but AFAIK
the situation for servlet 2.3 unchanged.
It is theoretically true that all permission setups involving users, groups and
roles could be modelled using only users and roles. In practice, groups are
useful, since roles are typically defined by architects and programmers, often
fixed in the application code. Roles embody the concept of a set of permissions
without a principal or subject. Roles therefore aren't convenient for gathering
users, adding the concept of groups gives the admins a level of abstraction to
work with. On the other hand, servlet doesn't seem to have groups...
Slide has groups, users and roles (does the ACL draft include groups now, or
not? I wish I could access it. Does someone have a copy??). Saying groups can be
treated as roles begs the question why have them in the first place...
> > There is one thing to consider though: Large computing environments
> typically
> > will already have established user structures stored in LDAP or databases.
>
> > Portal servers and reverse proxies use authentication tokens to pass logins
>
> > around clusters of servers, and this requires container based
> authentication.
> > Can we drop compatibility with all that?
>
> Do not see why we should. We could use web container managed
> authentication when we access Slide over the webdav tier and direct
> authentication when accessing Slide directly over its API, right?
>
Well, this is where the situation gets tricky. Servlet doesn't have groups,
slide does. Servlet won't store our DAV:group-membership or other DAV properties
on the users, so slide has to store them.
If slide stores them, but we still want to support container based
authentication, we need a realm for each server, since servlet doesn't specify
enough in this area, and each server has its own realm implmentations.
That is ugly enough in itself, and adds confusion to install and usage, but
there is another issue for the large companies:
Typically they have large amounts of users, lets say 100000 organized into 2000
groups all stored in LDAP for example, and they want the reverse proxy, the web
applications, the email system etc to all use this database. Just administering
all this requires full time employees, so in this example they would not be
pleased to learn that they have to replicate all their users onto slide because
slide requires its own Realm, rather than the LDAP-Realm they would like to use.
Replication is duplicated information, which as we know is one of the most
common causes of computer problems...
Does this make any more sense?
> > Also, passing the security on the container is an awfully nice way to pass
> the
> > buck for a tricky piece of code, not to mention that we'd be reinventing
> the
> > wheel if we did it ourselves.
> >
> > Perhaps we can find a good solution that satisfies both worlds, but it is
> > tricky, and to me it looks like we should drop the parts of the security
> from
> > slide that aren't part of the Servlet 2.3 spec...
>
> Maybe I still do not quite understand... Why dropping web container
> managed authentication for Tomcat. It works, so let's keep it...
>
Its not about dropping the container managed authentication, in fact, I would
prefer to keep it. Its more about finding a clean solution to the problem, that
scales well too.
I'm thinking about the problem... I implemented a kind of 'UserStore' in slide
about a year or more ago, which provided an abstract interface for accessing the
users to the Slide API, and two sample 'Stores' a SlideStoreSlideUserStore
(which actually kept the users on the slide file system in the old fashioned way
for backwards compatibility) and a LDAPSlideUserStore. In this solution the
container does the authentication, and slide obtains the principal from the
container. Slide checks the permissions. Both systems, however, use the same
storage for the users.
This kind of direction looks promising to me. There were even a couple of people
interested in the change at the time, but I found the changes within slide I had
to make to get it working were pretty deep, and no one else managed to integrate
the patches... However, now that the group is alive, something of this scale
might be attempted again.
Let me know if this makes any sense to you, and what you think...
> Oliver
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------
This mail sent through the
ungerground webmail system
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
