Jacques: my first reaction is if a robot can pull out confidential data then ofbiz would not pass the PCI audit.
the focus should be to not allow log in to confidential data, unless a strict protocol is followed. The other is to find all the ways a hack can be done, like DOS that may also allow access into the system. SATAN (Security Administrator Tool for Analyzing Networks) (1990)test very thoroughly. using it as a basis of testing would further ofbiz. http://d4rk-c0de.org/2008/11/15/satan-securitry-administrator/. Jacques Le Roux sent the following on 12/5/2008 8:25 AM: > I have another requirement : being able to dissalow acces to some pages > for some users if a number of hits in a pre-defined period of time is > exceeded. I have an idea of how to do that but do you thing it could be > interesting to be commited ? Maybe in a more generic way ? > > The purpose is security : this would prevent any kind of robot to pull > out confidential data from the system. > > Thanks > > Jacques > > From: "Jacques Le Roux" <[EMAIL PROTECTED]> >> So refering to defintions in >> http://docs.ofbiz.org/display/OFBTECH/OFBiz+security this would be >> between the component menu level and >> the screen level (which use "<if-has-permission" and >> "<if-service-permission" tags), that's it ? >> >> It would be great to be able to hide menus as Bruno suggested (having >> a parameter in menu-item like David sugested for screens >> def). It could be then named the menu level permission (we should >> then rename the component menu level to component level or even >> application level) >> >> In a 1st and generic approach we could use 2 user categories : experts >> and novices. By default the expert mode would be used (all >> shown OOTB) but users could change this in their preferences to novice >> mode. So this would need to define what novice could and >> should not see in all OFBiz (and should be updated later, being >> visible by default). >> >> Later contributors could defines specific categories and they could be >> added to users's preferences choice. Could not roles be used >> for that or is it really orthogonal ? (customer service can't see >> some accounting screens, but are able to view some other etc.). >> >> My 2 cts >> >> Jacques >> >> From: "Bruno Busco" <[EMAIL PROTECTED]> >>> David, >>> I like this idea. >>> >>> So we should add a screen property to specify a permission. >>> The same permission should be checked to render the menu item that >>> takes to >>> that screen (sub-screen). >>> Is this what you mean? >>> >>> This could be done even without the "getAllPermissions" service >>> proposed, am >>> I right? >>> >>> -Bruno >>> >>> >>> >>> 2008/12/3 David E Jones <[EMAIL PROTECTED]> >>> >>>> >>>> One option for this (or at least part of it), and one that I think >>>> has been >>>> discussed before, would be to introduce a convention for naming >>>> permissions >>>> (or more to the point, "ID-ing" permissions) based on screen names and >>>> locations. A few aspects of this: >>>> >>>> 1. We could configure specific screens to always require the >>>> screen-specific permission, or to require either a general permission >>>> (probably specified in the screen def) or the screen-specific >>>> permission >>>> >>>> 2. this would be a view-only permission for rendering the screen >>>> >>>> 3. doing it for each screen defined would allow for permissions on >>>> sub-screens and such as well >>>> >>>> -David >>>> >>>> >>>> >>>> On Nov 30, 2008, at 12:32 AM, Bruno Busco wrote: >>>> >>>> I need to simplify the UI has I described. >>>>> To do this I think the Map should contain ALL user permissions, not >>>>> restricted to a single application. >>>>> Could we think to specific permissions to hide the TabBar options? >>>>> >>>>> I understand that OFBiz UI is designed to have ALL there because at >>>>> least >>>>> everybody sees that a feature is available but this creates a >>>>> problem when >>>>> deplying to end user. >>>>> I understand also that the perfect UI is the one that reproduces >>>>> the very >>>>> specific users workflow and so it must be written ad hoc. >>>>> But having an 80% fitting UI with only permissions setting (user >>>>> profiling) >>>>> could be a good result. >>>>> >>>>> This IMO is another key factor for spreading OFBiz and having more >>>>> people >>>>> using it. >>>>> >>>>> I would like to hear other idea about this and, possibly, some user >>>>> profiling pattern ideas. >>>>> For sure the Portlet system will help in this direction but could >>>>> we think >>>>> to a UI profiling through permission too? >>>>> >>>>> -Bruno >>>>> >>>>> 2008/11/30 Adrian Crum <[EMAIL PROTECTED]> >>>>> >>>>> Bruno, >>>>>> >>>>>> I never got around to implementing that idea. I would still like >>>>>> to work >>>>>> on >>>>>> it though. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> --- On Sat, 11/29/08, Bruno Busco <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> From: Bruno Busco <[EMAIL PROTECTED]> >>>>>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>>>>> To: [email protected] >>>>>>> Date: Saturday, November 29, 2008, 10:30 AM >>>>>>> Hi Adrian, >>>>>>> I am thinking to something similar to what you proposed in >>>>>>> this thread. >>>>>>> What I would like to do is to simplify the UI to users who >>>>>>> should not >>>>>>> perform some operations. >>>>>>> >>>>>>> For instance, in the catalog application, when looking to >>>>>>> the EditProduct >>>>>>> screen, I would like that the following tabmenus: >>>>>>> Geos, IDs, Keywords, Associations, Manufacturing, Costs, >>>>>>> Attributes, >>>>>>> Agreements, Accounts, Maintenance, Meters, Workefforts >>>>>>> >>>>>>> should not be visible to standard users while they should >>>>>>> be visible to >>>>>>> admin. >>>>>>> >>>>>>> I am thinking to implement several permissions (may be some >>>>>>> are already >>>>>>> there) and to check for them in the menu items. >>>>>>> What do you think? >>>>>>> Did you implement something about it? >>>>>>> >>>>>>> Thank you, >>>>>>> -Bruno >>>>>>> >>>>>>> 2008/6/6 Adrian Crum <[EMAIL PROTECTED]> >>>>>>> >>>>>>> Correct. >>>>>>>> >>>>>>>> >>>>>>>> Bruno Busco wrote: >>>>>>>> >>>>>>>> Thank you, >>>>>>>>> it make sense; so a CREATE permission check will >>>>>>>>> >>>>>>>> be sufficient for the >>>>>>> >>>>>>>> CREATE button rendering. >>>>>>>>> -Bruno >>>>>>>>> >>>>>>>>> 2008/6/6 Adrian Crum <[EMAIL PROTECTED]>: >>>>>>>>> >>>>>>>>> The pattern used so far is that the ADMIN >>>>>>>>> >>>>>>>> permission is checked first, >>>>>>> >>>>>>>> then >>>>>>>>>> the other permissions. So if a user has the >>>>>>>>>> >>>>>>>>> ADMIN permission, they don't >>>>>>> >>>>>>>> need the additional permissions. >>>>>>>>>> >>>>>>>>>> I'll probably have all of the permissions >>>>>>>>>> >>>>>>>>> Map elements set to true if the >>>>>>> >>>>>>>> user has the ADMIN permission. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bruno Busco wrote: >>>>>>>>>> >>>>>>>>>> Adrian, >>>>>>>>>> >>>>>>>>>>> may be a newbie question but... >>>>>>>>>>> ...in the example you give what will >>>>>>>>>>> >>>>>>>>>> happen if a user has the ADMIN >>>>>>> >>>>>>>> permission but not the CREATE one? >>>>>>>>>>> Will the Create New button be rendered? >>>>>>>>>>> >>>>>>>>>>> In other words who is responsible for the >>>>>>>>>>> >>>>>>>>>> permission hierarchy ? >>>>>>> >>>>>>>> In order to display the CREATE button, >>>>>>>>>>> >>>>>>>>>> should a user be given with the >>>>>>> >>>>>>>> CREATE permission explicitly or the ADMIN >>>>>>>>>>> >>>>>>>>>> is sufficient? >>>>>>> >>>>>>>> >>>>>>>>>>> Thank you >>>>>>>>>>> -Bruno >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2008/6/6 Adrian Crum >>>>>>>>>>> >>>>>>>>>> <[EMAIL PROTECTED]>: >>>>>>> >>>>>>>> >>>>>>>>>>> I'll work on it this weekend. >>>>>>>>>>> >>>>>>>>>>> -Adrian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Ashish Vijaywargiya wrote: >>>>>>>>>>>> >>>>>>>>>>>> +1 >>>>>>>>>>>> >>>>>>>>>>>> Adrian I liked your idea. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jun 5, 2008 at 12:46 AM, >>>>>>>>>>>>> >>>>>>>>>>>> Sumit Pandit < >>>>>>> >>>>>>>> [EMAIL PROTECTED]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> +1 >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>>> Sumit Pandit >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Jun 5, 2008, at 3:04 AM, >>>>>>>>>>>>>> >>>>>>>>>>>>> Jacques Le Roux wrote: >>>>>>> >>>>>>>> >>>>>>>>>>>>>> Yes this sounds good to me >>>>>>>>>>>>>> >>>>>>>>>>>>> too >>>>>>> >>>>>>>> >>>>>>>>>>>>>> Jacques >>>>>>>>>>>>>> >>>>>>>>>>>>>> From: "Bruno >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Busco" <[EMAIL PROTECTED]> >>>>>>> >>>>>>>> >>>>>>>>>>>>>>> Wonderfull !!!! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Looking forward to having >>>>>>>>>>>>>>> >>>>>>>>>>>>>> it !!! ;-) >>>>>>> >>>>>>>> This will let me also >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> define a more granular permissions to >>>>>>> >>>>>>>> simplify >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> interface for >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> not-so-skilled users. >>>>>>> >>>>>>>> -Bruno >>>>>>>>>>>>>>>> 2008/6/4 Adrian Crum >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <[EMAIL PROTECTED]>: >>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> In the screen >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> widgets, you can check permissions with the >>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <if-has-permission> or <if-service-permission> >>>>>>> elements. That's >>>>>>> >>>>>>>> fine >>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>> only need to check >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> a single permission to control access to the >>>>>>> >>>>>>>> entire >>>>>>>>>>>>>>>>> screen. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Things get >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> complicated when a screen's elements are controlled by >>>>>>> >>>>>>>> more >>>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>>> one permission. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Let's say you have a typical Edit Item screen. The >>>>>>> >>>>>>>> screen >>>>>>>>>>>>>>>>> should be viewable >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> only to users who have the VIEW permission. >>>>>>> >>>>>>>> Users >>>>>>>>>>>>>>>>> who >>>>>>>>>>>>>>>>> have the UPDATE >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> permission can edit the item. Users who have the >>>>>>> >>>>>>>> CREATE >>>>>>>>>>>>>>>>> permission see a >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "New Item" button. Users who have DELETE >>>>>>> >>>>>>>> permission >>>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>> "Delete >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Item" button. Users who have the ADMIN permission have >>>>>>> >>>>>>>> unrestricted >>>>>>>>>>>>>>>>> access to the >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> screen. Wow. Five permission elements (and five >>>>>>> >>>>>>>> service >>>>>>>>>>>>>>>>> calls) >>>>>>>>>>>>>>>>> are needed to >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> control one screen. >>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Here's my >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> idea: have a permission service that returns ALL of the >>>>>>> >>>>>>>> user's >>>>>>>>>>>>>>>>> permissions in a >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Map. You call the service with the permission to >>>>>>> >>>>>>>> check >>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "ACCOUNTING" for example. The service returns a >>>>>>> Map containing all >>>>>>> >>>>>>>> of >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> user's >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ACCOUNTING permissions stored as Boolean objects. Let's >>>>>>> say >>>>>>> >>>>>>>> the >>>>>>>>>>>>>>>>> returned Map is >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> called permissionsMap and the user has >>>>>>> >>>>>>>> ACCOUNTING_VIEW >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> ACCOUNTING_UPDATE >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> permissions, then the Map would contain these >>>>>>> >>>>>>>> elements: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> CREATE=false >>>>>>>>>>>>>>>>> UPDATE=true >>>>>>>>>>>>>>>>> DELETE=false >>>>>>>>>>>>>>>>> VIEW=true >>>>>>>>>>>>>>>>> ADMIN=false >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If the service >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> call is put in the screen's <actions> element, >>>>>>> then >>>>>>> >>>>>>>> the >>>>>>>>>>>>>>>>> Map >>>>>>>>>>>>>>>>> elements could be >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> used to control the display of screen widget >>>>>>> >>>>>>>> sections, >>>>>>>>>>>>>>>>> menu items, and >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> form fields. >>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> Freemarker code >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> would be simpler too: >>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> <#if >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> permissionsMap.CREATE> >>>>>>> >>>>>>>> <!-- Render a >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Create New button --> >>>>>>> >>>>>>>> </#if> >>>>>>>>>>>>>>>>> <#if >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> permissionsMap.DELETE> >>>>>>> >>>>>>>> <!-- Render a >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Delete button --> >>>>>>> >>>>>>>> </#if> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >> > > >
