Security page in OFBTECH

[Jacques Le Roux]

Hi All,

I have partially rewritten the Security page in OFBTECH
https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+security+permissions

I think it's now more clear. I have also added some comments about the situation with "role limited" permissions in a warning.

Please review and comment if needed, thanks.

I have still to review this pages and decided about them
https://cwiki.apache.org/confluence/display/OFBTECH/Security+Services+-+Developer
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=7045135

Jacques

[Ron Wheeler]

Since I can not edit these pages, here are some suggested changes to
improve readability.

Here security is about permissions granted to access OFBiz artifacts,
like services, screen and data.
could be
Security, as discussed in this article, is about permissions being
granted to access OFBiz artifacts such as services, screens and data.


Category 2 (party permission, eg ORDERMGR_ROLE_CREATE) is*Party
dependent*and can be combined with Category 1, usually with special
"*role limited*" permissions that when checked require not just the
permission, but some*relationship*between the Party and whatever records
are concerned by the screen, service, or whatever. This lets quite open
possibilities.

could be

Category 2 (party permission, eg ORDERMGR_ROLE_CREATE) is*Party
dependent*and can be combined with Category 1, usually with special
"*role limited*" permissions that require not just the permission, but
some*relationship*between the Party and whatever artifact are being
controlled. This supports quite a wide range of access control.


It should be possible (in theory, not tested) to use the Category 1
without the party component. But the Category 2 is very dependent on the
Party data model and whatever data model relates to it for the required
relationships.

It should be possible (in theory, not tested) to use Category 1 security
without the party component. However, Category 2 is very dependent on
the Party data object and the data object related to it.


Note that a "role limited" permissions to work*requires*an enforcing
relationship to be used. There are currently a number of cases in OFBiz
where "role limited" permissions are used without enforcing
relationships. For instance often the <alt-permission tag is used in
simple methods as if the "role limited" permission would complement the
primary user permission when it's actually only redundant since the
<check-permission tag is not supposed to infer by itself what to do with
this alternative permission. This is explained and discussed inthis dev
ML thread <http://markmail.org/message/4eivnpyarcemtxxq>. Inthis other
user ML thread <http://markmail.org/message/si4yhvc57ra24joq>a solution
is proposed to prevent this to spread all over the code. Two other
propositions has been discussed some years ago, notably thisOFBiz
Security Redesign
<https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign>.

Note though that there are cases where the alternative permission could
be used, but not with "role limited" permissions, only user permissions.
For instance someone may not have the right to create all types of order
but only sales orders. Then with the primary permission defined
ORDERMGR_CREATE this person can't create a sales order but with
the alternative permission defined as ORDERMGR_SALES_CREATE it's
possible. As you see access permissions can be a very complex topic!


Is the section in bold a warning. It seems that using "role limited"
permissions are used without enforcing relationships is not a
recommended practice but it is described here as part of role limited
permissions with links to other references which are proposed as "best
practices". Perhaps this could, at least, be broken into 2 paragraphs
and the description of using role limited permission with enforcing
relationships described first and then the alternative of "without"
discussed with proper cautionary notes.
Perhaps clarifying the audience (new developer?) might make this section
more readable and give the person a clear idea of how to do it right
while explaining that they might encounter some less secure alternatives
while looking at existing applications.

A secure "role limited" permission scheme*requires*that an enforcing
relationship be used. *There are currently a number of cases in OFBiz
where "role limited" permissions are used without enforcing
relationships. For instance often the <alt-permission tag is used in
simple methods as if the "role limited" permission would complement the
primary user permission when it's actually redundant since the
<check-permission tag is not supposed to infer by itself what to do with
this alternative permission. This is explained and discussed in****this
dev ML thread <http://markmail.org/message/4eivnpyarcemtxxq>**.
In****this other user ML thread
<http://markmail.org/message/si4yhvc57ra24joq>****a solution is proposed
to prevent this from spreading all over the code. Two other propositions
have been discussed some years ago, notably this****OFBiz Security
Redesign
<https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign>**.*

Also note that there are cases where the alternative permission could be
used, but not with "role limited" permissions, only user permissions.
For instance someone may not have the right to create all types of order
but only sales orders. Then with the primary permission defined
ORDERMGR_CREATE this person can't create a sales order but with
the alternative permission defined as ORDERMGR_SALES_CREATE, it's
possible. As you see access permissions can be a very complex topic!



