I'm not sure I totaly undestand your schema but could SiteFuse1ID ... 10 be
replaced with an intermediate table that would facilitate a many to many
relationship?
I've worked on a similar type security issue where we had levels that
inherited permissions (public, edit, approve live). These were then grouped
into different sections (fuses?) so an administrator could be public on 1
section yet approve content on another.
We did this by keeping an aggregate table that linked an admin to a section,
with a different security level for each section.
-----Original Message-----
From: Ryan Williams [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 10, 2000 2:51 PM
To: [EMAIL PROTECTED]
Subject: Intranet web security..looking for feedback
I am in need of feedback with regards to the user permission schema
I am creating for our admin site re-design. How has everyone else
implemented their security schema solutions in a similar-type situation,
as compared to our situation (outlined below).
The eventual re-write of our administration site (home app) will contain
about 5-10 different fuses. Each user will have to have a different
user permission associated with each Fuse of the Home
Application. It is possible for a user to be of "administrator"
permission for one Fuse and a "Normal" user of another Fuse, and
be totally restricted from the rest of the Fuses of the Admin home app.
The current table schema I have come up with is as follows:
I have modeled this structure based on my understanding
of the proposed sub-fuseaction navigation idea first proposed by Hal Helms a
little bit ago on this list. (i.e. root.fuse.fuseaction).
UserstAble:
- Id Autonum; primary key
- UserLoginName (the passwords are checked by windows NT)
UserSecurityProfile
- Id Autonum; primary key
- UserLoginNameID (fk) (this key taken from UsersTable at 1:N)
- SiteFuse1ID (fk) (this key is taken from UserSecurityTypeSource at 1:N)
- Sitefuse2ID (fk) ... Up to Fuse10
- AdminID (fk) (Taken from UsersTable = who created this profile at 1:N)
- Datecreated
- Iscurrent (bit field) 0=old; 1=currentprofile
UserSecurityTypeSource
- Id Autonum; primay key
- SecurityTypeCode (used for access throughout site)
- SecuritytypeNotes (English language meaning of code)
Notes: the SecurityTypeCode will be in the format: Group | level |
special_exceptions,
with the delimiter being the pipe "|".
The "level" here is an inclusive number from 1-10. A "level" of 1 equals a
public anonymous user (i.e. when I go to www.netscape.com). Also, each
"level"
inherits all the lower "level" security settings. Therefore, if you had a
"level 5"
you would inherit all the security attributes of level 1-4 and their
permissions, etc.
An admin example: with limited security access, and a single
security exception (i.e. has access to floors 1-8 normally but this
exception says he
can't access floor 6)applied to that user account would be: Admin|3|1.
Likewise, an admin with complete permissions to access all of
the site with no security exceptions in his profile would be:
Admin|10|0 (they can access floor 1-8 anytime, anyday, etc)
My Boss and I, after some consideration, have our reservations as to
the usefulness of this schema in regards to implementation, coding,
and maintenance. We are concerned it may be overly complicated for the
in-house
needs of our admin site.
Does anyone have a different bent on how they went about implementing
web security for legitimate users on a site they worked on ? Any input
would be
greatly appreciated. After all, the more time I spend on paper making sure
my
model is correct, the less problems I should encounter later on in the
middle of the
project when it is too late, and costly, to change our security schema.
Thanks :-)
Ryan Williams
[EMAIL PROTECTED]
---------------------------------------------------------------------------
---
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
