Catalog/category privilegs per user

[MMA]

Hi Experts,

I'm quite new to OFBiz and currently trying to get an overview over the different features it offers.
One goal i'd like to achieve is that i can grant or revoke different users access to different catalogues/categories.

Is this functionality offered ootb? i haven't found a possibility to do this by now - maybe some of you could give me a hint where to look at/how this is possible?

Thanks and best regards,
Markus

[Jacques Le Roux]

You need to use the security options for that. You will find OOTB examples in code
https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+security

Jacques

From: "MMA" <[hidden email]>

> Hi Experts,
>
> I'm quite new to OFBiz and currently trying to get an overview over the
> different features it offers.
> One goal i'd like to achieve is that i can grant or revoke different users
> access to different catalogues/categories.
>
> Is this functionality offered ootb? i haven't found a possibility to do this
> by now - maybe some of you could give me a hint where to look at/how this is
> possible?
>
> Thanks and best regards,
> Markus
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Catalog-category-privilegs-per-user-tp4634786.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

[MMA]

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

[Jacques Le Roux]

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" <[hidden email]>

> 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.

[Deepak Agarwal-2]

Hello Jacques,

Just my opinion regarding role based restriction over ui parts, I see 2
possibilities to do it OOTB:

1) Each request-map is unique, so we can have an interface to link requests
with a particular role
2) We can also have role based selection of screens.

An example interface would be:

Select Screen (drop down)             Restrict for Roles (drop down)

so hasPermission can be extended as isRestricted(screen, role) .

On Sat, Jul 14, 2012 at 5:49 PM, Jacques Le Roux <
[hidden email]> wrote:

> Roles are a part of it, see this page for rights organisation
> https://demo-trunk.ofbiz.**apache.org/partymgr/control/**
> ProfileEditUserLoginSecurityGr**oups?partyId=admin&**userLoginId=admin<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" <[hidden email]>
>
>  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<http://ofbiz.135035.n4.nabble.com/Catalog-category-privilegs-per-user-tp4634786p4634815.html>
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>
>> --
>> Thanks,
>> Deepak Agarwal,
>>
>> Paxcel Technologies Pvt Ltd.
>> Hartron Complex, Sector 18, Gurgaon, India.
>> E-Mail: [hidden email]
>> Mobile: [phone]
>>
>>

[Jacques Le Roux]

Hi Deepak,

Without extension, you may easily cut at different levels using widgets (more for backend side but can be used also on eCommerce UI
types)
* Applications
* Menus
* screens
* parts of screens
* forms
* possibly parts of forms (never tried that could be by using skip-start and skip-end and maybe hide-header , but become more
complicated and I just realise that those attributes are missing xsd doc :/)

Of course you can also filter in events or services (related to request-map)

Markus case is very specific and he wants to avoid mucking in templates.
I'm not quite sure how to do that without really thinking/trying,  and I'm not inclined to do so today :o)
Maybe Markus can pick your ideas...

Jacques

From: "Deepak Agarwal" <[hidden email]>

> Hello Jacques,
>
> Just my opinion regarding role based restriction over ui parts, I see 2
> possibilities to do it OOTB:
>
> 1) Each request-map is unique, so we can have an interface to link requests
> with a particular role
> 2) We can also have role based selection of screens.
>
> An example interface would be:
>
> Select Screen (drop down)             Restrict for Roles (drop down)
>
> so hasPermission can be extended as isRestricted(screen, role) .
>
> On Sat, Jul 14, 2012 at 5:49 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Roles are a part of it, see this page for rights organisation
>> https://demo-trunk.ofbiz.**apache.org/partymgr/control/**
>> ProfileEditUserLoginSecurityGr**oups?partyId=admin&**userLoginId=admin<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" <[hidden email]>
>>
>>  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<http://ofbiz.135035.n4.nabble.com/Catalog-category-privilegs-per-user-tp4634786p4634815.html>
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>
>>> --
>>> Thanks,
>>> Deepak Agarwal,
>>>
>>> Paxcel Technologies Pvt Ltd.
>>> Hartron Complex, Sector 18, Gurgaon, India.
>>> E-Mail: [hidden email]
>>> Mobile: [phone]
>>>
>>>
>

[Ruth Hoffman-2]

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).

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.

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.

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" <[hidden email]>
>> 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.
>

[Jacques Le Roux]

From: "Ruth Hoffman" <[hidden email]>
> 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.
  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")
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. 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...

> 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...

> 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" <[hidden email]>
>>> 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.
>>
>
>

[Jacques Le Roux]

From: "Jacques Le Roux" <[hidden email]>

> From: "Ruth Hoffman" <[hidden email]>
>> 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.
>  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")
> 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. 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...
>
>> 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...
>
>> 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.

>"more fragile."
From a security POV I mean (to keep things clear)

Jacques

> 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" <[hidden email]>
>>>> 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.
>>>
>>
>>

[Ruth Hoffman-2]

On 7/15/12 9:19 AM, Jacques Le Roux wrote:

> From: "Ruth Hoffman" <[hidden email]>
>> 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" <[hidden email]>
>>>> 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.
>>>
>>
>>
>

