Hi Ruth,
I have just begun to read the most recent reference
http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf from your link below
Thanks for this precious information.
Jacques
From: "Ruth Hoffman" <[email protected]>
On 7/15/12 9:19 AM, Jacques Le Roux wrote:
From: "Ruth Hoffman" <[email protected]>
Hi Jacques:
IMHO, it would be really useful to have a way to assign OFBiz
"assets" to some type of protection group much like you can now do
with users (though the use of the UserLogin.) By "assets", I mean
things like a specific product, a file (as pointed to by a
contentId or dataResourceId) or business process (maybe as defined
using workflow).
Yes you put something on the table, Ruth. This needs more
consideration, indeed.
Not sure how to
1) define a business process (as, as you call them, an asset). Since
we don't really use the workflow component and are planning to
move it to Attic.
That was just an example, a way for me to relate what I'm trying to
explain to something that OFBiz people at least know about. I think if
we can first come up with a "language" and requirements that clearly
express what I'm talking about, well that would help. For example, the
term "Role Based Access Control" has a pretty good definition and
specification (http://csrc.nist.gov/groups/SNS/rbac/) that has been
around for years. The Unix files system is an example of a very simple
RBAC in action. So, first off we need to step away from how OFBiz does
this now, and define what it is that needs to be done.
I see 2 ways:
a) From a request-map uri (which may be seen as defining request flows)
b) Form a service (with possible SECA "callings")
The above are not very useful from my way of thinking. Problem with the
request-map or even "Service" based approach, is that we are only
protecting URLs (per request) and not individual "assets". What is
needed is a way to easily protect individual files by name and/or
directory location, database table rows (like a product where the
productId = X or an order where the orderId = Y).
The SECA approach is even more fraught with danger and if not applied
correctly breaks all kinds of logic. Anyhow, this is already what you
can do with SecurityPermissions and SecurityGroups. Just not very easily.
2) define an asset. Maybe we need to consider how other systems are
doing it. And, as we already dicussed on dev ML, I think Apache
Shiro could be used for this. The case you suggested could be handle
using what they call subject:
http://shiro.apache.org/authorization-features.html. We (developers)
mostly agreed on introducing/using Shiro in OFBiz.
Yes. I haven't had a chance to look at Shiro, but it sounds like this is
similar to what I have done in the past. I have created a few new
entities. One of those holds a "pointer" to the "subject" much like the
UserLogin holds a pointer to the user's login credentials. And then go
from there.
Now it need
the necessary human resources to do that. And we are already engaged
in other challenges (like the SlimDown action, see for intance
Adrian's last effort in this area: "Remove Code Related To Incomplete
"Authz" Implementation) "
https://issues.apache.org/jira/browse/OFBIZ-4839, etc.). So in long
term, yes I think it's a great idea...
This too is a good project and much needed. Probably more so then my
suggestion.
In my strategy, you could assign the "asset" to this "group" as well
as a UserLogin. Then you could check to see if both are in
the same group. If they are, the permission to access is granted. You
could even do groups of groups as a hierarchy of levels of
protection.
IMHO the OFBiz way of using SecurityPermissions, SecurityGroups etc.
is much too complex (and error prone) to achieve what is
effectively role based access control.
This needs really more thoughts and exchanges in the community before
going ahead. It's really a very important core feature...
I think so. And I've seen many real-world cases where a core feature
like this is something that sets OFBiz apart from its competitors.
But this gets away from the original question and answer(s) - to
which I might add the following for everyone's consideration:
Just because you restrict access to catalogs and categories does NOT
mean that products have restricted access. Since all that
catalogs and categories bring to the table is an elegant and
convenient mechanism for organizing products, this strategy does not
directly address the requirement to restrict access to individual
products. In other words, just because a catalog or specific
categories are protected, (without further logic to protect
products), a savvy browser can still see any product in the Product
table.
Right: catalog -> categories -> products "relationship" uses graph not
tree.
Unfortunately, there are a multitude of specific scenarios.
I think it's impossible to envision and model them all.
That's why I still prefer the graph relationship than tree for this.
It's more open, but also yes more fragile.
My 2cts (for now)
Jacques
Regards,
Ruth
On 7/14/12 8:19 AM, Jacques Le Roux wrote:
Roles are a part of it, see this page for rights organisation
https://demo-trunk.ofbiz.apache.org/partymgr/control/ProfileEditUserLoginSecurityGroups?partyId=admin&userLoginId=admin
You get there from the user profil, look for Security Groups. From
them follow the code and data. Looking into OOTB related demo
data is very good way to understand stuff, often quicker than
tracing code
Jacques
From: "MMA" <[email protected]>
Hi Jacques,
thanks for your fast response.
Im not sure if this is exactly what i was searching for...
My intention is to restrict the access to certain catalogues on the
front
end (in the ecommerce shop).
For instance, i want a un-registered user to see just our empty
front page,
without any catalogues/products.
Signed-in users should see different catalogues based on new
defined roles
e.g.
user 1
"role 1"
catalogue 1
catalogue 3
user 2
"role 2"
catalogue 1
catalogue 2
i hope that there is a possibility to do this in the backend,
because i want
to generate rules as dynamic as
possible, it would be much more effort to edit all template (or
similar)
files.
Is there any hint you could give me, where to start to achieve this? i
already found the possibility to bind
certain parties with a defined role to a catalogue, but i don't see
where
to define concrete rights for these
roles...
nevertheless, thank you and best regards,
Markus
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Catalog-category-privilegs-per-user-tp4634786p4634815.html
Sent from the OFBiz - User mailing list archive at Nabble.com.