Discussion: Permissions Checking Enhancement
Locked
123
123
Re: Discussion: Permissions Checking Enhancement
 
Administrator
|
From: "Jacques Le Roux" <[hidden email]>
> BJ, > > The client concern is in case a login/pwd couple is used but not by the right person (lost, stolen, etc.). Only biometric security > could deal with that I guess. > > By limiting the number of time a page can be visited in a period of time you don't really prevent using UI to pull out > confidential > data but you make it so long (years) that it's not usable. It's something used in spam fighting known as tarpitting. It has proven > to be very efficient and is now used in the gray list concept wich works great. Anyway for the moment it's the requirement I have > BTW I wonder if it should not better block the account and send a message to the admin in such case. He/she would then be able to > reset the login/pwd to secure anew the login. > > I will put the check in at end of RequestHandler.renderView just after the block where ServerHitBin.countView is used. This would > clearly separate this new security aspect. And having it at the framework level is clearly easier : you only have to define a list > of pages to constrain by PartyRoles. I had a better idea : to use a preprocessor event. I will though need to make a small change to allow to return a specific message from the event. I guess it will be the only thing I will commit, except if some people are interested in the tarpitting feature. Jacques > In the check I will need > . PartyRole(s), > . The list of pages to constrain access by PartyRoles. I will be an ConstrainViewByRole entity with 2 fields : partyRole viewName > (pages are actually views in OFBiz) > . Max number of page access allowed, and the period of time for counting the number of page accesses in security.properties > . An AccessedPage entity with fields loginId viewAccessed dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) > > I think it's a feature generic enough to be used in Framework if someone is interested in future (if nothing is defined in > security.properties the block would be simply skipped so it's harmful). So if nobody see a problem with that I will implement and > commit. Any comments welcome > > Thanks > > Jacques > > From: "BJ Freeman" <[hidden email]> >> 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" <[hidden email]> >>>> 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" <[hidden email]> >>>>> 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 <[hidden email]> >>>>> >>>>>> >>>>>> 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 <[hidden email]> >>>>>>> >>>>>>> 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 <[hidden email]> wrote: >>>>>>>> >>>>>>>> From: Bruno Busco <[hidden email]> >>>>>>>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>>>>>>> To: [hidden email] >>>>>>>>> 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 <[hidden email]> >>>>>>>>> >>>>>>>>> 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 <[hidden email]>: >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>> <[hidden email]>: >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> 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 < >>>>>>>>> >>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>> 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" <[hidden email]> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <[hidden email]>: >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >> > |
Re: Discussion: Permissions Checking Enhancement
|
sorry I have not responded till now
Inline: Jacques Le Roux sent the following on 12/9/2008 7:37 AM: > From: "Jacques Le Roux" <[hidden email]> >> BJ, >> >> The client concern is in case a login/pwd couple is used but not by >> the right person (lost, stolen, etc.). Only biometric security >> could deal with that I guess. have to think on this one. using encrypted USB devices for login works with PGP. >> >> By limiting the number of time a page can be visited in a period of >> time you don't really prevent using UI to pull out confidential >> data but you make it so long (years) that it's not usable. It's >> something used in spam fighting known as tarpitting. It has proven >> to be very efficient and is now used in the gray list concept wich >> works great. Anyway for the moment it's the requirement I have >> BTW I wonder if it should not better block the account and send a >> message to the admin in such case. He/she would then be able to reset >> the login/pwd to secure anew the login. spammers. However if there is a heavy use of tarpitting, you are using up a lot of threads and memory. I think blocking the account, and sending a email to the person's registered email with a link back to the login would validate them. the link would let them validate the email then another email would send them their logging information. CC the Admin would be an option as well. >> >> I will put the check in at end of RequestHandler.renderView just after >> the block where ServerHitBin.countView is used. This would >> clearly separate this new security aspect. And having it at the >> framework level is clearly easier : you only have to define a list >> of pages to constrain by PartyRoles. have to review code before I comment. > > I had a better idea : to use a preprocessor event. I will though need to > make a small change to allow to return a specific message from the > event. I guess it will be the only thing I will commit, except if some > people are interested in the tarpitting feature. interested but not knowledgeable enough to understand how it works. > > Jacques > >> In the check I will need >> . PartyRole(s), >> . The list of pages to constrain access by PartyRoles. I will be an >> ConstrainViewByRole entity with 2 fields : partyRole viewName >> (pages are actually views in OFBiz) >> . Max number of page access allowed, and the period of time for >> counting the number of page accesses in security.properties >> . An AccessedPage entity with fields loginId viewAccessed >> dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) >> >> I think it's a feature generic enough to be used in Framework if >> someone is interested in future (if nothing is defined in >> security.properties the block would be simply skipped so it's >> harmful). So if nobody see a problem with that I will implement and >> commit. Any comments welcome >> >> Thanks >> >> Jacques >> >> From: "BJ Freeman" <[hidden email]> >>> 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" <[hidden email]> >>>>> 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" <[hidden email]> >>>>>> 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 <[hidden email]> >>>>>> >>>>>>> >>>>>>> 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 <[hidden email]> >>>>>>>> >>>>>>>> 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 <[hidden email]> wrote: >>>>>>>>> >>>>>>>>> From: Bruno Busco <[hidden email]> >>>>>>>>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>>>>>>>> To: [hidden email] >>>>>>>>>> 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 <[hidden email]> >>>>>>>>>> >>>>>>>>>> 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 <[hidden email]>: >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>> <[hidden email]>: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>> 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 < >>>>>>>>>> >>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>>> 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" <[hidden email]> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> <[hidden email]>: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> > > > |
Re: Discussion: Permissions Checking Enhancement
|
Administrator
|
From: "BJ Freeman" <[hidden email]>
> sorry I have not responded till now > Inline: Thanks for your interest > Jacques Le Roux sent the following on 12/9/2008 7:37 AM: >> From: "Jacques Le Roux" <[hidden email]> >>> BJ, >>> >>> The client concern is in case a login/pwd couple is used but not by >>> the right person (lost, stolen, etc.). Only biometric security >>> could deal with that I guess. > have to think on this one. > using encrypted USB devices for login works with PGP. I did not think about that. Anyway it's not the thing the client is looking for (too much turnover I imagine) >>> >>> By limiting the number of time a page can be visited in a period of >>> time you don't really prevent using UI to pull out confidential >>> data but you make it so long (years) that it's not usable. It's >>> something used in spam fighting known as tarpitting. It has proven >>> to be very efficient and is now used in the gray list concept wich >>> works great. Anyway for the moment it's the requirement I have >>> BTW I wonder if it should not better block the account and send a >>> message to the admin in such case. He/she would then be able to reset >>> the login/pwd to secure anew the login. > yes use tarpitting works very well. I found it really slows down the > spammers. However if there is a heavy use of tarpitting, you are using > up a lot of threads and memory. > I think blocking the account, and sending a email to the person's > registered email with a link back to the login would validate them. > the link would let them validate the email then another email would send > them their logging information. > CC the Admin would be an option as well. Actually we have also to deal with the rare case of an authorised person who reachs the limit. So we will redirect this person to an explicit screen where will ask him/her to request the admin him/herself. Thieves will be tarpitted, that's all. >>> I will put the check in at end of RequestHandler.renderView just after >>> the block where ServerHitBin.countView is used. This would >>> clearly separate this new security aspect. And having it at the >>> framework level is clearly easier : you only have to define a list >>> of pages to constrain by PartyRoles. > have to review code before I comment. Forget it : obsolete >> I had a better idea : to use a preprocessor event. I will though need to >> make a small change to allow to return a specific message from the >> event. I guess it will be the only thing I will commit, except if some >> people are interested in the tarpitting feature. > interested but not knowledgeable enough to understand how it works. Really simple, I will create a Jira with a patch and hopefully a 3 lines explanation. It's much simpler and clean. So much things are already there, you just have to be patient enough to discover them at the rigth place, the right moment ;o) Jacques >> Jacques >> >>> In the check I will need >>> . PartyRole(s), >>> . The list of pages to constrain access by PartyRoles. I will be an >>> ConstrainViewByRole entity with 2 fields : partyRole viewName >>> (pages are actually views in OFBiz) >>> . Max number of page access allowed, and the period of time for >>> counting the number of page accesses in security.properties >>> . An AccessedPage entity with fields loginId viewAccessed >>> dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) >>> >>> I think it's a feature generic enough to be used in Framework if >>> someone is interested in future (if nothing is defined in >>> security.properties the block would be simply skipped so it's >>> harmful). So if nobody see a problem with that I will implement and >>> commit. Any comments welcome >>> >>> Thanks >>> >>> Jacques >>> >>> From: "BJ Freeman" <[hidden email]> >>>> 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" <[hidden email]> >>>>>> 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" <[hidden email]> >>>>>>> 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 <[hidden email]> >>>>>>> >>>>>>>> >>>>>>>> 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 <[hidden email]> >>>>>>>>> >>>>>>>>> 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 <[hidden email]> wrote: >>>>>>>>>> >>>>>>>>>> From: Bruno Busco <[hidden email]> >>>>>>>>>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>>>>>>>>> To: [hidden email] >>>>>>>>>>> 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 <[hidden email]> >>>>>>>>>>> >>>>>>>>>>> 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 <[hidden email]>: >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> <[hidden email]>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> 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 < >>>>>>>>>>> >>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>>>> 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" <[hidden email]> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> <[hidden email]>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> >> > |
|
|
In reply to this post by BJ Freeman
BJ,
Yes there are plenty of options to improve and enhance security of login methods but they can still be stolen/copied/lost etc with varying degrees of ease and success. When that happens you're exposed to data leakage. The point of the feature is to limit that damage should a valid access method be compromised. For example if you have 10's of thousands of clients the reality is no one user would likely access more than N clients a day for normal work purposes, the number depending on the role of the user. Armed with that knowledge you can limit the access per day to a maximum number, should it be reached it can be reported, investigated and dealt with. Ray BJ Freeman wrote: > sorry I have not responded till now > Inline: > > Jacques Le Roux sent the following on 12/9/2008 7:37 AM: >> From: "Jacques Le Roux" <[hidden email]> >>> BJ, >>> >>> The client concern is in case a login/pwd couple is used but not by >>> the right person (lost, stolen, etc.). Only biometric security >>> could deal with that I guess. > have to think on this one. > using encrypted USB devices for login works with PGP. > >>> By limiting the number of time a page can be visited in a period of >>> time you don't really prevent using UI to pull out confidential >>> data but you make it so long (years) that it's not usable. It's >>> something used in spam fighting known as tarpitting. It has proven >>> to be very efficient and is now used in the gray list concept wich >>> works great. Anyway for the moment it's the requirement I have >>> BTW I wonder if it should not better block the account and send a >>> message to the admin in such case. He/she would then be able to reset >>> the login/pwd to secure anew the login. > yes use tarpitting works very well. I found it really slows down the > spammers. However if there is a heavy use of tarpitting, you are using > up a lot of threads and memory. > I think blocking the account, and sending a email to the person's > registered email with a link back to the login would validate them. > the link would let them validate the email then another email would send > them their logging information. > CC the Admin would be an option as well. >>> I will put the check in at end of RequestHandler.renderView just after >>> the block where ServerHitBin.countView is used. This would >>> clearly separate this new security aspect. And having it at the >>> framework level is clearly easier : you only have to define a list >>> of pages to constrain by PartyRoles. > have to review code before I comment. >> I had a better idea : to use a preprocessor event. I will though need to >> make a small change to allow to return a specific message from the >> event. I guess it will be the only thing I will commit, except if some >> people are interested in the tarpitting feature. > interested but not knowledgeable enough to understand how it works. >> Jacques >> >>> In the check I will need >>> . PartyRole(s), >>> . The list of pages to constrain access by PartyRoles. I will be an >>> ConstrainViewByRole entity with 2 fields : partyRole viewName >>> (pages are actually views in OFBiz) >>> . Max number of page access allowed, and the period of time for >>> counting the number of page accesses in security.properties >>> . An AccessedPage entity with fields loginId viewAccessed >>> dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) >>> >>> I think it's a feature generic enough to be used in Framework if >>> someone is interested in future (if nothing is defined in >>> security.properties the block would be simply skipped so it's >>> harmful). So if nobody see a problem with that I will implement and >>> commit. Any comments welcome >>> >>> Thanks >>> >>> Jacques >>> |
Re: Discussion: Permissions Checking Enhancement
|
Administrator
|
In reply to this post by Jacques Le Roux
After a discussion with Ray I finally changed my mind and we would like to commit more changes.
It will be an entity with demo data. Nobody will be harmed since we will put large enough values on an example view. Entity name : ConstrainViewByRole, fields : partyRole = a party role viewName = name of view to check for constraint maxHit = number of hit before tarpitting the view for the login maxHitDuration = period of time associated with maxHit (no more than 1000 hits in 3 mins, for instance) tarpitDuration = period of time the login will not be able to acces this view again Example : partyRole = consultant view = confidentialDataView maxHit = 1000 duration = 360 (seconds = 3 mins) tarpitDuration = 360000 (seconds = 100 hours) If a login with consultant role has more than 1000 hits in 6 mins on the confidentialDataView it will be tarpitted for 100 heures I will also commit the BlockingWorker used by the prepocessor event. I have not written it yet but I suppose with at least 2 methods : one to count hits called by the main one which takes the decision and send informations (return status, possible msg) to the Controller (RequestHandler.doRequest) Since nobody objected, I will soon open a Jira issue with a 1st patch version with only the RequestHandler.doRequest changes for now. Thanks Jacques From: "Jacques Le Roux" <[hidden email]> > From: "BJ Freeman" <[hidden email]> >> sorry I have not responded till now >> Inline: > > Thanks for your interest > >> Jacques Le Roux sent the following on 12/9/2008 7:37 AM: >>> From: "Jacques Le Roux" <[hidden email]> >>>> BJ, >>>> >>>> The client concern is in case a login/pwd couple is used but not by >>>> the right person (lost, stolen, etc.). Only biometric security >>>> could deal with that I guess. >> have to think on this one. >> using encrypted USB devices for login works with PGP. > > I did not think about that. Anyway it's not the thing the client is looking for (too much turnover I imagine) > >>>> >>>> By limiting the number of time a page can be visited in a period of >>>> time you don't really prevent using UI to pull out confidential >>>> data but you make it so long (years) that it's not usable. It's >>>> something used in spam fighting known as tarpitting. It has proven >>>> to be very efficient and is now used in the gray list concept wich >>>> works great. Anyway for the moment it's the requirement I have >>>> BTW I wonder if it should not better block the account and send a >>>> message to the admin in such case. He/she would then be able to reset >>>> the login/pwd to secure anew the login. >> yes use tarpitting works very well. I found it really slows down the >> spammers. However if there is a heavy use of tarpitting, you are using >> up a lot of threads and memory. >> I think blocking the account, and sending a email to the person's >> registered email with a link back to the login would validate them. >> the link would let them validate the email then another email would send >> them their logging information. >> CC the Admin would be an option as well. > > Actually we have also to deal with the rare case of an authorised person who reachs the limit. So we will redirect this person to > an explicit screen where will ask him/her to request the admin him/herself. Thieves will be tarpitted, that's all. > >>>> I will put the check in at end of RequestHandler.renderView just after >>>> the block where ServerHitBin.countView is used. This would >>>> clearly separate this new security aspect. And having it at the >>>> framework level is clearly easier : you only have to define a list >>>> of pages to constrain by PartyRoles. >> have to review code before I comment. > > Forget it : obsolete > >>> I had a better idea : to use a preprocessor event. I will though need to >>> make a small change to allow to return a specific message from the >>> event. I guess it will be the only thing I will commit, except if some >>> people are interested in the tarpitting feature. >> interested but not knowledgeable enough to understand how it works. > > Really simple, I will create a Jira with a patch and hopefully a 3 lines explanation. It's much simpler and clean. So much things > are already there, you just have to be patient enough to discover them at the rigth place, the right moment ;o) > > Jacques > >>> Jacques >>> >>>> In the check I will need >>>> . PartyRole(s), >>>> . The list of pages to constrain access by PartyRoles. I will be an >>>> ConstrainViewByRole entity with 2 fields : partyRole viewName >>>> (pages are actually views in OFBiz) >>>> . Max number of page access allowed, and the period of time for >>>> counting the number of page accesses in security.properties >>>> . An AccessedPage entity with fields loginId viewAccessed >>>> dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) >>>> >>>> I think it's a feature generic enough to be used in Framework if >>>> someone is interested in future (if nothing is defined in >>>> security.properties the block would be simply skipped so it's >>>> harmful). So if nobody see a problem with that I will implement and >>>> commit. Any comments welcome >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> From: "BJ Freeman" <[hidden email]> >>>>> 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" <[hidden email]> >>>>>>> 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" <[hidden email]> >>>>>>>> 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 <[hidden email]> >>>>>>>> >>>>>>>>> >>>>>>>>> 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 <[hidden email]> >>>>>>>>>> >>>>>>>>>> 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 <[hidden email]> wrote: >>>>>>>>>>> >>>>>>>>>>> From: Bruno Busco <[hidden email]> >>>>>>>>>>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>>>>>>>>>> To: [hidden email] >>>>>>>>>>>> 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 <[hidden email]> >>>>>>>>>>>> >>>>>>>>>>>> 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 <[hidden email]>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <[hidden email]>: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>> >>>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>>>>> 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" <[hidden email]> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> <[hidden email]>: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >> > |
|
|
Hello, can somebody tell me what is done the timeout is over when I do a runSync("myService") in Java ? Can you give me a message or trace sample ? Thanks a lot. |
Re: Discussion: Permissions Checking Enhancement
|
|
In reply to this post by Jacques Le Roux
Instead of attaching this to a Party RoleType, it would be better to attach it to a SecurityPermission or SecurityGroup. Access to resources like pages and such is governed by permissions in OFBiz, and roles are used for record-level security (like which parties a user can view/edit/etc as opposed to being able to use the view profile screen). -David On Dec 10, 2008, at 3:54 AM, Jacques Le Roux wrote: > After a discussion with Ray I finally changed my mind and we would > like to commit more changes. > > It will be an entity with demo data. Nobody will be harmed since we > will put large enough values on an example view. > > Entity name : > ConstrainViewByRole, fields : > partyRole = a party role > viewName = name of view to check for constraint > maxHit = number of hit before tarpitting the view for the login > maxHitDuration = period of time associated with maxHit (no more than > 1000 hits in 3 mins, for instance) > tarpitDuration = period of time the login will not be able to acces > this view again > > Example : > partyRole = consultant > view = confidentialDataView > maxHit = 1000 > duration = 360 (seconds = 3 mins) > tarpitDuration = 360000 (seconds = 100 hours) > > If a login with consultant role has more than 1000 hits in 6 mins on > the confidentialDataView it will be tarpitted for 100 heures > > I will also commit the BlockingWorker used by the prepocessor event. > I have not written it yet but I suppose with at least 2 methods : > one to count hits called by the main one which takes the decision > and send informations (return status, possible msg) to the > Controller (RequestHandler.doRequest) > > Since nobody objected, I will soon open a Jira issue with a 1st > patch version with only the RequestHandler.doRequest changes for now. > > Thanks > > Jacques > > > From: "Jacques Le Roux" <[hidden email]> >> From: "BJ Freeman" <[hidden email]> >>> sorry I have not responded till now >>> Inline: >> >> Thanks for your interest >> >>> Jacques Le Roux sent the following on 12/9/2008 7:37 AM: >>>> From: "Jacques Le Roux" <[hidden email]> >>>>> BJ, >>>>> >>>>> The client concern is in case a login/pwd couple is used but not >>>>> by >>>>> the right person (lost, stolen, etc.). Only biometric security >>>>> could deal with that I guess. >>> have to think on this one. >>> using encrypted USB devices for login works with PGP. >> >> I did not think about that. Anyway it's not the thing the client is >> looking for (too much turnover I imagine) >> >>>>> >>>>> By limiting the number of time a page can be visited in a period >>>>> of >>>>> time you don't really prevent using UI to pull out confidential >>>>> data but you make it so long (years) that it's not usable. It's >>>>> something used in spam fighting known as tarpitting. It has proven >>>>> to be very efficient and is now used in the gray list concept >>>>> wich >>>>> works great. Anyway for the moment it's the requirement I have >>>>> BTW I wonder if it should not better block the account and send a >>>>> message to the admin in such case. He/she would then be able to >>>>> reset >>>>> the login/pwd to secure anew the login. >>> yes use tarpitting works very well. I found it really slows down the >>> spammers. However if there is a heavy use of tarpitting, you are >>> using >>> up a lot of threads and memory. >>> I think blocking the account, and sending a email to the person's >>> registered email with a link back to the login would validate them. >>> the link would let them validate the email then another email >>> would send >>> them their logging information. >>> CC the Admin would be an option as well. >> >> Actually we have also to deal with the rare case of an authorised >> person who reachs the limit. So we will redirect this person to an >> explicit screen where will ask him/her to request the admin him/ >> herself. Thieves will be tarpitted, that's all. >> >>>>> I will put the check in at end of RequestHandler.renderView just >>>>> after >>>>> the block where ServerHitBin.countView is used. This would >>>>> clearly separate this new security aspect. And having it at the >>>>> framework level is clearly easier : you only have to define a list >>>>> of pages to constrain by PartyRoles. >>> have to review code before I comment. >> >> Forget it : obsolete >> >>>> I had a better idea : to use a preprocessor event. I will though >>>> need to >>>> make a small change to allow to return a specific message from the >>>> event. I guess it will be the only thing I will commit, except if >>>> some >>>> people are interested in the tarpitting feature. >>> interested but not knowledgeable enough to understand how it works. >> >> Really simple, I will create a Jira with a patch and hopefully a 3 >> lines explanation. It's much simpler and clean. So much things are >> already there, you just have to be patient enough to discover them >> at the rigth place, the right moment ;o) >> >> Jacques >> >>>> Jacques >>>> >>>>> In the check I will need >>>>> . PartyRole(s), >>>>> . The list of pages to constrain access by PartyRoles. I will be >>>>> an >>>>> ConstrainViewByRole entity with 2 fields : partyRole viewName >>>>> (pages are actually views in OFBiz) >>>>> . Max number of page access allowed, and the period of time for >>>>> counting the number of page accesses in security.properties >>>>> . An AccessedPage entity with fields loginId viewAccessed >>>>> dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) >>>>> >>>>> I think it's a feature generic enough to be used in Framework if >>>>> someone is interested in future (if nothing is defined in >>>>> security.properties the block would be simply skipped so it's >>>>> harmful). So if nobody see a problem with that I will implement >>>>> and >>>>> commit. Any comments welcome >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> From: "BJ Freeman" <[hidden email]> >>>>>> 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" <[hidden email]> >>>>>>>> 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" <[hidden email]> >>>>>>>>> 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 <[hidden email]> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 <[hidden email]> >>>>>>>>>>> >>>>>>>>>>> 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 <[hidden email]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> From: Bruno Busco <[hidden email]> >>>>>>>>>>>>> Subject: Re: Discussion: Permissions Checking Enhancement >>>>>>>>>>>>> To: [hidden email] >>>>>>>>>>>>> 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 <[hidden email]> >>>>>>>>>>>>> >>>>>>>>>>>>> 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 <[hidden email]>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <[hidden email]>: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>> >>>>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>>>>>> 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" <[hidden email]> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> <[hidden email]>: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> > |
Re: Discussion: Permissions Checking Enhancement
|
Administrator
|
That's what I suggested 1st, But Ray, who is the leader on this project, has another opinion. So I will wait his answer...
I wondered also : but I finally think the name of the field viewName is not ambiguous (can't really be confused with SQL view) For managing this ConstrainViewBy... entity I think about adding a (ConstrainView?) button in Party/Security after "New Security Group" "Cert Issuers" buttons. It will lead to a find/list screen with edit and remove buttons by lines. Edit button leading to and edit screen available also on top of previous screen from a button (classical). Note that if we use ConstrainViewBySecurityGroup we would rather add a (ConstrainView?) button after "Security Groups Permissions" "User Logins" buttons of the "Security Group" sub-menu (when you edit a Security Group) leading also to the screens described above. We need at least 2 other entities : 1) one to count hits on each view for each login monitored (login/view couple actually) . to be able to decide to tarpit a login on a view . in case of blocking, an error reponse view will be used to give directions (ask the admin, etc.) to any user tarpitted by error (values to be adjusted in ConstrainViewBy... entity certainly). . I have still to write a smal change to deal whith the "no-error-response-provided" case to avoid showing the success view (a none view - ie blanck view - will be shown then) 2) another to store logins/views tarpitted . to quickly prevent any new access to tarpitted views . to allow admin to reset them on demand (maybe with an UI, maybe not) 1) We have 2 opposed constraints here : quickly compute hits while being sufficiently accurate. As this will be pre-processed for each monitored login/view couples we need to pre-compute as much as possible. But this is a dynamic system, whe don't have a fixed a period of time to count hit as it's done for ServerHitBin for instance. Fortunately, the maxHitDuration is normaly setted after some kind of tuning/profiling (or maybe intially from application knowledge). So we may choose this value as a revolving period of time to sum hits (beginning the 1st period with the 1st hit). If it proves to be too short (too much false tarpits) it will have to be adjusted, that's all. Another time don't worry, in the OOTB version we will provide sufficently large values on (an only on) an example view. The entity will be AccessedView with fields . accessedViewName . userLoginId . numberOf Hits = number of acces to the view by the login in the last maxHitDuration To avoid an SQL request to know which login/view couples we need to monitor each time we pre-process a request we should have an entity ConstrainViewByUserLogin with fields userLoginId = derived from Roles or Permission Groups viewName = name of view to check for constraint maxHit = number of hit before tarpitting the view for the login maxHitDuration = period of time associated with maxHit tarpitDuration = period of time the login will not be able to acces this view again This entity will be updated on every change in UserLoginSecurityGroup and ConstrainViewByRole (I did not think more yet but maybe could be a view-entity) 2) TarpittedViewLogin with fields . userLoginId . viewName . tarpitReleaseDateTime (0 meaning no tarpit, to allow the admin to free a login/view) For those interested, I have opened a Jira issue https://issues.apache.org/jira/browse/OFBIZ-2074, not much in it yet, will be completed progressively while discussing on this ML. Sorry for the long post, thanks Jacques From: "David E Jones" <[hidden email]> > > Instead of attaching this to a Party RoleType, it would be better to attach it to a SecurityPermission or SecurityGroup. Access > to resources like pages and such is governed by permissions in OFBiz, and roles are used for record-level security (like which > parties a user can view/edit/etc as opposed to being able to use the view profile screen). > > -David > > > On Dec 10, 2008, at 3:54 AM, Jacques Le Roux wrote: > >> After a discussion with Ray I finally changed my mind and we would like to commit more changes. >> >> It will be an entity with demo data. Nobody will be harmed since we will put large enough values on an example view. >> >> Entity name : >> ConstrainViewByRole, fields : >> partyRole = a party role >> viewName = name of view to check for constraint >> maxHit = number of hit before tarpitting the view for the login >> maxHitDuration = period of time associated with maxHit (no more than 1000 hits in 3 mins, for instance) >> tarpitDuration = period of time the login will not be able to acces this view again >> >> Example : >> partyRole = consultant >> view = confidentialDataView >> maxHit = 1000 >> duration = 360 (seconds = 3 mins) >> tarpitDuration = 360000 (seconds = 100 hours) >> >> If a login with consultant role has more than 1000 hits in 6 mins on the confidentialDataView it will be tarpitted for 100 >> heures >> >> I will also commit the BlockingWorker used by the prepocessor event. I have not written it yet but I suppose with at least 2 >> methods : one to count hits called by the main one which takes the decision and send informations (return status, possible msg) >> to the Controller (RequestHandler.doRequest) >> >> Since nobody objected, I will soon open a Jira issue with a 1st patch version with only the RequestHandler.doRequest changes for >> now. >> >> Thanks >> >> Jacques |
Re: detecting timeout in service
|
Administrator
|
In reply to this post by Fabien JALABERT
Please Fabien, remember this kind of question should be on user ML (you will not get much answers here)
From: "Fabien JALABERT" <[hidden email]> > > Hello, > > can somebody tell me what is done the timeout is over when I do a runSync("myService") in Java ? Can you give me a message or > trace sample ? Not sure to well understand the question. But I guess the answer is : unless you use use-transaction="false" and there is not alredy a running transaction, each service is done in a transaction and in such case (time-out) the surrounding transaction is simply rolled back Note that you can specify a transaction-timeout in seconds (defaults to 60) but it only works when a new transaction is started. By default, you can have a new transaction if there is not already a running transaction (in this case the service engine create a new transation for you by default, unless you use use-transaction="false") or if you set require-new-transaction to true. In latter case the new transaction can be embedded in an existing transaction. A roll-back on the new transaction will also roll-back the surrounding transaction or all (2 transactions) is commited, if it's ok. HTH Jacques > Thanks a lot. > > > > |
|
|
In reply to this post by David E Jones-3
It came about from a requirement driven around roles so that was the
suggested limiter. The example would be someone with a role of "Sales Rep" who works in house answering calls, processing paperwork might easily deal with 200 a day where as someone operating as "Sales Consultant" in the field visiting clients personally might only deal with 20 a day. They both have security to access the same client view but the user request was to limit them with a differing number of allowed accesses based on their roles. If that needs to be translated in to security groups for implementation to fit in with OFBiz practices then fine, I'm not struck to it being roles. This was thought to be a generally useful feature others might be interested in hence we are trying to make it compatible for the community. Ray David E Jones wrote: > > Instead of attaching this to a Party RoleType, it would be better to > attach it to a SecurityPermission or SecurityGroup. Access to resources > like pages and such is governed by permissions in OFBiz, and roles are > used for record-level security (like which parties a user can > view/edit/etc as opposed to being able to use the view profile screen). > > -David > > |
Grey list in OFBiz [was Re: Discussion: Permissions Checking Enhancement]
|
Administrator
|
In reply to this post by Jacques Le Roux
I think the phrase "grey list" is easier to speak about this functionnality and easier to understand and remember. So I propose to
use it rather than the tarpit word when speaking about this at large (I will change Entities names, fields, etc. accordinlgly when appropriate) As we use a prepocessor, to avoid any bad surprise later, I propose we introduce in site-conf.xsd an attribute allowGrayList in request-map element. It would work like track-visit and track-serverhit being true by default (though I wonder if we should not do reverse to false). Jacques |
Re: Discussion: Permissions Checking Enhancement
|
Administrator
|
In reply to this post by Ray-91
Maybe we could use "Security Roles" and not "Role limited permissions" inside Security Groups for more flexibility ?
Définitions are in http://docs.ofbiz.org/display/OFBTECH/OFBiz+security I will use that for now because I need something to move forward Jacques From: "Ray" <[hidden email]> > It came about from a requirement driven around roles so that was the > suggested limiter. The example would be someone with a role of "Sales > Rep" who works in house answering calls, processing paperwork might > easily deal with 200 a day where as someone operating as "Sales > Consultant" in the field visiting clients personally might only deal > with 20 a day. > > They both have security to access the same client view but the user > request was to limit them with a differing number of allowed accesses > based on their roles. > > If that needs to be translated in to security groups for implementation > to fit in with OFBiz practices then fine, I'm not struck to it being > roles. This was thought to be a generally useful feature others might be > interested in hence we are trying to make it compatible for the community. > > Ray > > > David E Jones wrote: >> >> Instead of attaching this to a Party RoleType, it would be better to >> attach it to a SecurityPermission or SecurityGroup. Access to resources >> like pages and such is governed by permissions in OFBiz, and roles are >> used for record-level security (like which parties a user can >> view/edit/etc as opposed to being able to use the view profile screen). >> >> -David >> >> > |
Re: Discussion: Permissions Checking Enhancement
|
|
In reply to this post by Ray-91
The word "role" in the context of an organization doesn't necessarily translate into a RoleType and PartyRole in OFBiz... or in other words the work "role" is used for various different meanings. In OFBiz we try to distinguish between a PartyRole that is used to describe how a Party relates to other things in the system, and a SecurityGroup which defines which users have which permissions. The concept of a SecurityGroup was separated from the Party/RoleType/ PartyRole stuff for a few reasons. One of them was to have a framework level security model that is separate the business level elements in the base applications, including the party stuff. In general framework components are not allowed to have a dependency on applications components, and the webapp tools are in the framework and RoleType/ PartyRole in applications. Backing up a bit, the client using the word "role" is part of a requirement and a design needs to be created based on that requirement. From the bit of this that I've read the closest concept in OFBiz to this is actually SecurityGroup and NOT RoleType. -David On Dec 11, 2008, at 8:44 AM, Ray wrote: > It came about from a requirement driven around roles so that was the > suggested limiter. The example would be someone with a role of "Sales > Rep" who works in house answering calls, processing paperwork might > easily deal with 200 a day where as someone operating as "Sales > Consultant" in the field visiting clients personally might only deal > with 20 a day. > > They both have security to access the same client view but the user > request was to limit them with a differing number of allowed accesses > based on their roles. > > If that needs to be translated in to security groups for > implementation > to fit in with OFBiz practices then fine, I'm not struck to it being > roles. This was thought to be a generally useful feature others > might be > interested in hence we are trying to make it compatible for the > community. > > Ray > > > David E Jones wrote: >> >> Instead of attaching this to a Party RoleType, it would be better to >> attach it to a SecurityPermission or SecurityGroup. Access to >> resources >> like pages and such is governed by permissions in OFBiz, and roles >> are >> used for record-level security (like which parties a user can >> view/edit/etc as opposed to being able to use the view profile >> screen). >> >> -David >> >> |
Re: Discussion: Permissions Checking Enhancement
|
|
To expand on what David said a little, you could have a SecurityGroup
called "SALES_REP" and another one called "SALES_CONSULTANT" - and apply the necessary permissions to each group. That's how I set up network permissions where I work - I create security groups that are based on employee roles. I assign the necessary permissions to the security group, and then assign the security group to the appropriate employees. -Adrian David E Jones wrote: > > The word "role" in the context of an organization doesn't necessarily > translate into a RoleType and PartyRole in OFBiz... or in other words > the work "role" is used for various different meanings. In OFBiz we try > to distinguish between a PartyRole that is used to describe how a Party > relates to other things in the system, and a SecurityGroup which defines > which users have which permissions. > > The concept of a SecurityGroup was separated from the > Party/RoleType/PartyRole stuff for a few reasons. One of them was to > have a framework level security model that is separate the business > level elements in the base applications, including the party stuff. In > general framework components are not allowed to have a dependency on > applications components, and the webapp tools are in the framework and > RoleType/PartyRole in applications. > > Backing up a bit, the client using the word "role" is part of a > requirement and a design needs to be created based on that requirement. > From the bit of this that I've read the closest concept in OFBiz to > this is actually SecurityGroup and NOT RoleType. > > -David > > > On Dec 11, 2008, at 8:44 AM, Ray wrote: > >> It came about from a requirement driven around roles so that was the >> suggested limiter. The example would be someone with a role of "Sales >> Rep" who works in house answering calls, processing paperwork might >> easily deal with 200 a day where as someone operating as "Sales >> Consultant" in the field visiting clients personally might only deal >> with 20 a day. >> >> They both have security to access the same client view but the user >> request was to limit them with a differing number of allowed accesses >> based on their roles. >> >> If that needs to be translated in to security groups for implementation >> to fit in with OFBiz practices then fine, I'm not struck to it being >> roles. This was thought to be a generally useful feature others might be >> interested in hence we are trying to make it compatible for the >> community. >> >> Ray >> >> >> David E Jones wrote: >>> >>> Instead of attaching this to a Party RoleType, it would be better to >>> attach it to a SecurityPermission or SecurityGroup. Access to resources >>> like pages and such is governed by permissions in OFBiz, and roles are >>> used for record-level security (like which parties a user can >>> view/edit/etc as opposed to being able to use the view profile screen). >>> >>> -David >>> >>> > > |
Re: Discussion: Permissions Checking Enhancement
|
Administrator
|
In reply to this post by David E Jones-3
If we agree on using Security Roles in SecurityGroup, as proposed earlier I will put UIs depending on a chosen Security Group (after
Security Groups Permissions User Logins button-bar) Jacques From: "David E Jones" <[hidden email]> > > The word "role" in the context of an organization doesn't necessarily translate into a RoleType and PartyRole in OFBiz... or in > other words the work "role" is used for various different meanings. In OFBiz we try to distinguish between a PartyRole that is > used to describe how a Party relates to other things in the system, and a SecurityGroup which defines which users have which > permissions. > > The concept of a SecurityGroup was separated from the Party/RoleType/ PartyRole stuff for a few reasons. One of them was to have a > framework level security model that is separate the business level elements in the base applications, including the party stuff. > In general framework components are not allowed to have a dependency on applications components, and the webapp tools are in the > framework and RoleType/ PartyRole in applications. > > Backing up a bit, the client using the word "role" is part of a requirement and a design needs to be created based on that > requirement. From the bit of this that I've read the closest concept in OFBiz to this is actually SecurityGroup and NOT RoleType. > > -David > > > On Dec 11, 2008, at 8:44 AM, Ray wrote: > >> It came about from a requirement driven around roles so that was the >> suggested limiter. The example would be someone with a role of "Sales >> Rep" who works in house answering calls, processing paperwork might >> easily deal with 200 a day where as someone operating as "Sales >> Consultant" in the field visiting clients personally might only deal >> with 20 a day. >> >> They both have security to access the same client view but the user >> request was to limit them with a differing number of allowed accesses >> based on their roles. >> >> If that needs to be translated in to security groups for implementation >> to fit in with OFBiz practices then fine, I'm not struck to it being >> roles. This was thought to be a generally useful feature others might be >> interested in hence we are trying to make it compatible for the community. >> >> Ray >> >> >> David E Jones wrote: >>> >>> Instead of attaching this to a Party RoleType, it would be better to >>> attach it to a SecurityPermission or SecurityGroup. Access to resources >>> like pages and such is governed by permissions in OFBiz, and roles are >>> used for record-level security (like which parties a user can >>> view/edit/etc as opposed to being able to use the view profile screen). >>> >>> -David >>> >>> > |
Re: Discussion: Permissions Checking Enhancement
|
Administrator
|
In reply to this post by Adrian Crum
I think all this is pretty well explained in http://docs.ofbiz.org/display/OFBTECH/OFBiz+security :o)
Else please amend Jacques From: "Adrian Crum" <[hidden email]> > To expand on what David said a little, you could have a SecurityGroup > called "SALES_REP" and another one called "SALES_CONSULTANT" - and apply > the necessary permissions to each group. > > That's how I set up network permissions where I work - I create security > groups that are based on employee roles. I assign the necessary > permissions to the security group, and then assign the security group to > the appropriate employees. > > -Adrian > > David E Jones wrote: >> >> The word "role" in the context of an organization doesn't necessarily >> translate into a RoleType and PartyRole in OFBiz... or in other words >> the work "role" is used for various different meanings. In OFBiz we try >> to distinguish between a PartyRole that is used to describe how a Party >> relates to other things in the system, and a SecurityGroup which defines >> which users have which permissions. >> >> The concept of a SecurityGroup was separated from the >> Party/RoleType/PartyRole stuff for a few reasons. One of them was to >> have a framework level security model that is separate the business >> level elements in the base applications, including the party stuff. In >> general framework components are not allowed to have a dependency on >> applications components, and the webapp tools are in the framework and >> RoleType/PartyRole in applications. >> >> Backing up a bit, the client using the word "role" is part of a >> requirement and a design needs to be created based on that requirement. >> From the bit of this that I've read the closest concept in OFBiz to >> this is actually SecurityGroup and NOT RoleType. >> >> -David >> >> >> On Dec 11, 2008, at 8:44 AM, Ray wrote: >> >>> It came about from a requirement driven around roles so that was the >>> suggested limiter. The example would be someone with a role of "Sales >>> Rep" who works in house answering calls, processing paperwork might >>> easily deal with 200 a day where as someone operating as "Sales >>> Consultant" in the field visiting clients personally might only deal >>> with 20 a day. >>> >>> They both have security to access the same client view but the user >>> request was to limit them with a differing number of allowed accesses >>> based on their roles. >>> >>> If that needs to be translated in to security groups for implementation >>> to fit in with OFBiz practices then fine, I'm not struck to it being >>> roles. This was thought to be a generally useful feature others might be >>> interested in hence we are trying to make it compatible for the >>> community. >>> >>> Ray >>> >>> >>> David E Jones wrote: >>>> >>>> Instead of attaching this to a Party RoleType, it would be better to >>>> attach it to a SecurityPermission or SecurityGroup. Access to resources >>>> like pages and such is governed by permissions in OFBiz, and roles are >>>> used for record-level security (like which parties a user can >>>> view/edit/etc as opposed to being able to use the view profile screen). >>>> >>>> -David >>>> >>>> >> >> > |
Re: Grey list in OFBiz [was Re: Discussion: Permissions Checking Enhancement]
|
|
In reply to this post by Jacques Le Roux
Maybe we should also decide on whether it is spelled "grey" or "gray." ;-)
-Adrian Jacques Le Roux wrote: > I think the phrase "grey list" is easier to speak about this > functionnality and easier to understand and remember. So I propose to > use it rather than the tarpit word when speaking about this at large (I > will change Entities names, fields, etc. accordinlgly when appropriate) > > As we use a prepocessor, to avoid any bad surprise later, I propose we > introduce in site-conf.xsd an attribute allowGrayList in > request-map element. It would work like track-visit and track-serverhit > being true by default (though I wonder if we should not do > reverse to false). > > Jacques > > |
Re: Grey list in OFBiz [was Re: Discussion: Permissions Checking Enhancement]
|
|
Adrian Crum wrote:
> Maybe we should also decide on whether it is spelled "grey" or "gray." ;-) Or how about a red-black list? |
Re: Discussion: Permissions Checking Enhancement
|
|
In reply to this post by Jacques Le Roux
What is a "Security Role"? In that page (the "OFBiz security" page) the stuff mentioned about the role-limited permissions is incorrect. The purpose of role-limited permissions is to tie a SecurityPermission to record level security using the RoleType/PartyRole and related entities. In OFBiz this is how record level permissions are done, ie somehow the user (through their Party record) is associated with another record in the database, and that specific relationship must exist in order for the role-limited permission to take effect. -David On Dec 11, 2008, at 12:27 PM, Jacques Le Roux wrote: > Maybe we could use "Security Roles" and not "Role limited > permissions" inside Security Groups for more flexibility ? > Définitions are in http://docs.ofbiz.org/display/OFBTECH/OFBiz > +security > > I will use that for now because I need something to move forward > > Jacques > > From: "Ray" <[hidden email]> >> It came about from a requirement driven around roles so that was the >> suggested limiter. The example would be someone with a role of "Sales >> Rep" who works in house answering calls, processing paperwork might >> easily deal with 200 a day where as someone operating as "Sales >> Consultant" in the field visiting clients personally might only deal >> with 20 a day. >> >> They both have security to access the same client view but the user >> request was to limit them with a differing number of allowed accesses >> based on their roles. >> >> If that needs to be translated in to security groups for >> implementation >> to fit in with OFBiz practices then fine, I'm not struck to it being >> roles. This was thought to be a generally useful feature others >> might be >> interested in hence we are trying to make it compatible for the >> community. >> >> Ray >> >> >> David E Jones wrote: >>> >>> Instead of attaching this to a Party RoleType, it would be better to >>> attach it to a SecurityPermission or SecurityGroup. Access to >>> resources >>> like pages and such is governed by permissions in OFBiz, and roles >>> are >>> used for record-level security (like which parties a user can >>> view/edit/etc as opposed to being able to use the view profile >>> screen). >>> >>> -David >>> >>> >> > |
Re: Grey list in OFBiz [was Re: Discussion: Permissions Checking Enhancement]
|
Administrator
|
In reply to this post by Adrian Crum
From: "Adrian Crum" <[hidden email]>
> Maybe we should also decide on whether it is spelled "grey" or "gray." ;-) I fight hard to write correctly grey but as with prodcut most of the time I failed and write gray (here I must say I"m not a Dyslexic). For prodcut I don't know why (though I suspect our hands to be used to the word cut) but have a look at http://www.nabble.com/forum/Search.jtp?local=y&forum=2740&query=prodcut : I'm not the only one :D For gray may be I'm influenced by Scott's name ? Jacques > -Adrian > > Jacques Le Roux wrote: >> I think the phrase "grey list" is easier to speak about this functionnality and easier to understand and remember. So I propose >> to >> use it rather than the tarpit word when speaking about this at large (I will change Entities names, fields, etc. accordinlgly >> when appropriate) >> >> As we use a prepocessor, to avoid any bad surprise later, I propose we introduce in site-conf.xsd an attribute allowGrayList in >> request-map element. It would work like track-visit and track-serverhit being true by default (though I wonder if we should not >> do >> reverse to false). >> >> Jacques >> >> > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |