Freemarker模板片段级别
session变量：security总是存在于screen的上下文对象——context中，你可以在模板中使用已定义的Java方法：hasPermission; hasEntityPermission;hasRolePermission;
service定义级别你可以定义专门的“Permission service”在不同的安全模式、不同的component中进行复用，这里你可以通过扩展ECA的规则来在其中插入权限验证。具体超出了本篇的范文可以参考示例`exampleGenericPermission`（example component下）
service编程级别这里有两种方式：
Minilanguage:使用<check-permission 标签，注：Minilanguage是OFBiz特有的基于XML的“语言”。
Java:使用org.ofbiz.security.Security.API
记录级别比如对于一个有特定约束的实体，一个基于它的查询，必须要具有特定的权限才能取得相应的结果
角色受限的（或者基于角色）权限（又称Party Roles）同如上的记录级别，通过使用RoleType、PartyRole以及相关的实体（如ContentAndRole）来进行控制。
注：这里的角色倾向于业务规则，而完全不同于下面谈到的“角色”
安全角色安全角色提供一个手段来将一个登录用户与一个特殊的OFBiz“元素”建立关联，举个例子，如果一个用户被分配有ORDERMGR_VIEW权限，而该用户又与一个特殊的团体有关联（假设称之为XYZ公司，该公司具有ORDERMGR_ROLE_UPDATE安全角色）。那么这么一组合将允许该用户浏览所有属于该公司的权限，并且可以只为该公司更新订单。
数据表结构设计首先来看看OFBiz对于权限这块的表结构设计，这里一共牵扯到6个数据表：
SECURITY_GROUP
SECURITY_PERMISSION
SECURITY_GROUP_PERMISSION
USER_LOGIN_SECURITY_GROUP
PARTY_RELATIONSHIP
SECURITY_PERMISSION_AUTO_GRANT（不作讨论）
SECURITY_GROUP
SECURITY_PERMISSION
权限表，这里定义了系统中的所有权限。其中最主要需要关注的就是前两个字段：
PERMISSION_ID:权限名称：通常以形如“Application_Operate”的形式进行定义（其中，Application表示具体的应用名称，Operate表示操作名称，常用的有CREATE/UPDATE/...）。当然了，也有一些特殊的命名方式比如：“MARKETING_VIEW”表示对MARKETING应用的页面拥有查看权限；"MANUAL_PAYMENT"表示人工支付的事务操作权限；"MARKETING_ADMIN"这里ADMIN作为后缀是一个特殊，表示它具有对MARKETING应用的所有操作权限。
DESCRIPTION:对于PERMISSION_ID的简短描述
SECURITY_GROUP_PERMISSION
如上面在设计思路中所述，这是“Group”与“Permission”的多对多关系表。从语义上也不难理解：一个安全组可以拥有多个权限，一个权限也可以从属于多个安全组。
USER_LOGIN_SECURITY_GROUP
登录用户安全组，从表的命名方式上也不难看出，这也是一个多对多的关系表（注意观察主键定义）。我们可以看到，这张表并不只是将两张表的主键合起来作为联合主键，而是联合了“FROM_DATE”，三者联合作为主键。这里我们需要关注OFBiz数据表中普遍采用的一个设计模式——过期而非删除。也就是说，很多关系是有时效性的，这些时效性表现在"FROM_DATE"跟"THRU_DATE"两个字段上。如果发现当前记录已过期，那么就认为其无效，这就相当于我们传统意义上的“删除记录”操作。这种设计方式在关系庞杂的企业应用中可以避免在删除时被外键困扰而导致的各种异常以及数据一致性约束。
PARTY_RELATIONSHIP
可以看到该表中包含有一个SECURITY_GROUP_ID字段，用来关联一个安全组（该字段通常都为null）。因为之前安全组只是跟用户产生关联，而用户也是Party的一种，Party可以包含任何的个人、用户、机构等。PARTY_RELATIONSHIP可以用于描述任何两个事物之间的关系，而这种关系有时不仅仅是人，因此他们有时可能也需要拥有权限，而不仅仅是登录用户才需要拥有权限。