Following is a technical description to explain security and permissions
in OFBiz.

The following is a technical description explaining security and
permissions in OFBiz.



The basics of the system (Category 1) are that there are*security
permissions*which consist out of two parts separated with a '_'
character. Most ot the time, the first part is the application name and
the second part is the action or operation. The application is normally
the same as the component name (or webapp name in case of sub-component
webapp) however in uppercase characters. The action can be anything
however the most used are : VIEW, CREATE, UPDATE, DELETE and the special
one called ADMIN which allows all operations.
An example is the security permission for creating an order, it's  
ORDERMGR_CREATE. In this case the application is the order manager and
the action is 'CREATE' to create an new order. This permission is
contained in the 'ORDERENTRY'*security group*. So every user ID
(userLoginId) which is connected to this group will be able to create
orders.

Category 1is based on*security permissions*. The names of permissions
consist out of two parts separated with a '_' character. Most of the
time, the first part is the application name and the second part is the
action or operation. In order to avoid name conflicts, the application
name is normally the same as the component name (or webapp name in case
of sub-component webapp) written in uppercase characters. The action can
be anything. However  VIEW, CREATE, UPDATE, DELETE and ADMIN are the
most commonly used. ADMIN is a special permission which allows all
operations.
For example the security permission for creating an order, is
ORDERMGR_CREATE. The application is the Order Manager (ORDERMGR) and the
action is 'CREATE' which indicates that this permission controls the
creation of an new order. OOTB, this permission is granted to the
'ORDERENTRY'*security group*, so every user ID (userLoginId) which is
part of the ORDERENTRY group can create orders.



In the file ofbiz-component.xml the*base-permission*is defined. The user
who want to login needs to have at least the base-permission
COMPONENT-NAME_VIEW or base-permission COMPONENT-NAME_ADMIN permissions.
Most of the components have the values OFBTOOLS coupled with generally
COMPONENT-NAME permission and this means that both are required to gain
access to the component.
The idea behind requiring both OFBTOOLS and COMPONENT-NAME_VIEW (or
base-permission COMPONENT-NAME_ADMIN permissions) is so that a OFBTOOLS
controls the access to the web apps, while COMPONENT-NAME_VIEW can be
used to control access information in any web application.
*Beware:*using comma as and operator is not obvious and has proven to be
a source of confusion in the past


- The "base permission" concept is never defined. It just magically
appears in a file.

- This paragraph needs some work for fix the sentence in bold.
"components" coupling has odd sexual connotations but "component" is not
defined - we did has "application and webapp in the previous section
related in some way to "component" but that relationship was not defined.
Perhaps there should be a statement at the start of the article
describing the relationship between "component" "application" and
"webapp" in the security context and then use a consistent description
of the security object.

- I see nothing about "commas" in the paragraph so the "*Beware"* makes
no sense

The*base-permission*is defined In the ofbiz-component.xml file. The user
who wants to login needs to have at least the base-permission
COMPONENT-NAME_VIEW or base-permission COMPONENT-NAME_ADMIN permission.
*Most of the components have the values OFBTOOLS coupled with generally
COMPONENT-NAME permission and this means that both are required to gain
access to the component.***(Makes no sense - I can not figure out what
this is supposed to mean)
The idea behind requiring both OFBTOOLS and COMPONENT-NAME_VIEW (or
base-permission COMPONENT-NAME_ADMIN permissions) is so that a OFBTOOLS
controls the access to the web apps, while COMPONENT-NAME_VIEW can be
used to control access information in any web application.
*Beware:**using comma as and operator is not obvious and has proven to
be a source of confusion in the past*


I gave up until we sort out "component" since it is used after this point.

Ron


On 07/11/2014 6:20 AM, Jacques Le Roux wrote:

> Hi All,
>
> I have partially rewritten the Security page in OFBTECH
> https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+security+permissions 
>
>
> I think it's now more clear. I have also added some comments about the
> situation with "role limited" permissions in a warning.
>
> Please review and comment if needed, thanks.
>
> I have still to review this pages and decided about them
> https://cwiki.apache.org/confluence/display/OFBTECH/Security+Services+-+Developer 
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=7045135
>
> Jacques
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Jacques Le Roux]

OK I have done my best to take your propositions into account.

