Apache Shiro subject [was: Re: Catalog/category privilegs per user]

[Jacques Le Roux <ja...@les7arts.com>]

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" <ad...@sandglass-software.com>
>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" <rh...@aesolves.com>
>>> On 7/15/12 9:19 AM, Jacques Le Roux wrote:
>>>> From: "Ruth Hoffman" <rh...@aesolves.com>
>>>>> 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" <ma...@gmail.com>
>>>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
> 
>