| View previous topic :: View next topic |
| Author |
Message |
RhythmAddict Guest
|
Posted: Wed Apr 09, 2008 9:33 pm Post subject: Role Based Access Security Patterns |
|
|
Hi All,
SO my question is sort of a simple one...
Looking at something like this...http://wiki.asp.net/page.aspx/289/
strategy/ structure for my application. Essentially, I need an
architecture that will allow me to 1) add roles easily 2) modify
permissions for existing/new roles easily
My question is, in implementing something similar to the above, where
should each of my SecurityCheckStrategy classes go to evaluate their
permissions? The first thing that comes to mind is have them check
against the db in a table that houses a relationship between roles and
the objects (pages/controls?) that they can access. But something in
the back of my head is telling me there is a better way to do this.
Any thoughts? Would love to see a simplified example of how others
accomplish this in their apps.
Cheers,
S |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman Guest
|
Posted: Thu Apr 10, 2008 7:30 pm Post subject: Re: Role Based Access Security Patterns |
|
|
responding to RhythmAddict...
| Quote: |
Looking at something like this...http://wiki.asp.net/page.aspx/289/
strategy/ structure for my application. Essentially, I need an
architecture that will allow me to 1) add roles easily 2) modify
permissions for existing/new roles easily
|
Yes, the Strategy pattern will let you do that.
| Quote: |
My question is, in implementing something similar to the above, where
should each of my SecurityCheckStrategy classes go to evaluate their
permissions? The first thing that comes to mind is have them check
against the db in a table that houses a relationship between roles and
the objects (pages/controls?) that they can access. But something in
the back of my head is telling me there is a better way to do this.
|
The basic issue is:
* R1 uses 1
[Validator] --------------------- [ValidationStrategy]
+ validateUser()
A
|
+---------------+---...
| |
[UserType1] [UserType2]
The R1 association will be instantiated based on what type of user is
being validated. Whoever does that will usually know what type of user
is in hand (e.g., a userType attribute in a [User] object).
IOW, by the time you need to do privilege validation, the context
information will usually already be in the instantiated objects.
similarly, the [ValidationStrategy] objects only need to access
attribute data to do their thing.
Quite often instantiating R1 will be done when the User object is
instantiated (perhaps from the DB) by a factory object of some sort.
That factory object would have a lookup table based on userType that
would yield the correct subclass references for the [ValidationStrategy]
to use in instantiating the association. That lookup table would in
initialized when the factory object is instantiated, usually at startup.
(That, in turn, implies that the [ValidationStrategy] objects are
already instantiated.)
That initialization will usually be more robust if it is defined in
external configuration data (e.g., in the DB). Basically one needs a
table that maps userType to a strategyType attribute in
[validationStrategy]. (Since you only need one object of each subclass,
strategyType doubles as an explicit identifier.) IOW, the thing you get
from the DB is the lookup table for instantiating R1, usually at startup.
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
RhythmAddict Guest
|
Posted: Thu Apr 10, 2008 8:35 pm Post subject: Re: Role Based Access Security Patterns |
|
|
H. S. Lahman,
Thanks for taking the time to give me an extremely thorough response
to my question. I'll move fwd with defining my permissions within the
DB where it makes sense.
Cheers,
S |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|

112 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|