Catalog/category privilegs per user

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Catalog/category privilegs per user

Jacques Le Roux
Administrator
BTW I found that Shiro is not for this uage http://incubator.apache.org/syncope/ sounds better for that

>Shiro is an Access Manager [1] While Syncope is an Identity Manager [2]

>Access Management is more about authentication, Single SignOn, Federation, ...
>Identity Management is more about user provisioning, password management, ...

>[1] http://en.wikipedia.org/wiki/Web_access_management
>[2] http://en.wikipedia.org/wiki/Identity_management

Thanks to Francesco Chicchiriccò
>[3] https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap#Roadmap-3.0.0%28Maggiore%29
>[4]http://mail-archives.apache.org/mod_mbox/www-apachecon-discuss/201206.mbox/%3C4FE2DB7A.20103%40apache.org%3E

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