Leyne, Sean wrote:

>The "problem" that you think exists is very simply addressed by the web
>service authenticating a user using one connection (which has access to
>only the security data) and then have all other accesses done using
>having the a new connection created. As such, the new connection would
>be in the users context and thus governed by their specific rights.
>
>

That, at best, doubles the overhead. And if a user has multiple roles
(say a poster, moderator, and administrator), it doesn't work at all
since no single role can give the user his full range of access without
the dba being required to define artificial roles to map the artesian
product of actual roles. And to what end?

>While someone could implement the model you describe, it is NOT the
>model I have been describing but your too stuck on the "activating"
>function too see what I'm talking about.
>
>
>

I've been using this model in Netfrastructure for five years.
Netfrastructure applications and users couldn't live without it. Most
applications have a dozen or more major roles. The Firebird
collaboration site, for example, has the roles:

ADMIN
APPLICATION
AUTHOR
DESIGNER
EDITOR
GATEKEEPER
GROUP_MEMBER
GROUP_POST
MEMBER
MODERATOR
PUBLIC
REGISTRAR
WEBMASTER
WHEEL

If you'd have registered, you would have the roles PUBLIC and MEMBER in
general, GROUP_MEMBER and GROUP_POST for content owned by a group you
were a member of, and AUTHOR for content you authored. If you got
promoted for good behavior, we might also give you MODERATOR, REGISTRAR,
or even GATEKEEPER. When an application know what it was doing, it
would also be running with APPLICATION, but before we trusted anything
that originated from a browser, we'd drop APPLICATION and let the
primary roles do there thing.

Since we don't know what you are going to do before you do it, we need
to the application the privileges you entitled to, but nothing more. We
couldn't possibly restrict you to a single role since the row level
security is role driven, so content accessible by other roles would
simply disappear.

This is the way the world works. Somebody assigns you a set a roles to
perform. Each role gives you a set of privileges. You don't necessary
want to exert all of your privileges all the time, but there are times
that you do.

If the database security model is too weak to model the real world, the
only workaround is to give all privileges to the application server and
let it sort things out. This is logically equivalent to no database
security at all.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376