The SiteFuse1ID column is the name of an individual Fuse of the site. For
example, "Accounts_ID", to use real data, would represent the "accounts"
Fuse in the
Home Application..
There would only be one record of any particular user in the table:
UserstAble. I linked the primary key of that table in a one to many
relationship with the UserSecurityProfile
table. The primary key of UserSecurityTypeSource table is linked to the
UserSecurityProfile NamedFuses column(s) in a one to many relationship.
This permits users to have many "security profiles" in the
UserSecurityProfile table, but only one can be considered "active" at a
time, via the IsCurrent bit field.
Lets consider an example: Say our Home Application had 5 "Fuses" (sub-apps),
"Edit Account", "Add New Account", "Delete Account", "Suspend Account", and
"Approve Account". The table "UserSecurityProfile" would have, in this
example, 5 of their columns using the names that I listed above. I would
store the correct security_ID from the "UserSecurityTypeSource" table, as a
foreign key, in each of the "Fuse Columns" of the UserSecurityProfile
table, therefore letting me know with a single column what that user's
security setting was in regards to that particular "Fuse" of the site.
Also, I wanted a way to keep a profile history, of sorts, for the user. So,
if, for whatever reason, the user had to re-set his current security profile
with a Fuse of the site to a past setting, we would only have to switch the
bit field of one of the older "profiles" in the table from a 0 to a 1,
instead of re-typing it into the database by hand..
However, this does not mean I am not interested in learning how you
implemented your security strategy using M:N tables. Could you send me some
example code off list so I can examine it? I went with the above strategy
for the simple reason that I couldn't "see" in my mind exactly how to set a
M:N table AND be able to get it to retain a "profile history" like I need to
do with this admin site. This was the best solution, to date, that I could
come up with to fulfill our needs.
If you want to email me off list please feel free to do so. Anyone else
have any other ideas ? I want to make sure I do this thing right now so our
site goes off without a hitch. :-)
Ryan Williams
[EMAIL PROTECTED]
----- Original Message -----
From: "JME Maxwell" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 10, 2000 3:09 PM
Subject: RE: Intranet web security..looking for feedback
> 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.
>
------------------------------------------------------------------------------
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.
