Subject Re: [Firebird-Architect] FB security - Roles vs Groups
Author Geoff Worboys
Hi Sean,

> I don't agree.

Somehow I didn't think you would :-)

> In my model I only have to define n roles and then link the
> users to the roles (multiple) as appropriate.


> Role A
> Role B
> Role C
> Role D

> User A -> Role A
> User B -> Role B
> User C -> Roles A & B & C
> User D -> Roles A & B & C & D

...

> I don't see how your example accomplishes the goal, or
> certainly in a manner which is as straight-forward as the
> one I outline above.

To implement your example requires having a users table in the
application database. If there are other reasons for such a
table then perhaps your solution is appropriate. My example
was intended to show that your example could be implemented
without a separate users table.

Role A
Role B
Role C
Role D

Role User1 -> Role A
Role User2 -> Role B
Role User3 -> Roles A & B & C
Role User4 -> Roles A & B & C & D

By implementing roles named (in some way) after the users you
can achieve exactly the same effect as having a separate users
table, but without needing to introduce any non-standard
security implementation.

Indeed the only difference between our two suggestions is where
the grouping of privileges takes place. You require a separate
user table, I want it to occur as part of the roles.

The advantage I see with my example is that it uses the SQL
standard role capability (once FB supports it more fully) to
achieve the result.

If a User1 logs on with role User2 they wont get anywhere
because they will not have been given memberhip of that role.
Not sure what happens if the user logs on with role A, I
would expect that that is not permitted either since their
membership is to role User1 (which includes role A).

The other advantages I see with my suggestion is that it
inherently maintains backwards compatibility and it provides
great flexibility in how any given application will implement
its security.


Not that I am against your suggestion of a separate users table
to carry such things as user specific role groupings. I just
dont think it is necessary _if_ we can get FB to support roles
within roles. To my mind supporting roles within roles should
be the first priority as it would be useful whether or not we
also have a separate user table.

--
Geoff Worboys
Telesis Computing