Please review, and continue if you agree. We need also some attention from at least Adrian for the "login level", other committers are also wanted of
course.

Thanks

Jacques
PS: writing critical documentation takes at least as long time as coding...

Le 07/11/2014 16:38, Ron Wheeler a écrit :

> Since I can not edit these pages, here are some suggested changes to improve readability.
>
> Here security is about permissions granted to access OFBiz artifacts, like services, screen and data.
> could be
> Security, as discussed in this article, is about permissions being granted to access OFBiz artifacts such as services, screens and data.
>
>
> Category 2 (party permission, eg ORDERMGR_ROLE_CREATE) is*Party dependent*and can be combined with Category 1, usually with special "*role limited*"
> permissions that when checked require not just the permission, but some*relationship*between the Party and whatever records are concerned by the
> screen, service, or whatever. This lets quite open possibilities.
>
> could be
>
> Category 2 (party permission, eg ORDERMGR_ROLE_CREATE) is*Party dependent*and can be combined with Category 1, usually with special "*role limited*"
> permissions that require not just the permission, but some*relationship*between the Party and whatever artifact are being controlled. This supports
> quite a wide range of access control.
>
>
> It should be possible (in theory, not tested) to use the Category 1 without the party component. But the Category 2 is very dependent on the Party
> data model and whatever data model relates to it for the required relationships.
>
> It should be possible (in theory, not tested) to use Category 1 security without the party component. However, Category 2 is very dependent on the
> Party data object and the data object related to it.
>
>
> Note that a "role limited" permissions to work*requires*an enforcing relationship to be used. There are currently a number of cases in OFBiz where
> "role limited" permissions are used without enforcing relationships. For instance often the <alt-permission tag is used in simple methods as if the
> "role limited" permission would complement the primary user permission when it's actually only redundant since the <check-permission tag is not
> supposed to infer by itself what to do with this alternative permission. This is explained and discussed inthis dev ML thread
> <http://markmail.org/message/4eivnpyarcemtxxq>. Inthis other user ML thread <http://markmail.org/message/si4yhvc57ra24joq>a solution is proposed to
> prevent this to spread all over the code. Two other propositions has been discussed some years ago, notably thisOFBiz Security Redesign
> <https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign>.
>
> Note though that there are cases where the alternative permission could be used, but not with "role limited" permissions, only user permissions. For
> instance someone may not have the right to create all types of order but only sales orders. Then with the primary permission defined ORDERMGR_CREATE
> this person can't create a sales order but with the alternative permission defined as ORDERMGR_SALES_CREATE it's possible. As you see access
> permissions can be a very complex topic!
>
>
> Is the section in bold a warning. It seems that using "role limited" permissions are used without enforcing relationships is not a recommended
> practice but it is described here as part of role limited permissions with links to other references which are proposed as "best practices". Perhaps
> this could, at least, be broken into 2 paragraphs and the description of using role limited permission with enforcing relationships described first
> and then the alternative of "without" discussed with proper cautionary notes.
> Perhaps clarifying the audience (new developer?) might make this section more readable and give the person a clear idea of how to do it right while
> explaining that they might encounter some less secure alternatives while looking at existing applications.
>
> A secure "role limited" permission scheme*requires*that an enforcing relationship be used. *There are currently a number of cases in OFBiz where
> "role limited" permissions are used without enforcing relationships. For instance often the <alt-permission tag is used in simple methods as if the
> "role limited" permission would complement the primary user permission when it's actually redundant since the <check-permission tag is not supposed
> to infer by itself what to do with this alternative permission. This is explained and discussed in****this dev ML thread
> <http://markmail.org/message/4eivnpyarcemtxxq>**. In****this other user ML thread <http://markmail.org/message/si4yhvc57ra24joq>****a solution is
> proposed to prevent this from spreading all over the code. Two other propositions have been discussed some years ago, notably this****OFBiz Security
> Redesign <https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign>**.*
>
> Also note that there are cases where the alternative permission could be used, but not with "role limited" permissions, only user permissions. For
> instance someone may not have the right to create all types of order but only sales orders. Then with the primary permission defined ORDERMGR_CREATE
> this person can't create a sales order but with the alternative permission defined as ORDERMGR_SALES_CREATE, it's possible. As you see access
> permissions can be a very complex topic!
>
>
>
> Following is a technical description to explain security and permissions in OFBiz.
>
> The following is a technical description explaining security and permissions in OFBiz.
>
>
>
> The basics of the system (Category 1) are that there are*security permissions*which consist out of two parts separated with a '_' character. Most ot
> the time, the first part is the application name and the second part is the action or operation. The application is normally the same as the
> component name (or webapp name in case of sub-component webapp) however in uppercase characters. The action can be anything however the most used
> are : VIEW, CREATE, UPDATE, DELETE and the special one called ADMIN which allows all operations.
> An example is the security permission for creating an order, it's ORDERMGR_CREATE. In this case the application is the order manager and the action
> is 'CREATE' to create an new order. This permission is contained in the 'ORDERENTRY'*security group*. So every user ID (userLoginId) which is
> connected to this group will be able to create orders.
>
> Category 1is based on*security permissions*. The names of permissions consist out of two parts separated with a '_' character. Most of the time, the
> first part is the application name and the second part is the action or operation. In order to avoid name conflicts, the application name is
> normally the same as the component name (or webapp name in case of sub-component webapp) written in uppercase characters. The action can be
> anything. However  VIEW, CREATE, UPDATE, DELETE and ADMIN are the most commonly used. ADMIN is a special permission which allows all operations.
> For example the security permission for creating an order, is ORDERMGR_CREATE. The application is the Order Manager (ORDERMGR) and the action is
> 'CREATE' which indicates that this permission controls the creation of an new order. OOTB, this permission is granted to the 'ORDERENTRY'*security
> group*, so every user ID (userLoginId) which is part of the ORDERENTRY group can create orders.
>
>
>
> In the file ofbiz-component.xml the*base-permission*is defined. The user who want to login needs to have at least the base-permission
> COMPONENT-NAME_VIEW or base-permission COMPONENT-NAME_ADMIN permissions. Most of the components have the values OFBTOOLS coupled with generally
> COMPONENT-NAME permission and this means that both are required to gain access to the component.
> The idea behind requiring both OFBTOOLS and COMPONENT-NAME_VIEW (or base-permission COMPONENT-NAME_ADMIN permissions) is so that a OFBTOOLS controls
> the access to the web apps, while COMPONENT-NAME_VIEW can be used to control access information in any web application.
> *Beware:*using comma as and operator is not obvious and has proven to be a source of confusion in the past
>
>
> - The "base permission" concept is never defined. It just magically appears in a file.
>
> - This paragraph needs some work for fix the sentence in bold. "components" coupling has odd sexual connotations but "component" is not defined - we
> did has "application and webapp in the previous section related in some way to "component" but that relationship was not defined.
> Perhaps there should be a statement at the start of the article describing the relationship between "component" "application" and "webapp" in the
> security context and then use a consistent description of the security object.
>
> - I see nothing about "commas" in the paragraph so the "*Beware"* makes no sense
>
> The*base-permission*is defined In the ofbiz-component.xml file. The user who wants to login needs to have at least the base-permission
> COMPONENT-NAME_VIEW or base-permission COMPONENT-NAME_ADMIN permission.
> *Most of the components have the values OFBTOOLS coupled with generally COMPONENT-NAME permission and this means that both are required to gain
> access to the component.***(Makes no sense - I can not figure out what this is supposed to mean)
> The idea behind requiring both OFBTOOLS and COMPONENT-NAME_VIEW (or base-permission COMPONENT-NAME_ADMIN permissions) is so that a OFBTOOLS controls
> the access to the web apps, while COMPONENT-NAME_VIEW can be used to control access information in any web application.
> *Beware:**using comma as and operator is not obvious and has proven to be a source of confusion in the past*
>
>
> I gave up until we sort out "component" since it is used after this point.
>
> Ron
>
>
> On 07/11/2014 6:20 AM, Jacques Le Roux wrote:
>> Hi All,
>>
>> I have partially rewritten the Security page in OFBTECH
>> https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+security+permissions
>>
>> I think it's now more clear. I have also added some comments about the situation with "role limited" permissions in a warning.
>>
>> Please review and comment if needed, thanks.
>>
>> I have still to review this pages and decided about them
>> https://cwiki.apache.org/confluence/display/OFBTECH/Security+Services+-+Developer
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=7045135
>>
>> Jacques
>>
>
>