[AccessD] You don't need perfect code to avoid security problems

Hi Francisco

I think you need to leave Users and Groups and which users are members
of which groups, UserGroups, as is.

Then build a set of tables for Apps and Attributes where Apps is a
list of your Apps and Attributes are whatever security or user
property (menus, printer options, default colourset and language,
saved options for the user, whatever) that could be assigned a user of
an app. 

Now you can build Roles (Admin, Clerk, Student, etc.) which for every
App can be assigned a selection of Attributes.

Finally, build UserRoles and GroupRoles to connect users and groups
with apps and attributes.
When a user logs in, check UserRoles as well as UserGroups/GroupRoles
to retrieve the current attributes (including security) for the
current app for this user.

This, of course, assumes that one attribute cannot negate another;
otherwise things get very complicated.

/gustav


> In the company I work for, we are gearing up to deliver a full blown
> Upgrade to our current Department System.  It is currently in Access 97 
> and we've already been handeling the growing pains w/ normalizing the 
> data and upsizing it to Sql Server 2000.  The 2nd part is a little more 
> critical because it deals w/ Security and because eventually all this 
> will auto-synchronize as a distributed application, but I digress.

> A common Security Topology follows this type of table format

> Users (1-many) UserGroups (many-1) Groups

> But what if the database needed to handel security for multiple 
> applications. Would it then be more Along the lines of

> Users (1-many) UserApp (many-1) Apps (1-many) Groups

> The reason I ask, is because already I'm receiving a list of possible 
> "GROUP/Role" names of what each application will use.  Commonalities are 
> ADMIN and Clerk or Guest.