Great movement! Exciting! Only one question, I read your document and I'm not sure whether it's easy to support multiple OUs of sales, for example: access:sfa:langhua egovernment sales unit:opportunity access:sfa:langhua ecomerce sales unit:opportunity access:sfa:langhua chemistry sales unit:opportunity
Regards, Shi Yusen/Beijing Langhua Ltd. 在 2009-05-01五的 13:36 -0400，Andrew Zeneski写道： > I'd like to move the discussion of the new Authz security > implementation to this thread. To start off the discussion I will > briefly describe what I would like to propose as the NEW best practices. > > 1. Single point of contact for ALL security checks, instead of having > security embedded in functionality, or tied to services directly, the > API should be the governor of all security. This means no more writing > security logic in the functionality, and no more permission services > attached directly to functionality (services or ecas). This is a bad > design IMHO because it spreads the permission logic around in multiple > places and makes it impossible to get the same results when checking > permissions from different framework tools. > > -- We want to be consistent, and be able to obtain the same > information from the UI or screen/form as we would get from a service > call. > -- Main point of contact is the Authorization interface. > > 2. Permission services become Dynamic Access (DA). Now instead of > having permission services attached to services, we have Dynamic > Access implementations which can be a compiled Java object, a Groovy > script or a Service. My personal preference here is the Groovy script, > but the API current supports all three. This DA logic is attached to a > permission instead of a service. > > -- This allows for extending or changing the permission logic for a > specific implementation/customization/application much easier. Since > the DAs are all data driven, changing the seed data you can change the > logic which is used. This means you no longer have to customize the > services or logic in OFBiz to change the way authorization is handled > for your company (or client); one less thing to worry about when > merging customizations with the open source project. > > -- for groovy use "component://path/to/script.groovy" in the > dynamicAccess field on SecurityPermission. > -- for services use "service:serviceName" in the dynamicAccess field > on SecurityPermission > -- for objects use "org.ofbiz.path.to.Object (which implements > DynamicAccess)" in the dynamicAccess field on SecurityPermission > > 3. Avoid having to check multiple permissions, for example > PARTYMGR_UPDATE or PARTYMGR_ADMIN. Instead we use a new permission > format which embeds all permissions which will be accepted: > > Example: update:party:contact:10000 - Update the contact information > for party 10000 > > This will allow anyone who has: > "update" or "update:party" or "update:party:contact" or is granted > record level access by the DA logic. > > 4. Define permission for users, not admins. Instead of looking for a > static permission, set the permission to be checked at the most > granular level. When doing so, admin users will always have permission > and the API will handle user access using DA logic. > > -- see: http://docs.ofbiz.org/x/JR4 > > That's enough to get started, http://docs.ofbiz.org/x/-B0 contains a > lot more details; interested parties are encouraged to read it through. > > > Andrew > > > > > > >
