I have mixed feelings about that type of authorization. True, in most
cases a user's role in the enterprise and their role as an OFBiz user
will be the same. But they might not be the same - so authorization
should not depend too heavily on the user's role in the enterprise.
From my perspective, it would be best if the OP redefined the
ProdCatalogRole to change the relation to PartyRole to no-fk, then
create a UI or service to assign the user to various catalogs in various
roles.
-Adrian
On 7/18/2012 11:45 AM, Jacques Le Roux wrote:
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.
