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.
