Leon Rosenberg wrote:
---Ursprüngliche Nachricht-----
Von: Borislav Sabev [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 13. Juli 2005 18:54
An: Struts Users Mailing List
Betreff: [OT] olipmic rings metaphor
How do you classify Security and Authorization issues in this
metaphor?
In my current project I have troubles since code that is
related somehow to Authorization is spread over all "rings.
Still it's difficult to me to have a clear understanding how
to implement in a nice, consistent way. I'll appreciate any
suggestions or recommendations about this problem.
I think each layer has its own security and authorization sublayers (a layer
itself can be composed of multiple layers) in the corba world better known
as interruptors. But each layer should only make decision based on the
knowledge which the layer itself posseses.
I fully agree here, that's why I consider Authorization as a ring that
intersect all other rings, and this means it depend on each of them.
But it fact better metaphor for it is that is a small ring inside every
other ring, i.e. not seen as one monolithic ring.
So the presentation layer decides whether a user is allowed to execute a
specific use case by checking user's permissions and roles.
The business layer decides whether the specific method can be called from
specific caller (a host for example), and the persistence layer decides
which process/host can access the database. If you think about what you want
to protect from whom, and act accordingly.
These are System Authorization activities, but I mean Business
Authorization activities.
For example I have companies with some persmisions and their employees
inherit and extend them.
There are 3 types of Business Roles: suppliers, consumers and
controlers. (think the names are enough to explain what they do more or
less)
There are different BO that suppliers put in the system, controlers
check them and publish them (i.e. make the "visible" to the consumers)
Suppliers can read all BO, but can change (edit, delete) only owned
objects. Controler can do all that Supplier can do + publishing.
Consumers can only read and make requests.
So let's imagine I have to show a single list of some BO by some search
criteria. The result list can be a mixture of BO owned and not owned
objects.
So here is list of checks that has to be performed to acomplish this:
1. Can the user see the list -> this should be enforced by the
controler and view layers
2. Which BO will be collected from persistence (or cache) layer - only
owned, owned + published etc -> this should be enforced by the model and
persistance layer.
3. Check for every item in the list if it can be edited/published by the
user -> this should be in the view only ( to show a link or button for
each item for edit )
So now you see how such "simple" usecase spread authorization logic over
all the layers ( not conserning hosts, db connections etc).
Regards
Borislav
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