[Jacques Le Roux]

From: "Ruth Hoffman" <[hidden email]>
>>> 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.

Which competitors are you thinking about?

Jacques

[Ruth Hoffman-2]

Did say that?
Well I guess that is a typo...what I meant to write is:

If we had a core feature like this (and I didn't have to prototype it
and then build it each time), well that could make my life much easier.
By the time I get into a project and this sort of thing comes up, the
competition has long since be bested by OFBiz and all the other cool
features it offers.

This is something that most OFBiz adopters don't understand and/or don't
see until much later in the development cycle - if at all.

Ruth
On 7/16/12 5:32 PM, Jacques Le Roux wrote:

> From: "Ruth Hoffman" <[hidden email]>
>>>> 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.
>
> Which competitors are you thinking about?
>
> Jacques
>

[Jacques Le Roux]

From: "Ruth Hoffman" <[hidden email]>
> Did say that?
> Well I guess that is a typo...what I meant to write is:
>
> If we had a core feature like this (and I didn't have to prototype it and then build it each time), well that could make my life
> much easier.

Yes everybody life I guess

> By the time I get into a project and this sort of thing comes up, the competition has long since be bested by OFBiz and all the
> other cool features it offers.

Arg, sorry I don't get this sentence (tried twice to read ;o). I mean
<<
> the competition has long since be bested by OFBiz and all the other cool features it offers.
>>
excuse: English is not my mother's tongue :p

> This is something that most OFBiz adopters don't understand and/or don't see until much later in the development cycle - if at
> all.

We need Shiro for sure, "we" agreed. What we will need after the slimdown effort is to get a consensus between developers about what
should be done next. And not only, but as some requested already, *a road map*, with tasks ordered (and if possible assigned,
whisful thinking, I'm an optimist). This can stay simple with only big tasks (projects?) referred to, like
http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/

Jacques

> Ruth
> On 7/16/12 5:32 PM, Jacques Le Roux wrote:
>> From: "Ruth Hoffman" <[hidden email]>
>>>>> 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.
>>
>> Which competitors are you thinking about?
>>
>> Jacques
>>
>
>

[Ruth Hoffman-2]

On 7/17/12 6:21 AM, Jacques Le Roux wrote:
> From: "Ruth Hoffman" <[hidden email]>
>> By the time I get into a project and this sort of thing comes up, the
>> competition has long since be bested by OFBiz and all the other cool
>> features it offers.
> Arg, sorry I don't get this sentence (tried twice to read ;o). I mean
> <<
By the time I get involved with an implementation of OFBiz, there is no
competition. OFBiz is already the selected platform for all the reasons
we know about. The list of reasons why OFBiz gets selected is too long
to enumerate here. I wrote a marketing piece called the "OFBiz Top 10.
Why you should consider OFBiz for your next enterprise software
endeavor". It is a PDF so I can't attach it. But if you want it, let me
know. I'll send it to you.

>> This is something that most OFBiz adopters don't understand and/or
>> don't see until much later in the development cycle - if at all.
>
> We need Shiro for sure, "we" agreed. What we will need after the
> slimdown effort is to get a consensus between developers about what
> should be done next. And not only, but as some requested already, *a
> road map*, with tasks ordered (and if possible assigned, whisful
> thinking, I'm an optimist). This can stay simple with only big tasks
> (projects?) referred to, like
> http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/
>
> Jacques
>

[Deepak Agarwal-2]

Please send to me too.

On Tue, Jul 17, 2012 at 4:55 PM, Ruth Hoffman <[hidden email]> wrote:

>
> On 7/17/12 6:21 AM, Jacques Le Roux wrote:
>
>> From: "Ruth Hoffman" <[hidden email]>
>>
>>> By the time I get into a project and this sort of thing comes up, the
>>> competition has long since be bested by OFBiz and all the other cool
>>> features it offers.
>>>
>> Arg, sorry I don't get this sentence (tried twice to read ;o). I mean
>> <<
>>
> By the time I get involved with an implementation of OFBiz, there is no
> competition. OFBiz is already the selected platform for all the reasons we
> know about. The list of reasons why OFBiz gets selected is too long to
> enumerate here. I wrote a marketing piece called the "OFBiz Top 10. Why you
> should consider OFBiz for your next enterprise software endeavor". It is a
> PDF so I can't attach it. But if you want it, let me know. I'll send it to
> you.
>
>  This is something that most OFBiz adopters don't understand and/or don't
>>> see until much later in the development cycle - if at all.
>>>
>>
>> We need Shiro for sure, "we" agreed. What we will need after the slimdown
>> effort is to get a consensus between developers about what should be done
>> next. And not only, but as some requested already, *a road map*, with tasks
>> ordered (and if possible assigned, whisful thinking, I'm an optimist). This
>> can stay simple with only big tasks (projects?) referred to, like
>> http://blog.jquery.com/2012/**06/28/jquery-core-version-1-9-**and-beyond/<http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/>
>>
>> Jacques
>>
>> --
>> Thanks,
>> Deepak Agarwal,
>>
>> Paxcel Technologies Pvt Ltd.
>> Hartron Complex, Sector 18, Gurgaon, India.
>> E-Mail: [hidden email]
>> Mobile: [phone]
>>
>>

[Jacques Le Roux]

From: "Ruth Hoffman" <[hidden email]>

> On 7/17/12 6:21 AM, Jacques Le Roux wrote:
>> From: "Ruth Hoffman" <[hidden email]>
>>> By the time I get into a project and this sort of thing comes up, the
>>> competition has long since be bested by OFBiz and all the other cool
>>> features it offers.
>> Arg, sorry I don't get this sentence (tried twice to read ;o). I mean
>> <<
> By the time I get involved with an implementation of OFBiz, there is no
> competition. OFBiz is already the selected platform for all the reasons
> we know about. The list of reasons why OFBiz gets selected is too long
> to enumerate here. I wrote a marketing piece called the "OFBiz Top 10.
> Why you should consider OFBiz for your next enterprise software
> endeavor". It is a PDF so I can't attach it. But if you want it, let me
> know. I'll send it to you.

Ha yes, I get your sentence now, makes sense to me finally :o)
Sure please send me the PDF

Jacques

>>> This is something that most OFBiz adopters don't understand and/or
>>> don't see until much later in the development cycle - if at all.
>>
>> We need Shiro for sure, "we" agreed. What we will need after the
>> slimdown effort is to get a consensus between developers about what
>> should be done next. And not only, but as some requested already, *a
>> road map*, with tasks ordered (and if possible assigned, whisful
>> thinking, I'm an optimist). This can stay simple with only big tasks
>> (projects?) referred to, like
>> http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/
>>
>> Jacques
>>
>
>

[Ruth Hoffman-2]

Hello All:
If you'd like this document, please send me a separate email:
[hidden email].
I will consider your request as time permits.
Best Regards,
Ruth
On 7/17/12 7:30 AM, Deepak Agarwal wrote:

> Please send to me too.
>
> On Tue, Jul 17, 2012 at 4:55 PM, Ruth Hoffman <[hidden email]> wrote:
>
>> On 7/17/12 6:21 AM, Jacques Le Roux wrote:
>>
>>> From: "Ruth Hoffman" <[hidden email]>
>>>
>>>> By the time I get into a project and this sort of thing comes up, the
>>>> competition has long since be bested by OFBiz and all the other cool
>>>> features it offers.
>>>>
>>> Arg, sorry I don't get this sentence (tried twice to read ;o). I mean
>>> <<
>>>
>> By the time I get involved with an implementation of OFBiz, there is no
>> competition. OFBiz is already the selected platform for all the reasons we
>> know about. The list of reasons why OFBiz gets selected is too long to
>> enumerate here. I wrote a marketing piece called the "OFBiz Top 10. Why you
>> should consider OFBiz for your next enterprise software endeavor". It is a
>> PDF so I can't attach it. But if you want it, let me know. I'll send it to
>> you.
>>
>>   This is something that most OFBiz adopters don't understand and/or don't
>>>> see until much later in the development cycle - if at all.
>>>>
>>> We need Shiro for sure, "we" agreed. What we will need after the slimdown
>>> effort is to get a consensus between developers about what should be done
>>> next. And not only, but as some requested already, *a road map*, with tasks
>>> ordered (and if possible assigned, whisful thinking, I'm an optimist). This
>>> can stay simple with only big tasks (projects?) referred to, like
>>> http://blog.jquery.com/2012/**06/28/jquery-core-version-1-9-**and-beyond/<http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/>
>>>
>>> Jacques
>>>
>>> --
>>> Thanks,
>>> Deepak Agarwal,
>>>
>>> Paxcel Technologies Pvt Ltd.
>>> Hartron Complex, Sector 18, Gurgaon, India.
>>> E-Mail: [hidden email]
>>> Mobile: [phone]
>>>
>>>

[Jacques Le Roux]

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" <[hidden email]>

> On 7/15/12 9:19 AM, Jacques Le Roux wrote:
>> From: "Ruth Hoffman" <[hidden email]>
>>> 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" <[hidden email]>
>>>>> 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.
>>>>
>>>
>>>
>>
>
>

[Adrian Crum-3]

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" <[hidden email]>
>> On 7/15/12 9:19 AM, Jacques Le Roux wrote:
>>> From: "Ruth Hoffman" <[hidden email]>
>>>> 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" <[hidden email]>
>>>>>> 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.
>>>>>
>>>>
>>>>
>>>
>>
>>

[Jacques Le Roux]

I was not thinking about catalog particularly/category. Maybe I should have changed the subject at this point.
I was more focusing on the "asset" notion Ruth introduced in relation with the "subject" concept Apache Shiro uses.
I believe we should try to escape from OOTB code for those things and try to deleagate more to specialised projects.
Same idea with content repository and Apache JackRabbit where an effort has already made by Sascha.

Jacques

From: "Adrian Crum" <[hidden email]>

>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" <[hidden email]>
>>> On 7/15/12 9:19 AM, Jacques Le Roux wrote:
>>>> From: "Ruth Hoffman" <[hidden email]>
>>>>> 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" <[hidden email]>
>>>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>