Subject | Re: [IB-Architect] Roles (ex planning the use of blr codes) |
---|---|
Author | Jim Starkey |
Post date | 2001-04-18T21:59:26Z |
At 06:07 PM 4/18/01 -0300, you wrote:
typically has four roles:
User: Access rights given to unidentified users
Member: Access rights given to special identified users
Application: Access rights given to the server side application
Admin: Access rights given to an administrator
The standard account used by a web-server module (or ISAPI dll)
usually has User (active, Member (latent), and Application (active).
The application, if it recognizes the user, may activate Member.
Most of the time the application runs with Application active. If,
however, it needs to do some sort of query on behalf of the user,
it can deactivate Application before operation, which is then
subject to the privileges accorded User and maybe Member.
This is an example of a class of security models that recognize
that servers often act on behalf of clients, and the server and
client has distinct security policies. The application says,
on a operation by operation basis, "this operation should be
checked against my rights as a server" or "this operation
should be check against the clients rights." NT already supports
this type of security mechanism; Linux will have it in about
ten year then blame Gates for not publishing the source.
Since privileges in a SQL database are additive, there are
no conflicting permissions and restrictions.
Jim Starkey
>No, with several active roles. A Netfrastructure application
>I assume you mean with only one active role at a time, right? Changing roles
>without having to reconnect sounds quite useful. But when defining each role
>correctly, I really don't think there should be any need to support the user
>of multiple active roles. That would introduce the problem of conflicting
>permissions and restrictions, and it would probably generate more headaches
>than saving time.
>
typically has four roles:
User: Access rights given to unidentified users
Member: Access rights given to special identified users
Application: Access rights given to the server side application
Admin: Access rights given to an administrator
The standard account used by a web-server module (or ISAPI dll)
usually has User (active, Member (latent), and Application (active).
The application, if it recognizes the user, may activate Member.
Most of the time the application runs with Application active. If,
however, it needs to do some sort of query on behalf of the user,
it can deactivate Application before operation, which is then
subject to the privileges accorded User and maybe Member.
This is an example of a class of security models that recognize
that servers often act on behalf of clients, and the server and
client has distinct security policies. The application says,
on a operation by operation basis, "this operation should be
checked against my rights as a server" or "this operation
should be check against the clients rights." NT already supports
this type of security mechanism; Linux will have it in about
ten year then blame Gates for not publishing the source.
Since privileges in a SQL database are additive, there are
no conflicting permissions and restrictions.
Jim Starkey