ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BJ Freeman <bjf...@free-man.net>
Subject Re: Discussion: Permissions Checking Enhancement
Date Fri, 05 Dec 2008 19:33:37 GMT
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" <jacques.le.roux@les7arts.com>
>> 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" <bruno.busco@gmail.com>
>>> 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 <david.jones@hotwaxmedia.com>
>>>
>>>>
>>>> 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 <adrian.crum@yahoo.com>
>>>>>
>>>>>  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 <bruno.busco@gmail.com> wrote:
>>>>>>
>>>>>>  From: Bruno Busco <bruno.busco@gmail.com>
>>>>>>> Subject: Re: Discussion: Permissions Checking Enhancement
>>>>>>> To: dev@ofbiz.apache.org
>>>>>>> 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 <adrianc@hlmksw.com>
>>>>>>>
>>>>>>>  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 <adrianc@hlmksw.com>:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>> <adrianc@hlmksw.com>:
>>>>>>>
>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>
>>>>>>>> sumit.pandit@hotwaxmedia.com>
>>>>>>>>>>>>> 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" <bruno.busco@gmail.com>
>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <adrianc@hlmksw.com>:
>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
> 
> 
> 

Mime
View raw message