>
>>>The purpose of the UserRights table is not clear to me. Do you intend that users should be given rights without being assigned to >>any roles?
>
>
>Rights are assigned first to roles, Then a user is assigned one or more roles. Then any user right that is different than the role right is
>stored in UserRights.
>
>So after login the rights for the user's roles are loaded, then the UserRights are loaded on top of them.

Understood. But my gut feeling is that it will be too complicated for an end user (acting in an 'Admin' role) to get a clear picture of exactly *why* which rights are available to each user (the same problem exists on a lesser scale as soon as you allow users to be assigned to more than one role). Why not just create an additional role to handle the 'fine-tuning' and drop the UserRights table?

>
>>>Why are the password details in the UserRoles table rather than the Users table?
>Because a user logs in as a specific role. His/her rights would be determined by the role they log into.

Don't see this. Why allow a user to login in different ways to obtain different rights - why not simply require them to login as a different user?

>
>>>How do the RoleRights.AccessLevel and Rights.AllowDeny fit together?
>
>The table has been changed 'AccessLevel' should read 'AllowDeny'.

OK. So is the AllowDeny field needed in the Rights table?

Going back to my first comment above: I haven't really found a way, even with my simpler structure, of presenting a clear picture of exactly why a specific user is assigned a specific right. Any thoughts on this?
Regards,
Viv