Custom Security / Permissions
Locked
12
12
Re: Custom Security / Permissions
 
|
Re: Custom Security / Permissions
|
|
In reply to this post by Adrian Crum
Yes Adrian I agree...
I am thinking about the same types of processes. The createParty service for example is useless unless used with other services, createPerson or createPartyGroup. When creating these, its nice to say if the user has PARTYMGR_CREATE permission then all is good. However... I don't want to give users permission to just a person all the time. I want to createContact, this would create a person/party group, roles, and associate them w/ my account. If createPerson REQUIRED the low level permissions then it would make this impossible... Maybe the logic should be as follows: 1) Keep CRUD service level permissions (base permissions as is today) 2) Move all checking to the service invocation level (out of the implementation) 3) Inherit permissions from previous services: Example: Service A - createPerson - requires PARTYMGR_CREATE permission (defined in the service def) Service B - createContact - request custom permission scheme (defined in the service def) Service B invokes Service A, and bypasses its base security since the permission passed for Service B. This would still allow CRuD services to be called directly and used as they are today, but also give us the flexibility to bypass them as needed through new service definitions (groups/ecas). That said, ECAs would follow the same pattern. The action service permission checking would not be invoked (ever), same with service groups... Does this solve all problems? Andrew On Jan 9, 2007, at 3:06 PM, Adrian Crum wrote: > Yeah, there are two things I brought up in response to Andy's > original email and the discussion has become a mixture of the two. > Maybe we should start another thread to make a clearer distinction. > > My two orignal proposals: > > 1. Centralize security maintenance/checking code so that an > alternate security "back-end" can be "plugged in." This has nothing > to do with Andy's original proposal. I mentioned it because I was > thinking he could consider it while mucking around in the security > stuff. > > 2. Extend or modify the current permissions implementation to make > it more flexible. This was more along the lines of what Andy first > mentioned. I'd like to see permissions assigned in a little more > organized and consistent way. As has been pointed out, this would > be a major work. > > Now Andy is proposing a two-tiered service structure that would > address something that has bothered me for a while. For that I can > give an example: > > I developed role-oriented party data-entry screens. Instead of one > application to maintain parties in all roles (Party Manager) I have > a Customer maintenance screen, a Supplier maintenance screen, a > Dealer maintenance screen, etc. A user's role in the company > determines which screens they can use. > > To keep development to a minimum, I called OFBiz's party java > methods directly to perform the create/update/delete tasks. Problem > was, the java methods had permissions checking built into them. To > me, that seemed redundant because the service engine or UI had > already checked permissions. > > I ended up disabling the permissions checking in the java methods. > It didn't become a security issue because none of the OOTB screens > were being used anyway. > > Maybe OFBiz has changed some of that recently - hence your > confusion. But in the past it has been a major pain in the butt. > > From my perspective it would be cool if all service calls were > organized like this: > > Invoke service > Permissions/parameter checking layer > Perform desired action layer (permissions ignorant) > > > > David E Jones wrote: >> On Jan 9, 2007, at 12:20 PM, Adrian Crum wrote: >>> Andrew Zeneski wrote: >>> >>>> CRUD services probably will not have permissions assigned, and >>>> NEVER called directly from requests. Maybe we add a flag to >>>> these definitions to prevent them from being called directly >>>> through an event handler. Special purpose services will be >>>> implemented (which call the CRUD services) to perform >>>> functions (i.e. create party, create order, etc). These >>>> services will have permissions set and often custom permission >>>> services to check if the user can perform the operations. >>> >>> >>> That would rock! I've always been frustrated by permissions >>> checking in the lower level stuff. It would be great if there was >>> a pattern followed where anytime the lower level services are >>> used, they assume that permissions were checked somewhere higher. >>> >>> That's the pattern I used in https://issues.apache.org/jira/ >>> browse/ OFBIZ-495. >> This is interesting, but does it mean that for all CrUD service >> definitions that are now being called directly will have to be >> duplicated to create services with permissions? Right now the >> current patterns involve quite a bit of this. Does this mean we'd >> have alternate service definitions for each page where the lower >> level service implementation is used? >> Are the different permission requirements really that >> conflicting? Based on the real-world scenarios I've been through >> so far using the pattern of general and role limited, or even >> multiple varieties of role limited, permissions is a fine way to >> go, and can be done "centrally" in the lower level services so >> nothing gets through accidentally. >> I'm not quite sure where this is going, so perhaps it would be >> good to step back and start putting together some more general >> requirements and example scenarios. Given the fairly substantial >> current functionality and the amount of work that will be >> required regardless of what we choose it would be really great to >> get something good on this pass. >> Part of the reason I'm bringing this up is that I'm seeing some >> "requirements" that are conflicted, for example: >> 1. have a central place to easily manage permissions and things >> security in general >> 2. have no security (or at least permission) checking on lower >> level (CrUD) services, and instead have each higher level service >> handle the permissions >> -David |
smime.p7s (3K)
Re: Custom Security / Permissions
|
|
Re: Custom Security / Permissions
|
|
In reply to this post by Adrian Crum
Adrian,
Where do you see the need for an Object? So far what I have heard is service based authentication and permissions will cover everything, if you see otherwise please describe. Andrew On Jan 9, 2007, at 3:11 PM, Adrian Crum wrote: > Andrew Zeneski wrote: >> There are two main areas for permissions: >> 1) Invocation - Does the user have permission to invoke this service >> 2) View - Does the user have permission to view this page. >> I think what we are proposing takes care of #1, the screen widget >> can be modified to call into these service based permissions as >> well to take care of #2. > > The object permissions idea I proposed would extend #2 to control > what data elements on the page the user can view. > > |
Re: Custom Security / Permissions
|
|
In reply to this post by Adrian Crum
Do you foresee this causing new problems? :)
On Jan 9, 2007, at 3:24 PM, Adrian Crum wrote: > It certainly solves the one I described! Thanks Andy! > > Andrew Zeneski wrote: > >> Yes Adrian I agree... >> I am thinking about the same types of processes. The createParty >> service for example is useless unless used with other services, >> createPerson or createPartyGroup. When creating these, its nice >> to say if the user has PARTYMGR_CREATE permission then all is >> good. However... >> I don't want to give users permission to just a person all the >> time. I want to createContact, this would create a person/party >> group, roles, and associate them w/ my account. If createPerson >> REQUIRED the low level permissions then it would make this >> impossible... >> Maybe the logic should be as follows: >> 1) Keep CRUD service level permissions (base permissions as is today) >> 2) Move all checking to the service invocation level (out of the >> implementation) >> 3) Inherit permissions from previous services: >> Example: >> Service A - createPerson - requires PARTYMGR_CREATE permission >> (defined in the service def) >> Service B - createContact - request custom permission scheme >> (defined in the service def) >> Service B invokes Service A, and bypasses its base security since >> the permission passed for Service B. >> This would still allow CRuD services to be called directly and >> used as they are today, but also give us the flexibility to >> bypass them as needed through new service definitions (groups/ecas). >> That said, ECAs would follow the same pattern. The action service >> permission checking would not be invoked (ever), same with >> service groups... >> Does this solve all problems? >> Andrew >> On Jan 9, 2007, at 3:06 PM, Adrian Crum wrote: >>> Yeah, there are two things I brought up in response to Andy's >>> original email and the discussion has become a mixture of the >>> two. Maybe we should start another thread to make a clearer >>> distinction. >>> >>> My two orignal proposals: >>> >>> 1. Centralize security maintenance/checking code so that an >>> alternate security "back-end" can be "plugged in." This has >>> nothing to do with Andy's original proposal. I mentioned it >>> because I was thinking he could consider it while mucking around >>> in the security stuff. >>> >>> 2. Extend or modify the current permissions implementation to >>> make it more flexible. This was more along the lines of what >>> Andy first mentioned. I'd like to see permissions assigned in a >>> little more organized and consistent way. As has been pointed >>> out, this would be a major work. >>> >>> Now Andy is proposing a two-tiered service structure that would >>> address something that has bothered me for a while. For that I >>> can give an example: >>> >>> I developed role-oriented party data-entry screens. Instead of >>> one application to maintain parties in all roles (Party Manager) >>> I have a Customer maintenance screen, a Supplier maintenance >>> screen, a Dealer maintenance screen, etc. A user's role in the >>> company determines which screens they can use. >>> >>> To keep development to a minimum, I called OFBiz's party java >>> methods directly to perform the create/update/delete tasks. >>> Problem was, the java methods had permissions checking built >>> into them. To me, that seemed redundant because the service >>> engine or UI had already checked permissions. >>> >>> I ended up disabling the permissions checking in the java >>> methods. It didn't become a security issue because none of the >>> OOTB screens were being used anyway. >>> >>> Maybe OFBiz has changed some of that recently - hence your >>> confusion. But in the past it has been a major pain in the butt. >>> >>> From my perspective it would be cool if all service calls were >>> organized like this: >>> >>> Invoke service >>> Permissions/parameter checking layer >>> Perform desired action layer (permissions ignorant) >>> >>> >>> >>> David E Jones wrote: >>> >>>> On Jan 9, 2007, at 12:20 PM, Adrian Crum wrote: >>>> >>>>> Andrew Zeneski wrote: >>>>> >>>>>> CRUD services probably will not have permissions assigned, >>>>>> and NEVER called directly from requests. Maybe we add a >>>>>> flag to these definitions to prevent them from being called >>>>>> directly through an event handler. Special purpose services >>>>>> will be implemented (which call the CRUD services) to >>>>>> perform functions (i.e. create party, create order, etc). >>>>>> These services will have permissions set and often custom >>>>>> permission services to check if the user can perform the >>>>>> operations. >>>>> >>>>> >>>>> >>>>> That would rock! I've always been frustrated by permissions >>>>> checking in the lower level stuff. It would be great if there >>>>> was a pattern followed where anytime the lower level services >>>>> are used, they assume that permissions were checked somewhere >>>>> higher. >>>>> >>>>> That's the pattern I used in https://issues.apache.org/jira/ >>>>> browse/ OFBIZ-495. >>>> >>>> This is interesting, but does it mean that for all CrUD >>>> service definitions that are now being called directly will >>>> have to be duplicated to create services with permissions? >>>> Right now the current patterns involve quite a bit of this. >>>> Does this mean we'd have alternate service definitions for >>>> each page where the lower level service implementation is used? >>>> Are the different permission requirements really that >>>> conflicting? Based on the real-world scenarios I've been >>>> through so far using the pattern of general and role limited, >>>> or even multiple varieties of role limited, permissions is a >>>> fine way to go, and can be done "centrally" in the lower level >>>> services so nothing gets through accidentally. >>>> I'm not quite sure where this is going, so perhaps it would be >>>> good to step back and start putting together some more >>>> general requirements and example scenarios. Given the fairly >>>> substantial current functionality and the amount of work that >>>> will be required regardless of what we choose it would be >>>> really great to get something good on this pass. >>>> Part of the reason I'm bringing this up is that I'm seeing >>>> some "requirements" that are conflicted, for example: >>>> 1. have a central place to easily manage permissions and >>>> things security in general >>>> 2. have no security (or at least permission) checking on lower >>>> level (CrUD) services, and instead have each higher level >>>> service handle the permissions >>>> -David |
Re: Custom Security / Permissions
|
|
In reply to this post by Andrew Zeneski
Maybe adding:
<condition-permission ... To the service ECAs to trigger events based on permission would add an additional layer of security when triggering events. If we go with the bypass route, this may be necessary. Andrew On Jan 9, 2007, at 3:17 PM, Andrew Zeneski wrote: > Yes Adrian I agree... > > I am thinking about the same types of processes. The createParty > service for example is useless unless used with other services, > createPerson or createPartyGroup. When creating these, its nice to > say if the user has PARTYMGR_CREATE permission then all is good. > However... > > I don't want to give users permission to just a person all the > time. I want to createContact, this would create a person/party > group, roles, and associate them w/ my account. If createPerson > REQUIRED the low level permissions then it would make this > impossible... > > Maybe the logic should be as follows: > > 1) Keep CRUD service level permissions (base permissions as is today) > 2) Move all checking to the service invocation level (out of the > implementation) > 3) Inherit permissions from previous services: > Example: > > Service A - createPerson - requires PARTYMGR_CREATE permission > (defined in the service def) > Service B - createContact - request custom permission scheme > (defined in the service def) > Service B invokes Service A, and bypasses its base security since > the permission passed for Service B. > > This would still allow CRuD services to be called directly and used > as they are today, but also give us the flexibility to bypass them > as needed through new service definitions (groups/ecas). > > That said, ECAs would follow the same pattern. The action service > permission checking would not be invoked (ever), same with service > groups... > > Does this solve all problems? > > Andrew > > On Jan 9, 2007, at 3:06 PM, Adrian Crum wrote: > >> Yeah, there are two things I brought up in response to Andy's >> original email and the discussion has become a mixture of the two. >> Maybe we should start another thread to make a clearer distinction. >> >> My two orignal proposals: >> >> 1. Centralize security maintenance/checking code so that an >> alternate security "back-end" can be "plugged in." This has >> nothing to do with Andy's original proposal. I mentioned it >> because I was thinking he could consider it while mucking around >> in the security stuff. >> >> 2. Extend or modify the current permissions implementation to make >> it more flexible. This was more along the lines of what Andy first >> mentioned. I'd like to see permissions assigned in a little more >> organized and consistent way. As has been pointed out, this would >> be a major work. >> >> Now Andy is proposing a two-tiered service structure that would >> address something that has bothered me for a while. For that I can >> give an example: >> >> I developed role-oriented party data-entry screens. Instead of one >> application to maintain parties in all roles (Party Manager) I >> have a Customer maintenance screen, a Supplier maintenance screen, >> a Dealer maintenance screen, etc. A user's role in the company >> determines which screens they can use. >> >> To keep development to a minimum, I called OFBiz's party java >> methods directly to perform the create/update/delete tasks. >> Problem was, the java methods had permissions checking built into >> them. To me, that seemed redundant because the service engine or >> UI had already checked permissions. >> >> I ended up disabling the permissions checking in the java methods. >> It didn't become a security issue because none of the OOTB screens >> were being used anyway. >> >> Maybe OFBiz has changed some of that recently - hence your >> confusion. But in the past it has been a major pain in the butt. >> >> From my perspective it would be cool if all service calls were >> organized like this: >> >> Invoke service >> Permissions/parameter checking layer >> Perform desired action layer (permissions ignorant) >> >> >> >> David E Jones wrote: >>> On Jan 9, 2007, at 12:20 PM, Adrian Crum wrote: >>>> Andrew Zeneski wrote: >>>> >>>>> CRUD services probably will not have permissions assigned, and >>>>> NEVER called directly from requests. Maybe we add a flag to >>>>> these definitions to prevent them from being called directly >>>>> through an event handler. Special purpose services will be >>>>> implemented (which call the CRUD services) to perform >>>>> functions (i.e. create party, create order, etc). These >>>>> services will have permissions set and often custom >>>>> permission services to check if the user can perform the >>>>> operations. >>>> >>>> >>>> That would rock! I've always been frustrated by permissions >>>> checking in the lower level stuff. It would be great if there >>>> was a pattern followed where anytime the lower level services >>>> are used, they assume that permissions were checked somewhere >>>> higher. >>>> >>>> That's the pattern I used in https://issues.apache.org/jira/ >>>> browse/ OFBIZ-495. >>> This is interesting, but does it mean that for all CrUD service >>> definitions that are now being called directly will have to be >>> duplicated to create services with permissions? Right now the >>> current patterns involve quite a bit of this. Does this mean >>> we'd have alternate service definitions for each page where the >>> lower level service implementation is used? >>> Are the different permission requirements really that >>> conflicting? Based on the real-world scenarios I've been through >>> so far using the pattern of general and role limited, or even >>> multiple varieties of role limited, permissions is a fine way to >>> go, and can be done "centrally" in the lower level services so >>> nothing gets through accidentally. >>> I'm not quite sure where this is going, so perhaps it would be >>> good to step back and start putting together some more general >>> requirements and example scenarios. Given the fairly substantial >>> current functionality and the amount of work that will be >>> required regardless of what we choose it would be really great >>> to get something good on this pass. >>> Part of the reason I'm bringing this up is that I'm seeing some >>> "requirements" that are conflicted, for example: >>> 1. have a central place to easily manage permissions and things >>> security in general >>> 2. have no security (or at least permission) checking on lower >>> level (CrUD) services, and instead have each higher level >>> service handle the permissions >>> -David > |
Re: Custom Security / Permissions
|
|
In reply to this post by Andrew Zeneski
Ummm... to be honest, this scares the _hell_ out of me (and goodness knows there's plenty there to scare out)! What this implies to me is a new service definition for each variation on permissions that might be needed by a stock or custom application. Once you have half a dozen service definitions for a service implementation it will start to take some work to figure out which one to use, and it will greatly increase the risk that you're using the wrong one, that someone might change that one and create a whole in your code, or that user level interactions will accidently hit a code path with no permission checks at all. In other words, this seems like it would be _very_ difficult to manage. Much to much for my poor little head... The whole point of having low-level CrUD services is to have a central place to attach stuff that we always want applied, including ECA rules, security auth and permission checks, and any constraints in general related to the data elements involved. I'd be much more comfortable with the pattern that has been around for years, and that has been mentioned and described dozens of times in the mailing lists and other places, namely the general and role- limited permissions pattern. The idea is that the permission checking code would allow multiple permission paths for the user to access the service (or screen or whatever). Some permissions, like most (but not all!) of the current permissions in OOTB OFBiz, are general permissions that mean you can perform the operation on any related record. Other permissions, the "role limited" ones, allow for alternate scenarios and will usually have additional conditions like requiring the logged in user's party to be related to an existing record, or on create allow it but then associate it with the user in a particular way. This is super-important. I don't think we can really discuss permission management without understanding this well at least from a historical perspective, and I have yet to see any requirements that don't fit right into this pattern. That includes what Adrian described for his application, because even though I have no idea what his custom security code looks like, I know that the custom code could be associated with a role-limited permission just for it, and then live happily along with other permissions for a given service or screen or whatever. A good example of existing code for this is the ProductServices.xml#checkProductRelatedPermission simple-method (starts on line 483 in the current revision of the file). Right now it is called from each simple-method, but it should probably be wrapped with a service definition and called as a service through the service definition as a pre-condition. To facilitate discussion I beg on bended knee that everyone read over this, even if you think you know about what is in there! I find it an extremely helpful to remind me of certain nuances related to this. It may not be perfect code, but it's pretty good. -David On Jan 9, 2007, at 1:17 PM, Andrew Zeneski wrote: > Yes Adrian I agree... > > I am thinking about the same types of processes. The createParty > service for example is useless unless used with other services, > createPerson or createPartyGroup. When creating these, its nice to > say if the user has PARTYMGR_CREATE permission then all is good. > However... > > I don't want to give users permission to just a person all the > time. I want to createContact, this would create a person/party > group, roles, and associate them w/ my account. If createPerson > REQUIRED the low level permissions then it would make this > impossible... > > Maybe the logic should be as follows: > > 1) Keep CRUD service level permissions (base permissions as is today) > 2) Move all checking to the service invocation level (out of the > implementation) > 3) Inherit permissions from previous services: > Example: > > Service A - createPerson - requires PARTYMGR_CREATE permission > (defined in the service def) > Service B - createContact - request custom permission scheme > (defined in the service def) > Service B invokes Service A, and bypasses its base security since > the permission passed for Service B. > > This would still allow CRuD services to be called directly and used > as they are today, but also give us the flexibility to bypass them > as needed through new service definitions (groups/ecas). > > That said, ECAs would follow the same pattern. The action service > permission checking would not be invoked (ever), same with service > groups... > > Does this solve all problems? > > Andrew > > On Jan 9, 2007, at 3:06 PM, Adrian Crum wrote: > >> Yeah, there are two things I brought up in response to Andy's >> original email and the discussion has become a mixture of the two. >> Maybe we should start another thread to make a clearer distinction. >> >> My two orignal proposals: >> >> 1. Centralize security maintenance/checking code so that an >> alternate security "back-end" can be "plugged in." This has >> nothing to do with Andy's original proposal. I mentioned it >> because I was thinking he could consider it while mucking around >> in the security stuff. >> >> 2. Extend or modify the current permissions implementation to make >> it more flexible. This was more along the lines of what Andy first >> mentioned. I'd like to see permissions assigned in a little more >> organized and consistent way. As has been pointed out, this would >> be a major work. >> >> Now Andy is proposing a two-tiered service structure that would >> address something that has bothered me for a while. For that I can >> give an example: >> >> I developed role-oriented party data-entry screens. Instead of one >> application to maintain parties in all roles (Party Manager) I >> have a Customer maintenance screen, a Supplier maintenance screen, >> a Dealer maintenance screen, etc. A user's role in the company >> determines which screens they can use. >> >> To keep development to a minimum, I called OFBiz's party java >> methods directly to perform the create/update/delete tasks. >> Problem was, the java methods had permissions checking built into >> them. To me, that seemed redundant because the service engine or >> UI had already checked permissions. >> >> I ended up disabling the permissions checking in the java methods. >> It didn't become a security issue because none of the OOTB screens >> were being used anyway. >> >> Maybe OFBiz has changed some of that recently - hence your >> confusion. But in the past it has been a major pain in the butt. >> >> From my perspective it would be cool if all service calls were >> organized like this: >> >> Invoke service >> Permissions/parameter checking layer >> Perform desired action layer (permissions ignorant) >> >> >> >> David E Jones wrote: >>> On Jan 9, 2007, at 12:20 PM, Adrian Crum wrote: >>>> Andrew Zeneski wrote: >>>> >>>>> CRUD services probably will not have permissions assigned, and >>>>> NEVER called directly from requests. Maybe we add a flag to >>>>> these definitions to prevent them from being called directly >>>>> through an event handler. Special purpose services will be >>>>> implemented (which call the CRUD services) to perform >>>>> functions (i.e. create party, create order, etc). These >>>>> services will have permissions set and often custom >>>>> permission services to check if the user can perform the >>>>> operations. >>>> >>>> >>>> That would rock! I've always been frustrated by permissions >>>> checking in the lower level stuff. It would be great if there >>>> was a pattern followed where anytime the lower level services >>>> are used, they assume that permissions were checked somewhere >>>> higher. >>>> >>>> That's the pattern I used in https://issues.apache.org/jira/ >>>> browse/ OFBIZ-495. >>> This is interesting, but does it mean that for all CrUD service >>> definitions that are now being called directly will have to be >>> duplicated to create services with permissions? Right now the >>> current patterns involve quite a bit of this. Does this mean >>> we'd have alternate service definitions for each page where the >>> lower level service implementation is used? >>> Are the different permission requirements really that >>> conflicting? Based on the real-world scenarios I've been through >>> so far using the pattern of general and role limited, or even >>> multiple varieties of role limited, permissions is a fine way to >>> go, and can be done "centrally" in the lower level services so >>> nothing gets through accidentally. >>> I'm not quite sure where this is going, so perhaps it would be >>> good to step back and start putting together some more general >>> requirements and example scenarios. Given the fairly substantial >>> current functionality and the amount of work that will be >>> required regardless of what we choose it would be really great >>> to get something good on this pass. >>> Part of the reason I'm bringing this up is that I'm seeing some >>> "requirements" that are conflicted, for example: >>> 1. have a central place to easily manage permissions and things >>> security in general >>> 2. have no security (or at least permission) checking on lower >>> level (CrUD) services, and instead have each higher level >>> service handle the permissions >>> -David > |
Re: Custom Security / Permissions
|
|
Re: Custom Security / Permissions
|
|
I agree, I think this is nice. I thought you were talking about Java
Objects however, so indeed I think the service model will still fit this just fine. Andrew On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote: > Andrew Zeneski wrote: >> Adrian, >> Where do you see the need for an Object? So far what I have heard >> is service based authentication and permissions will cover >> everything, if you see otherwise please describe. >> Andrew > > My Original Example: > Object A wants to modify Object B. > > Implementation: > If Object A and Object B are members of the same permission > context, then > If Object A has modify permission in that context AND Object B > has modify-able permission in that context, then > Object A is granted permission to modify Object B > > Scenario 1: > In our sales order program we have orders that are used as > templates. Our orders are very complicated and detailed, and they > take a lot of time to create. Using templates speeds things up > considerably. Templates are copied to new orders and the new order > is modified. The templates are seldom modified, and only by those > who have permission to do so. Templates should not be deleted. > > I could add an order type called "TEMPLATE" and write custom code > to control what actions can be performed on records that have that > order type, OR using the security scheme mentioned above I could > just set the template's permissions to Modify-able=false and Delete- > able=false - the underlying security checking will do all of the > work my custom code would have done. > > Scenario 2: > I want to temporarily disable a service. I set the service's > permissions to Invoke-able=false. > > Scenario 3: > I'm the OFBiz administrator and I want to go on a vacation. I > assign a co-worker to be the OFBiz administrator in my absence by > giving him full admin permissions. Either accidentally or > maliciously, the coworker deletes or disables the main admin user > login while I'm gone. > > Using the security scheme mentioned above, I can set the main > admin's permissions to Modify-able=false and Delete-able=false for > anyone but the main admin. > > I could think of more. Assigning permissions to objects opens up > many possibilities. > |
Re: Custom Security / Permissions
|
|
Re: Custom Security / Permissions
|
|
Based on the discussions from this thread as well as some offline
discussions, the new service based permission checking is checked in. Examples of using this can be found in the example component. One feature not yet documented yet is you can trigger an eca on running a condition on hasPermission (boolean) and can either add additional permission checks or do alternative permission checking. This will be very handy! Thanks to everyone for their input! Andrew On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote: > Oh, oops. Yeah, Object = OFBiz element: user, record, service, etc. > > > Andrew Zeneski wrote: > >> I agree, I think this is nice. I thought you were talking about >> Java Objects however, so indeed I think the service model will >> still fit this just fine. >> Andrew >> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote: >>> Andrew Zeneski wrote: >>> >>>> Adrian, >>>> Where do you see the need for an Object? So far what I have >>>> heard is service based authentication and permissions will >>>> cover everything, if you see otherwise please describe. >>>> Andrew >>> >>> >>> My Original Example: >>> Object A wants to modify Object B. >>> >>> Implementation: >>> If Object A and Object B are members of the same permission >>> context, then >>> If Object A has modify permission in that context AND Object B >>> has modify-able permission in that context, then >>> Object A is granted permission to modify Object B >>> >>> Scenario 1: >>> In our sales order program we have orders that are used as >>> templates. Our orders are very complicated and detailed, and >>> they take a lot of time to create. Using templates speeds things >>> up considerably. Templates are copied to new orders and the new >>> order is modified. The templates are seldom modified, and only >>> by those who have permission to do so. Templates should not be >>> deleted. >>> >>> I could add an order type called "TEMPLATE" and write custom >>> code to control what actions can be performed on records that >>> have that order type, OR using the security scheme mentioned >>> above I could just set the template's permissions to Modify- >>> able=false and Delete- able=false - the underlying security >>> checking will do all of the work my custom code would have done. >>> >>> Scenario 2: >>> I want to temporarily disable a service. I set the service's >>> permissions to Invoke-able=false. >>> >>> Scenario 3: >>> I'm the OFBiz administrator and I want to go on a vacation. I >>> assign a co-worker to be the OFBiz administrator in my absence >>> by giving him full admin permissions. Either accidentally or >>> maliciously, the coworker deletes or disables the main admin >>> user login while I'm gone. >>> >>> Using the security scheme mentioned above, I can set the main >>> admin's permissions to Modify-able=false and Delete-able=false >>> for anyone but the main admin. >>> >>> I could think of more. Assigning permissions to objects opens up >>> many possibilities. >>> |
Re: Custom Security / Permissions
|
|
Looks good Andy, and there's even an example of how to use it! -David On Jan 9, 2007, at 10:35 PM, Andrew Zeneski wrote: > Based on the discussions from this thread as well as some offline > discussions, the new service based permission checking is checked in. > > Examples of using this can be found in the example component. One > feature not yet documented yet is you can trigger an eca on running > a condition on hasPermission (boolean) and can either add > additional permission checks or do alternative permission checking. > This will be very handy! > > Thanks to everyone for their input! > > Andrew > > > On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote: > >> Oh, oops. Yeah, Object = OFBiz element: user, record, service, etc. >> >> >> Andrew Zeneski wrote: >> >>> I agree, I think this is nice. I thought you were talking about >>> Java Objects however, so indeed I think the service model will >>> still fit this just fine. >>> Andrew >>> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote: >>>> Andrew Zeneski wrote: >>>> >>>>> Adrian, >>>>> Where do you see the need for an Object? So far what I have >>>>> heard is service based authentication and permissions will >>>>> cover everything, if you see otherwise please describe. >>>>> Andrew >>>> >>>> >>>> My Original Example: >>>> Object A wants to modify Object B. >>>> >>>> Implementation: >>>> If Object A and Object B are members of the same permission >>>> context, then >>>> If Object A has modify permission in that context AND Object >>>> B has modify-able permission in that context, then >>>> Object A is granted permission to modify Object B >>>> >>>> Scenario 1: >>>> In our sales order program we have orders that are used as >>>> templates. Our orders are very complicated and detailed, and >>>> they take a lot of time to create. Using templates speeds >>>> things up considerably. Templates are copied to new orders and >>>> the new order is modified. The templates are seldom modified, >>>> and only by those who have permission to do so. Templates >>>> should not be deleted. >>>> >>>> I could add an order type called "TEMPLATE" and write custom >>>> code to control what actions can be performed on records that >>>> have that order type, OR using the security scheme mentioned >>>> above I could just set the template's permissions to Modify- >>>> able=false and Delete- able=false - the underlying security >>>> checking will do all of the work my custom code would have done. >>>> >>>> Scenario 2: >>>> I want to temporarily disable a service. I set the service's >>>> permissions to Invoke-able=false. >>>> >>>> Scenario 3: >>>> I'm the OFBiz administrator and I want to go on a vacation. I >>>> assign a co-worker to be the OFBiz administrator in my absence >>>> by giving him full admin permissions. Either accidentally or >>>> maliciously, the coworker deletes or disables the main admin >>>> user login while I'm gone. >>>> >>>> Using the security scheme mentioned above, I can set the main >>>> admin's permissions to Modify-able=false and Delete-able=false >>>> for anyone but the main admin. >>>> >>>> I could think of more. Assigning permissions to objects opens >>>> up many possibilities. >>>> > |
Re: Custom Security / Permissions
|
|
Yes, however the example uses the built in permission checking in the
simple methods which in turn uses the Security Object. I still think this Object needs to be deprecated and as a best practice example this probably isn't good. Since simple methods (other than permission checking methods) won't need the check-permission any more, maybe this tag should be deprecated as well? What do you think about this? I would like to throw in a simple method which checks base permissions (like the security object does today). Maybe but this method in 'common'? Or it could even live in the service component, or security for that matter... Then there will be a generic 'checkBasePermission' service which can be used to replace the simple calls there today. What are your thoughts on that? Andrew On Jan 10, 2007, at 12:51 AM, David E Jones wrote: > > Looks good Andy, and there's even an example of how to use it! > > -David > > > On Jan 9, 2007, at 10:35 PM, Andrew Zeneski wrote: > >> Based on the discussions from this thread as well as some offline >> discussions, the new service based permission checking is checked in. >> >> Examples of using this can be found in the example component. One >> feature not yet documented yet is you can trigger an eca on >> running a condition on hasPermission (boolean) and can either add >> additional permission checks or do alternative permission >> checking. This will be very handy! >> >> Thanks to everyone for their input! >> >> Andrew >> >> >> On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote: >> >>> Oh, oops. Yeah, Object = OFBiz element: user, record, service, etc. >>> >>> >>> Andrew Zeneski wrote: >>> >>>> I agree, I think this is nice. I thought you were talking about >>>> Java Objects however, so indeed I think the service model will >>>> still fit this just fine. >>>> Andrew >>>> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote: >>>>> Andrew Zeneski wrote: >>>>> >>>>>> Adrian, >>>>>> Where do you see the need for an Object? So far what I have >>>>>> heard is service based authentication and permissions will >>>>>> cover everything, if you see otherwise please describe. >>>>>> Andrew >>>>> >>>>> >>>>> My Original Example: >>>>> Object A wants to modify Object B. >>>>> >>>>> Implementation: >>>>> If Object A and Object B are members of the same permission >>>>> context, then >>>>> If Object A has modify permission in that context AND Object >>>>> B has modify-able permission in that context, then >>>>> Object A is granted permission to modify Object B >>>>> >>>>> Scenario 1: >>>>> In our sales order program we have orders that are used as >>>>> templates. Our orders are very complicated and detailed, and >>>>> they take a lot of time to create. Using templates speeds >>>>> things up considerably. Templates are copied to new orders and >>>>> the new order is modified. The templates are seldom modified, >>>>> and only by those who have permission to do so. Templates >>>>> should not be deleted. >>>>> >>>>> I could add an order type called "TEMPLATE" and write custom >>>>> code to control what actions can be performed on records that >>>>> have that order type, OR using the security scheme mentioned >>>>> above I could just set the template's permissions to Modify- >>>>> able=false and Delete- able=false - the underlying security >>>>> checking will do all of the work my custom code would have done. >>>>> >>>>> Scenario 2: >>>>> I want to temporarily disable a service. I set the service's >>>>> permissions to Invoke-able=false. >>>>> >>>>> Scenario 3: >>>>> I'm the OFBiz administrator and I want to go on a vacation. I >>>>> assign a co-worker to be the OFBiz administrator in my absence >>>>> by giving him full admin permissions. Either accidentally or >>>>> maliciously, the coworker deletes or disables the main admin >>>>> user login while I'm gone. >>>>> >>>>> Using the security scheme mentioned above, I can set the main >>>>> admin's permissions to Modify-able=false and Delete-able=false >>>>> for anyone but the main admin. >>>>> >>>>> I could think of more. Assigning permissions to objects opens >>>>> up many possibilities. >>>>> >> > |
Re: Custom Security / Permissions
|
|
On Jan 10, 2007, at 8:57 AM, Andrew Zeneski wrote: > Yes, however the example uses the built in permission checking in > the simple methods which in turn uses the Security Object. I still > think this Object needs to be deprecated and as a best practice > example this probably isn't good. What would it mean to deprecate the Security object? What would replace it everywhere it is used? > Since simple methods (other than permission checking methods) won't > need the check-permission any more, maybe this tag should be > deprecated as well? What do you think about this? Similar to above, what would replace the check-permission simple- method, especially in the permission services? Would you also like to get rid of the if-permission operation and condition? > I would like to throw in a simple method which checks base > permissions (like the security object does today). Maybe but this > method in 'common'? Or it could even live in the service component, > or security for that matter... Is this what would replace the Security object and the check- permission operation? How would it be different? How would it be better? I'd appreciate any details you could offer on your thoughts, I must admit I'm pretty completely lost trying to see where you're going with this one... -David > Then there will be a generic 'checkBasePermission' service which > can be used to replace the simple calls there today. What are your > thoughts on that? > > Andrew > > On Jan 10, 2007, at 12:51 AM, David E Jones wrote: > >> >> Looks good Andy, and there's even an example of how to use it! >> >> -David >> >> >> On Jan 9, 2007, at 10:35 PM, Andrew Zeneski wrote: >> >>> Based on the discussions from this thread as well as some offline >>> discussions, the new service based permission checking is checked >>> in. >>> >>> Examples of using this can be found in the example component. One >>> feature not yet documented yet is you can trigger an eca on >>> running a condition on hasPermission (boolean) and can either add >>> additional permission checks or do alternative permission >>> checking. This will be very handy! >>> >>> Thanks to everyone for their input! >>> >>> Andrew >>> >>> >>> On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote: >>> >>>> Oh, oops. Yeah, Object = OFBiz element: user, record, service, etc. >>>> >>>> >>>> Andrew Zeneski wrote: >>>> >>>>> I agree, I think this is nice. I thought you were talking about >>>>> Java Objects however, so indeed I think the service model will >>>>> still fit this just fine. >>>>> Andrew >>>>> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote: >>>>>> Andrew Zeneski wrote: >>>>>> >>>>>>> Adrian, >>>>>>> Where do you see the need for an Object? So far what I have >>>>>>> heard is service based authentication and permissions will >>>>>>> cover everything, if you see otherwise please describe. >>>>>>> Andrew >>>>>> >>>>>> >>>>>> My Original Example: >>>>>> Object A wants to modify Object B. >>>>>> >>>>>> Implementation: >>>>>> If Object A and Object B are members of the same permission >>>>>> context, then >>>>>> If Object A has modify permission in that context AND Object >>>>>> B has modify-able permission in that context, then >>>>>> Object A is granted permission to modify Object B >>>>>> >>>>>> Scenario 1: >>>>>> In our sales order program we have orders that are used as >>>>>> templates. Our orders are very complicated and detailed, and >>>>>> they take a lot of time to create. Using templates speeds >>>>>> things up considerably. Templates are copied to new orders >>>>>> and the new order is modified. The templates are seldom >>>>>> modified, and only by those who have permission to do so. >>>>>> Templates should not be deleted. >>>>>> >>>>>> I could add an order type called "TEMPLATE" and write custom >>>>>> code to control what actions can be performed on records that >>>>>> have that order type, OR using the security scheme mentioned >>>>>> above I could just set the template's permissions to Modify- >>>>>> able=false and Delete- able=false - the underlying security >>>>>> checking will do all of the work my custom code would have done. >>>>>> >>>>>> Scenario 2: >>>>>> I want to temporarily disable a service. I set the service's >>>>>> permissions to Invoke-able=false. >>>>>> >>>>>> Scenario 3: >>>>>> I'm the OFBiz administrator and I want to go on a vacation. I >>>>>> assign a co-worker to be the OFBiz administrator in my absence >>>>>> by giving him full admin permissions. Either accidentally or >>>>>> maliciously, the coworker deletes or disables the main admin >>>>>> user login while I'm gone. >>>>>> >>>>>> Using the security scheme mentioned above, I can set the main >>>>>> admin's permissions to Modify-able=false and Delete-able=false >>>>>> for anyone but the main admin. >>>>>> >>>>>> I could think of more. Assigning permissions to objects opens >>>>>> up many possibilities. >>>>>> >>> >> > |
Re: Custom Security / Permissions
|
|
Re: Custom Security / Permissions
|
|
In reply to this post by David E Jones-2
I guess I jumped the gun on this one, I looked at this code today and
realized that it would be impossible to implement in a simple method. All the caching code is there and that's pretty darn important. I was hoping to find a way to actually get rid of the security object in many places to prevent its use (inside of services, simple methods, FTL files, etc). However, maybe its fine to just leave as is, as an alternative. The actual idea was to replace the security object everywhere it was used with a permission service. Laying out some base services to handle the generic permissions. But now I realize this isn't practical. Andrew On Jan 10, 2007, at 2:31 PM, David E Jones wrote: > > On Jan 10, 2007, at 8:57 AM, Andrew Zeneski wrote: > >> Yes, however the example uses the built in permission checking in >> the simple methods which in turn uses the Security Object. I still >> think this Object needs to be deprecated and as a best practice >> example this probably isn't good. > > What would it mean to deprecate the Security object? What would > replace it everywhere it is used? > >> Since simple methods (other than permission checking methods) >> won't need the check-permission any more, maybe this tag should be >> deprecated as well? What do you think about this? > > Similar to above, what would replace the check-permission simple- > method, especially in the permission services? Would you also like > to get rid of the if-permission operation and condition? > >> I would like to throw in a simple method which checks base >> permissions (like the security object does today). Maybe but this >> method in 'common'? Or it could even live in the service >> component, or security for that matter... > > Is this what would replace the Security object and the check- > permission operation? How would it be different? How would it be > better? > > I'd appreciate any details you could offer on your thoughts, I must > admit I'm pretty completely lost trying to see where you're going > with this one... > > -David > > >> Then there will be a generic 'checkBasePermission' service which >> can be used to replace the simple calls there today. What are your >> thoughts on that? >> >> Andrew >> >> On Jan 10, 2007, at 12:51 AM, David E Jones wrote: >> >>> >>> Looks good Andy, and there's even an example of how to use it! >>> >>> -David >>> >>> >>> On Jan 9, 2007, at 10:35 PM, Andrew Zeneski wrote: >>> >>>> Based on the discussions from this thread as well as some >>>> offline discussions, the new service based permission checking >>>> is checked in. >>>> >>>> Examples of using this can be found in the example component. >>>> One feature not yet documented yet is you can trigger an eca on >>>> running a condition on hasPermission (boolean) and can either >>>> add additional permission checks or do alternative permission >>>> checking. This will be very handy! >>>> >>>> Thanks to everyone for their input! >>>> >>>> Andrew >>>> >>>> >>>> On Jan 9, 2007, at 4:59 PM, Adrian Crum wrote: >>>> >>>>> Oh, oops. Yeah, Object = OFBiz element: user, record, service, >>>>> etc. >>>>> >>>>> >>>>> Andrew Zeneski wrote: >>>>> >>>>>> I agree, I think this is nice. I thought you were talking >>>>>> about Java Objects however, so indeed I think the service >>>>>> model will still fit this just fine. >>>>>> Andrew >>>>>> On Jan 9, 2007, at 3:57 PM, Adrian Crum wrote: >>>>>>> Andrew Zeneski wrote: >>>>>>> >>>>>>>> Adrian, >>>>>>>> Where do you see the need for an Object? So far what I have >>>>>>>> heard is service based authentication and permissions will >>>>>>>> cover everything, if you see otherwise please describe. >>>>>>>> Andrew >>>>>>> >>>>>>> >>>>>>> My Original Example: >>>>>>> Object A wants to modify Object B. >>>>>>> >>>>>>> Implementation: >>>>>>> If Object A and Object B are members of the same permission >>>>>>> context, then >>>>>>> If Object A has modify permission in that context AND >>>>>>> Object B has modify-able permission in that context, then >>>>>>> Object A is granted permission to modify Object B >>>>>>> >>>>>>> Scenario 1: >>>>>>> In our sales order program we have orders that are used as >>>>>>> templates. Our orders are very complicated and detailed, and >>>>>>> they take a lot of time to create. Using templates speeds >>>>>>> things up considerably. Templates are copied to new orders >>>>>>> and the new order is modified. The templates are seldom >>>>>>> modified, and only by those who have permission to do so. >>>>>>> Templates should not be deleted. >>>>>>> >>>>>>> I could add an order type called "TEMPLATE" and write custom >>>>>>> code to control what actions can be performed on records >>>>>>> that have that order type, OR using the security scheme >>>>>>> mentioned above I could just set the template's permissions >>>>>>> to Modify-able=false and Delete- able=false - the underlying >>>>>>> security checking will do all of the work my custom code >>>>>>> would have done. >>>>>>> >>>>>>> Scenario 2: >>>>>>> I want to temporarily disable a service. I set the service's >>>>>>> permissions to Invoke-able=false. >>>>>>> >>>>>>> Scenario 3: >>>>>>> I'm the OFBiz administrator and I want to go on a vacation. >>>>>>> I assign a co-worker to be the OFBiz administrator in my >>>>>>> absence by giving him full admin permissions. Either >>>>>>> accidentally or maliciously, the coworker deletes or >>>>>>> disables the main admin user login while I'm gone. >>>>>>> >>>>>>> Using the security scheme mentioned above, I can set the >>>>>>> main admin's permissions to Modify-able=false and Delete- >>>>>>> able=false for anyone but the main admin. >>>>>>> >>>>>>> I could think of more. Assigning permissions to objects opens >>>>>>> up many possibilities. >>>>>>> >>>> >>> >> > |
| Free forum by Nabble | Edit this page |