Role Based Access Security Patterns

Role Based Access Security Patterns

Post by RhythmAddi » Fri, 11 Apr 2008 06:33:01


Hi All,
SO my question is sort of a simple one...

Looking at something like this... http://www.yqcomputer.com/
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
 
 
 

Role Based Access Security Patterns

Post by H. S. Lahm » Fri, 11 Apr 2008 23:30:09

responding to Rhythm *** ...


Yes, the Strategy pattern will let you do that.


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
XXXX@XXXXX.COM
Pathfinder Solutions
http://www.yqcomputer.com/
blog: http://www.yqcomputer.com/
"Model-Based Translation: The Next Step in Agile Development". Email
XXXX@XXXXX.COM for your copy.
Pathfinder is hiring:
http://www.yqcomputer.com/
(888)OOA-PATH

 
 
 

Role Based Access Security Patterns

Post by RhythmAddi » Sat, 12 Apr 2008 05:35:02

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