As I said before, the concept of role based permissions has become
muddled. OFBiz doesn't enforce one pattern over the other and there is
a good reason for that: different OFBiz installations will have
different security requirements.
Using your Facility example: A party can be associated to a facility
in a certain role. That relationship simply models a real-world
relationship in the data, but it doesn't necessarily model an OFBiz
user's security role. In other words, the party being related to the
facility might not be an OFBiz user - so security permissions have
nothing to do with the relationship.
Conversely, an application might want to consider the OFBiz
user/party's relationship to the facility to control access to certain
facility functions. In other words, if OFBiz user's partyId X is
related to facility Y in party role Z, then partyId X is granted
update permission for facility Y.
In my opinion, using party roles to control security is a bad idea -
and I'm speaking as someone who has done it. I think the reason for it
being that way is because OFBiz doesn't have the means to connect
OFBiz user (not party) X to facility Y in security role Z. Using party
roles to control security assumes that a party's role in an
organization will always equal the OFBiz user's role in OFBiz. In real
life they are not always the same.
-Adrian
Quoting Pankaj Singh <[email protected]>:
Hi Adrain,
We further reviewed the security model and implementation references coupled
with the inputs on this thread. This is what we find.
https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+security
<snip>
Security Roles
Security Roles provide a means to associate a user ID (userLoginId) with a
particular OFBiz element. This may seem the same as Security Permission, but
it is slightly different. For example: a user is assigned the ORDERMGR_VIEW
permission, and is associated to a particular facility (let's say XYZ
Company) with the ORDERMGR_ROLE_UPDATE security role. This combination would
allow the user to view orders for all facilities, and update orders for the
XYZ Company facility only. They may be seen as limiting permissions.
</snip>
The above is very close to what we are looking to do. What is unclear though
is the association of a particular facility to ORDER_ROLE_UPDATE security
role. What we find is a FacilityParty Entity storing the association of
facilityId, partyId and roleTypeId and no association like the one mentioned
ORDERMGR_ROLE_UPDATE which believe is intended to be from
SecurityGroupPermission entity.
So, to solve the issues of deriving the permissions against a (role) for a
(party) for a (record), will it make sense to have a relationship entity
(say RoleTypeSecurityGroup) between RoleType and
SecurityGroupPermission ?This will enable getting the party
association with the entity record with a
certain role (ENTITYRole) and then figure out the actual permissions
matching the roleType from the RoleTypeSecurityGroup entity.
That still leaves the SecurityGroupPermission association with userLogin
which can be special overrides over and above.
--
Thanks ,
Pankaj Kumar Singh
On Thu, Feb 3, 2011 at 12:58 PM, Adrian Crum <
[email protected]> wrote:
There are no links between a party role type and a security permission
group.
In the beginning, security roles were simply permissions with the word ROLE
in them. Various applications used the security role permissions to control
access to certain actions.
Over time, application code started using the party role to control access
- effectively making the party role a security role, so the concept of role
based permissions has become blurred or muddled.
https://cwiki.apache.org/OFBTECH/ofbiz-security.html
Unfortunately, the current party role based permissions are not very well
documented. You have to look at the code to determine which roles control
access to various parts of the applications.
-Adrian
On 2/2/2011 10:47 PM, Pankaj Singh wrote:
Hi ,
Yes we have gone through the shared links. Also understand that link
between
userIds and security groups and between party and partyrole. What is not
clear is how these roles translate to actual privileges. In other words we
did not find any entity to capture links between RoleType and
SecurityPermisssionGroup.
Here is what we are looking at.
- Derive permissions from associated PartyRole.
- Avoid security group association to userLogin. This is apply security
privileges at the party level rather than at the userlogin level.
Hope that helps. It is possible that all these are implemented in a
certain
way and discussed in the link referenced but unclear to us at this time
and
therefore looking for hints.
Thanks ,
Pankaj Kumar Singh
On Thu, Feb 3, 2011 at 12:44 AM, BJ Freeman<[email protected]> wrote:
https://cwiki.apache.org/OFBTECH/ofbiz-security.html
https://demo-trunk.ofbiz.apache.org/partymgr/control/viewprofile?partyId=admin
I use this for an example
this party has many logins. each login can have its own Security Groups
On top of this you can also have roles assigned to the party
https://demo-trunk.ofbiz.apache.org/partymgr/control/viewroles?partyId=admin
these are available for all the logins assigned for that party.
from a code level you use the login to find the roles assigned to the
party, as well as the securitygroups for that login.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation<
http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com<http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Pankaj Singh sent the following on 2/2/2011 9:41 AM:
Hi All,
We have some query about security system please give us some ideas on
below
:-
For a given role type how does the Application find out the applicable
security permissions ?
for example :-
a manager role type in org_A requires ORDERMGR_ADMIN only while another
org_B requires ORDERMGR_ADMIN and PARTYMGR_ADMIN. How can this be done
without code level changes ?
