ModeShape把所有的认证和授权交给仓库配置文件中所配置的provider来做。ModeShape提供了一些现成的程序,但也可以创建自定义的身份验证和授权provider。
访问控制是个例外,ModeShape提供了标准JCR API定义在Node级别的访问控制方法,这种细粒度的访问控制在ModeShape中处理,存储在常规存储库内容中,并且建立在现有身份验证和授权提供程序上。
在创建Session之前,客户端程序必须登录并提供Credential来完成认证。ModeShape把次认证传递给一系列的AuthenticationProvider组件,最后返回一个合法的Session。
授权provider,会返回一个内置的与Session关联的SecurityContext,通过次SecurityContext来确认此session的具体读写权限。
三个角色名称为:readonly,readwrite和admin。
ModeShape允许创建匿名Session,不用经过认证,只具有读权限。当客户端认证失败时,可能有两种返回结果:
JAAS是最简单的provider,也是ModeShape默认的认证策略。配置方式有很多种,下面是xml方式。
<?xml version='1.0'?>
<policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:jboss:security-config:5.0" xmlns="urn:jboss:security-config:5.0">
<application-policy name="modeshape-jcr">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">security/users.properties</module-option>
<module-option name="rolesProperties">security/roles.properties</module-option>
</login-module>
</authentication>
</application-policy>
</policy>
回想一下,上述基于角色的授权适用于整个存储库或工作空间,因此被称为粗粒度授权。 这种简单的方法对于许多应用程序来说是完全可以接受的。 但是,可以使用细粒度的授权来确定允许在特定节点或子树上执行哪些操作。 设置和管理这些细粒度权限和访问控制列表的API实际上是标准JCR 2.0 API的一部分。
请注意,在评估任何细粒度的访问控制之前,必须已为已认证的用户授予存储库的粗粒度角色。 这意味着,例如,即使已向经过身份验证的用户授予了修改节点属性的特权,也没有任何意义,除非该用户具有允许写入或更改内容的角色之一。 换句话说,使用细粒度访问控制时,ModeShape将要求粗粒度和细粒度授权都允许请求的操作。
JCR2.0定义了以下权限
Privilege | Description |
---|---|
jcr:read | 获取Node,属性和内容 |
jcr:modifyProperties | 创建,删除,修改Node中属性值. |
jcr:addChildNodes | 创建node的子node. |
jcr:removeNode | 删除一个node |
jcr:removeChildNodes | 删除node的子node。 |
jcr:write | 权限组合: jcr:modifyProperties , jcr:addChildNodes , jcr:removeNode , and jcr:removeChildNodes . |
jcr:readAccessControl | 读取node的权限控制设置 |
jcr:modifyAccessControl | 修改node的权限控制设置 |
jcr:lockManagement | 锁/释放node |
jcr:versionManagement | node版本管理 |
jcr:nodeTypeManagement | 添加/删除混合结点类型,修改基本结点类型. |
jcr:retentionManagement | node保留管理 |
jcr:lifecycleManagement | node生命周期管理 |
jcr:all | 权限组和: jcr:read , jcr:write , jcr:readAccessControl , jcr:modifyAccessControl , jcr:lockManagement , jcr:versionManagement , jcr:nodeTypeManagement , jcr:retentionManagement , and jcr:lifecycleManagement |
如果AuthorizationProvider或AdvancedAuthorizationProvider实现对hasRole(groupName)返回true,则经过身份验证的用户将被视为组的成员。
可以通过将访问控制策略分配给节点来控制授予用户的特权。 但是,在可以控制对节点的访问之前,它必须具有“ mode:accessControllable”。 每个这样的节点具有一个或多个访问控制策略,可以向其添加其他访问控制条目。
定义权限控制策略的代码段
String path = "/Cars/Luxury";
String[] privileges = new String[]{Privilege.JCR_READ, Privilege.JCR_WRITE, Privilege.JCR_MODIFY_ACCESS_CONTROL};
Principal principal = ... /* any implementation, referring to a username or group name */
Session session = ...
AccessControlManager acm = session.getAccessControlManager();
// Convert the privilege strings to Privilege instances ...
Privilege[] permissions = new Privilege[privileges.length];
for (int i = 0; i < privileges.length; i++) {
permissions[i] = acm.privilegeFromName(privileges[i]);
}
AccessControlList acl = null;
AccessControlPolicyIterator it = acm.getApplicablePolicies(path);
if (it.hasNext()) {
acl = (AccessControlList)it.nextAccessControlPolicy();
} else {
acl = (AccessControlList)acm.getPolicies(path)[0];
}
acl.addAccessControlEntry(principal, permissions);
acm.setPolicy(path, acl);
session.save();