I agree that the Roles (page 34 vol I) for a party should not be used
for security.
however if you step back and use roles in partyrelationships (page 41
vol I), you do limit what data is available to a login related to a party.
This is not a security situation but a data relationship.
to me the security then is a finer definition as to CRUD functions on
the data, or should be, that is available to the that party, based on
the application interacting on the data.
=========================
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
[email protected] sent the following on 2/3/2011 8:57 AM:
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 ?
