级别: 中级 Tim Freeman, Globus 开发人员, Chicago 大学
Rachana Ananthakrishnan, Globus 开发人员, Argonne National Laboratory
2005 年 11 月 21 日 本文将介绍 Globus Toolkit 4.0 （GT4）中的授权选项和架构，并介绍如何开发自己的定制授权模型。作者将逐一介绍 GT4 的授权架构和模块接口，并介绍几种可以实现不同授权算法和情景的方法。
简介
授权是确定一个具有特定标识或一组属性的实体具有某种权限来对特定的资源执行特定操作的过程。这个步骤就发生在认证之后，认证是建立实体标识的过程。
在 Web 服务中，当对服务调用某个操作时，服务器就可能会对客户机进行授权。这称为服务器端（server-side） 的授权。类似地，客户机也可以在调用之前或调用过程中对服务器进行授权，这称为客户机端（client-side） 授权。本文将重点介绍 GT 中的服务器端授权框架。
GT4 授权概述
在 GT4 的安全性框架中，每种授权机制都表现为确定某个实体是否可以执行某个操作。授权机制是在称为决策点（Policy Decision Point，PDP） 的地方执行的。例如，如果我们指定了 gridmap 授权，那么就会在内部实例化一个 GridmapPDP，并在执行服务代码之前执行这个过程：
图 1. Gridmap PDP
即使只有一个 PDP（如上图所示），在内部也会配置一个 PDP 链，其中每个 PDP 都会独立地作出一个决定。整个框架中的授权引擎然后就可以使用一种策略合并算法将每个 PDP 所返回的决定组合起来，生成一个最终的决定。图 2 给出了一个 PDP [0..n] 列表，每个都返回一个 PERMIT 或 DENY 决定。
图 2. PDP 链
这个授权链可以在 Web 服务资源框架（WSRF）资源、服务或容器级别进行配置，要使用的链是按照优先级的顺序进行选取的。如果没有指定资源级的链，就使用服务级的链；如果服务级的链也没有指定，那么就使用容器级的链。
GT4 的实现使用了拒绝覆盖（deny override） 作为合并算法，这就意味着如果整个链中有任何一个 PDP 返回 DENY 决定，那么这个请求就被拒绝了。而且，一旦 PDP 返回 DENY 之后，整个链中后面的 PDP 也就不会继续计算了。只有在整个链中的所有 PDP 都返回 PERMIT 时，这个框架才会返回 PERMIT。我们也可以模拟一个允许覆盖算法，这在 模拟允许覆盖算法 一节中讨论。
还有另外一个实体称为策略信息点（Policy Information Point，PIP）。PIP 负责搜集有关调用者的信息，但是它并不返回任何授权决定。将这个搜集过程分隔在我们的模块中非常有用，这样就可以对相同的搜集过程配置使用不同的授权算法和策略了。PIP 的例子有 Virtual Organization Membership Service（VOMS）PIP，它负责为某些属性来分析调用者的 VOMS 凭证；还有 Shibboleth PIP，这是一个远程的调用，负责检索 Security Assertions Markup Language（SAML）属性（请参阅 参考资料 中有关这两个例子的链接）。
GT 将 PIP 和 PDP 都称为拦截器（interceptor），在本文中我们会一直使用这个术语来代表 PIP 和 PDP。
有一点非常重要，由于 PIP 不会返回决策，因此它并不会影响到拒绝覆盖 算法的最终决定。但是 PIP 所搜集到的信息对于 PDP 来说都是可用的，也可以用于决策制定过程中。
各种授权机制的实现作为 GT4 的一部分，对于服务的开发者和管理员是可用的。在每种机制中，调用者的标识是从客户机用来与服务联系所使用的凭证中获得的。资源所有者的标识是从为资源、服务或容器配置的凭证中获得的，这种设置可以根据需要按照优先级的顺序进行设置。授权机制有：
-
self —— self 授权 PDP 只允许具有与资源所有者相同标识的调用者。
-
gridmap —— gridmap 授权 PDP 只允许那些具有在 PDP 配置的 gridmap 文件中列出的标识的调用者；gridmap 文件是一个访问控制列表，其中是所允许的调用者标识，每个标识都有一个或多个到本地用户名的映射。PDP 在允许之前，还要将实体映射到在 gridmap 文件中列出的本地用户名。
-
identity —— identity 授权 PDP 只允许那些具有在 PDP 中配置的特定标识的调用者。
-
host —— host 授权 PDP 只允许那些具有在 PDP 中配置的特定主机的调用者。主机标识是一种特殊格式的证书，它具有一个通用名（CN），对应于一个从 DNS 或某个配置的服务名中获取的名字。
-
samlCallout —— samlCallout 授权 PDP 通过由 Global Grid Forum (GGF) 的 OGSA-AuthZ 工作组所定义的一种协议来与一个 SAML 授权服务进行联系。只有那些从 SAML 授权服务接收到肯定的授权决定的调用者才会被允许。
-
userName —— userName 允许那些使用所配置的 Java Authentication and Authorization Service（JAAS）登录模块成功进行认证的用户。
有关这些授权方法的详细信息，请参阅 WS 认证和授权文档（请参阅 参考资料）。
编写定制授权插件
我们可以通过开发定制拦截器并在一个安全描述符中启用它们，这样就可以使用具有自己的授权逻辑的服务。
本节将一步步地介绍如何创建自己的拦截器。这些步骤可以划分为以下阶段：
- 实现 PDP 接口
- 从一个安全描述符中引用这个 PDP
- 测试 PDP
- 实现 PIP 接口
- 从一个安全描述符中引用这个 PIP
- 测试 PIP
- 在 PIP 与 PDP 之间对属性进行通信
- 添加拦截器的一个配置
在您自己编写类的时候，您可以下载并参考为本文所创建的样例授权包。
不管您是使用这个样例授权包，还是正在从零开发类，本文都假设您已经安装好了 GT4 Java™ 核心，并正确设置了 X.509 证书（请参阅 参考资料）。
实现 PDP 接口
我们首先来创建一个工作目录和类层次。在本文中所讨论的样例包中，PDP 可以在这个源文件中找到：interceptors/src/org/globus/sampleauthz/PermitOnlyPDP.java。我们创建了下面的方法来实现 GT org.globus.wsrf.security.authorization.PDP 接口。
这是一个“哑”实现的样例 ，通常都会返回允许：
清单 1. PermitOnlyPDP
package org.globus.sampleauthz;
import org.globus.wsrf.security.authorization.PDP;
import org.globus.wsrf.security.authorization.PDPConfig;
import org.w3c.dom.Node;
import org.globus.wsrf.impl.security.authorization.
exceptions.InvalidPolicyException;
import org.globus.wsrf.impl.security.authorization.
exceptions.AuthorizationException;
import org.globus.wsrf.impl.security.authorization.
exceptions.CloseException;
import org.globus.wsrf.impl.security.authorization.
exceptions.InitializeException;
import javax.security.auth.Subject;
import javax.xml.rpc.handler.MessageContext;
import javax.xml.namespace.QName;
public class PermitOnlyPDP implements PDP {
static Log logger = LogFactory.getLog(
PermitOnlyPDP.class.getName());
public boolean isPermitted(Subject subject,
MessageContext ctx,
QName operation)
throws AuthorizationException {
logger.debug("decision = PERMIT");
return true;
}
public void initialize(PDPConfig pdpConfig,
String name,
String id)
throws InitializeException {
//
}
public void close() throws CloseException {
//
}
public String[] getPolicyNames() {
return null;
}
public Node getPolicy(Node node)
throws InvalidPolicyException {
return null;
}
public Node setPolicy(Node node)
throws InvalidPolicyException {
return null;
}
}
|
这个类是一个非常好的 PDP 的例子。isPermitted 方法就是返回授权决定的方法，对于 PERMIT，它返回 true；对于 DENY，则返回 false。正如您可以在清单 1 中所看到的一样，每次调用 isPermitted 时，它都会返回 PERMIT，这并没有太大用处。
在本文中，我们要忽略 close、getPolicyNames、getPolicy 和 setPolicy 方法，只重点介绍 isPermitted 和 initialize 方法。
注意一下记录日志的代码。要查看这些代码，请编辑 $GLOBUS_LOCATION/container-log4j.properties，添加一行对应于您的 Java 包的 DEBUG 的代码（前缀是 log4j.category）。例如，下面是这个样例授权包中对应的包层次：
log4j.category.org.globus.sampleauthz=DEBUG
|
将这个类编译成一个 .jar 文件，并将这个 jar 文件移动到 $GLOBUS_LOCATION/lib 目录中。如果您正在使用这个样例授权文件的代码，那么所需要做的是在顶层的目录中输入 ant deploy，在运行这个命令之前要确保已经设置了环境变量 GLOBUS_LOCATION。
从一个安全描述符中引用 PDP
在您可以使用 PDP 之前，必须要使用定制的授权类建立一个服务。我们首先要使用的一个好服务是 SecureCounterService。如果您正在使用这个样例授权包，那么在上面输入 ant deploy 时，就会为进行 PDP 测试而包括和部署 NoOpService。
如果您没有使用这个样例授权服务，那么在启用 PDP 之前，首先要验证您的安装在调用 SecureCounterService 之前已经正确设置了，在 GT4 中，这默认是已经安装的：
$ cd $GLOBUS_LOCATION
$ ./bin/counter-client -m conv -s\
https://localhost:8443/wsrf/services/SecureCounterService
|
如果您现在看到一个授权拒绝的错误，这是因为这个容器不是使用与客户机相同的凭证运行的。SecureCounterService 的默认授权设置是 "self"。要修改这种设置，请注销掉 $GLOBUS_LOCATION/etc/globus_wsrf_core_samples_counter/security-config.xml 中的 authz 元素，并重新启动这个容器以进行测试。
如果有什么问题，请参阅 GT4 管理员手册（参阅 参考资料）。
如果您正在使用这个样例授权包的 NoOpService 来测试授权，那么相关的安全描述符是 $GLOBUS_LOCATION/etc/no_op_service/noop-service-security-descriptor.xml，调用方法如下：
$ cd $GLOBUS_LOCATION
$ ./bin/noop -s https://localhost:8443/wsrf/services/NoOpService
|
在相应的安全描述符（$GLOBUS_LOCATION/etc/no_op_service/noop-service-security-descriptor.xml
$GLOBUS_LOCATION/etc/globus_wsrf_core_samples_counter/security-config.xml）中，启用基于您定制的类的授权。将其作为惟一的 authz 元素添加：
<authz value="ascope:org.globus.sampleauthz.PermitOnlyPDP"/>
|
其中 ascope 是一个随机标识符，: 将其范围与类分隔开来，后面的是 PDP 的完整类名。后面我们会对范围的使用详细进行介绍。
测试 PDP
在为您所使用的服务修改安全描述符之后，请重新启动容器，并调用这个服务，正如上面显示的一样。您应该允许调用这个操作，由于我们启用了上面的日志功能，在运行容器的终端中您应该可以看到 isPermitted 方法中的 decision = PERMIT 日志行，这是 logger 的默认输出流。
实现 PIP 接口
在与 PermitOnlyPDP 相同的类层次中，添加一个类来实现 GT4 org.globus.wsrf.security.authorization.PIP 接口：
清单 2. 简单的 PIP
package org.globus.sampleauthz;
import org.globus.wsrf.security.authorization.PIP;
import org.globus.wsrf.security.authorization.PDPConfig;
import org.globus.wsrf.impl.security.authorization.
exceptions.AttributeException;
import org.globus.wsrf.impl.security.authorization.
exceptions.CloseException;
import org.globus.wsrf.impl.security.authorization.
exceptions.InitializeException;
import javax.security.auth.Subject;
import javax.xml.rpc.handler.MessageContext;
import javax.xml.namespace.QName;
public class SamplePIP implements PIP {
static Log logger = LogFactory.getLog(
SamplePIP.class.getName());
public void collectAttributes(Subject subject,
MessageContext ctx,
QName operation)
throws AttributeException {
logger.debug("SamplePIP called");
}
public void initialize(PDPConfig pipConfig,
String name,
String id)
throws InitializeException {
//
}
public void close() throws CloseException {
//
}
}
|
重新编译生成新的 jar 文件，并替换 $GLOBUS_LOCATION/lib 中的 jar 文件。如果像上面一样，正在使用这个样例认证包，则在输入 ant deploy 时就会部署这个类。
从一个安全描述符中引用这个 PIP
在所使用的服务的安全描述符中，将整个 PIP 类添加到授权链中，这样它就像下面一样了：
<authz value="ascope:org.globus.sampleauthz.SamplePIP
pdpscope:org.globus.sampleauthz.PermitOnlyPDP"/>
|
授权链（authorization chain） 是一个在一行中运行多个拦截器的配置。上面这个服务的授权链现在配置为首先运行定制的 PIP，然后再运行定制的 PDP。
图 3. PIP 和 PDP 链
您可以构造任意的授权链，但是重要的是 PIP 和 PDP 的执行次序取决于在授权链配置中指定的次序。您必须在这个链中使用空格将每个类分隔开来。
如果一个实现了 PDP 接口的拦截器（在本例中是 PermitOnlyPDP）返回一个 DENY 决定，那么处理过程就停止了。
测试 PIP
现在我们已经配置好了测试服务的安全描述符，接下来要重新启动容器并重新调用这个服务。在运行容器的终端中您应该可以看到 collectAttributes 的日志行，这是默认的日志输出流。
在 PIP 与 PDP 之间对属性进行通信
现在我们已经有了一个定制的 PIP，那么它有什么用处呢？PIP 用来搜集属性。由于我们可以控制这两个拦截器，因此可以为 PIP 建立一个知名的位置，将属性保存在 PDP 可以找到的位置。但是如果您正在对一个已经存在的 PIP 开发一个 PDP，那么您就需要参考它的文档，了解如何从 PIP 中检索属性和其他信息。
我们的 PIP 会将属性添加到调用者的公共凭证上。将下面的代码添加到 SamplePIP 的 collectAttributes 方法中。所包含的样例授权包中的 SamplePIP 类中已经将一些代码注释掉了，现在需要恢复，正如代码注释中所显示的一样。
清单 3. 将属性添加到调用者的凭证中
Attribute attribute = new Attribute("manager");
subject.getPublicCredentials().add(attribute);
logger.info("Found an attribute of the caller: "
+ attribute.getAttribute());
|
您需要创建一个 Attribute 类，并将其导入。上面显示的例子已经包括到了这个样例授权包中。这个类只是一个简单的类，它在构造函数中可以接受一个 String，并提供一个 getter 方法来检索 String。您可以将任何类实例添加到这些凭证中。请确保对适当的 instanceof 进行相应的检索过程检查。
现在您已经将一个属性添加到了该主题的凭证中，并从 PDP 中检索属性，正如下面的例子所显示的一样。如果您决定要使用一个不同的对象与 PDP 进行通信，请使用一个不同的 instanceof 和 casting 机制。
如果找到一个值为 manager 的属性，那么下面的代码就会返回 PERMIT；否则就返回 DENY。您可以编辑 PIP 中的属性值，并重新编译/部署来查看拒绝的情况。下一节介绍拦截器如何利用这些配置，从而减少重新编译的需要。
清单 4. ManagerPDP：从调用者的凭证中检索属性
public class ManagerPDP implements PDP {
static Log logger = LogFactory.getLog(
ManagerPDP.class.getName());
public boolean isPermitted(Subject subject,
MessageContext ctx,
QName operation)
throws AuthorizationException {
Attribute attr = null;
Set credSet = subject.getPublicCredentials();
Iterator creds = credSet.iterator();
while (creds.hasNext()) {
Object o = creds.next();
if (o instanceof Attribute) {
attr = (Attribute) o;
break;
}
}
if (attr != null) {
logger.info("Found an attribute of the" +
"caller: " + attr.getAttribute());
if ("manager".equals(attr.getAttribute())) {
logger.debug("decision = PERMIT");
return true;
}
}
logger.debug("decision = DENY");
return false;
}
|
要使用这个 PDP 取代 PermitOnlyPDP，请为您的测试服务来修改安全描述符，如下所示：
<authz value="bscope:org.globus.sampleauthz.SamplePIP
mscope:org.globus.sampleauthz.ManagerPDP"/>
|
要进行测试，请重新编译并生成 jar 文件，并用其替换 $GLOBUS_LOCATION/lib 中的 jar 文件。如果您正在使用这个样例授权包，就需要在这个样例授权包的顶层目录中再次输入 ant deploy。
重新启动容器，并调用所保护的服务，再次查看日志行的内容。
添加一个拦截器的配置
通常，我们需要允许使用用户指定的值来对拦截器进行配置。经常使用的配置文件的例子包括策略文件名、要联系的服务的 URL、数据库登录信息以及定制行为的标记。
initialize 方法是在加载拦截器时调用的，可以用来建立配置。PIP 和 PDP 接口都具有相同的 initialize 方法，这我们在上面已经看到了。传递给 initialize 方法的 PDPConfig 被用来访问配置信息。
PDPConfig 是一个对实际的存储设备进行抽象并对配置属性进行检索的接口。GT4 发行版中包含了一个对这个接口的实现，它可以从部署描述符、服务部署描述符和内存中的全局描述符部分中提取信息，这是对所有配置信息的一个 hash 值。在本文中，我们假设 PDPConfig 对象是从服务部署描述符中提取配置信息。如果拦截器需要从其他地方提取配置信息，那么就可以编写并使用用户定义的 PDPConfig 实现。
为了示范起见，我们要向 PIP 中添加一个简单的配置，告诉它要为调用者（任何调用者）提供哪些属性。
在 $GLOBUS_LOCATION/etc/<your_service> 中找到测试服务的部署描述文件：
-
SecureCounterService 的 wsdd 是 $GLOBUS_LOCATION/etc/globus_wsrf_core_samples_counter/server-config.wsdd
-
NoOpService 的 wsdd 是 $GLOBUS_LOCATION/etc/no_op_service/server-config.wsdd
在这个文件中，编辑适当的服务配置：
<parameter name="bscope-attribute" value="notmanager"/>
|
上面提到的 scope 设置现在就可以使用了。在配置授权链时，您必须为每个拦截器都列出一个范围。这个范围就是授权机制 "context"，它用来将这些授权机制与该链中的相同实现类区别开来。在搜索配置时，拦截器提供了范围 String，以及 PDPConfig.getProperty() 方法的参数名。
例如，您可以为一个处理 gridmap 文件的 PDP 使用这种实现，它为每个都配置了不同的 gridmap 文件。因此在这个部署描述符中，您可能会看到 scope1:gridmapFile 和 scope2:gridmapFile。尽管在这两种情况中参数名是相同的（gridmapFile），PDP 会根据已经初始化的范围来使用正确的参数。在我们使用的例子中，参数名是 attribute，其范围是 bscope。
在您的代码中，添加一个 String 类型的实例变量 attribute，其初始值是 null。将这个变量或类似的代码添加到 PIP 的 initialize 方法中。如果您正在使用下载的代码，请在 SamplePIP 类中注释掉对应的代码：
清单 5. 检索部署描述符参数
try {
Object attr =
pipConfig.getProperty(name, "attribute");
if (attr == null) {
logger.debug("no attribute " +
"configuration, default is 'manager'");
this.attribute = "manager";
} else {
this.attribute = (String) attr;
logger.debug("found attribute configuration: '"
+ this.attribute + "'");
}
} catch (Exception e) {
throw new InitializeException(
"Problem initializing SamplePIP", e);
}
|
name 变量被传递到 initialize 方法中，范围值是在授权链设置中配置的。PDPConfig 类型的 pipConfig 变量也会传递到 initialize 方法中，这样可以获取拦截器的配置。
从上面的代码中我们可以清晰地看出，当部署描述符没有配置一个具有特定范围的参数（传递给 getProperty 的 name）和参数名（传递给 getProperty 的 attribute）时，就会使用默认的 manager 值。
另外，由于我们正在使用这个实例变量，而不是硬编码的 String，所以可将代码修改为引用 this.attribute，而不是硬编码的 manager。在这个样例代码中，这些修改可以在代码注释中使用。
根据部署描述符中的 PIP 参数是否有值 manager，ManagerPDP 所返回的授权可能分别是允许或拒绝。在上面的例子中，在配置中包括 notmanager 会导致结果是拒绝；将其修改为 manager 就会导致结果是允许，这是因为 ManagerPDP 的策略只允许那些具有 manager 属性的调用者。
还能实现什么功能？
虽然我们可以实现更多功能，但是上面的技术还可以应用得更加广泛。本文尚未介绍的一个主题是对基于对服务调用的特定操作授权策略的支持。注意 PDP 方法的 isPermitted 中的 QName 类型的 operation 参数。如果使用了限定名称，将这个操作名与策略进行匹配就非常简单：可以使用 operation.toString().equals() 方法。
我们还可以表示基于 Web 服务消息内容的策略，这样可以在到达服务之前截获调用。在 Workspace Service 的代码中，类 BanlistPDP 给出了一个在 approveAdditions 方法中处理消息内容的例子。
有两个非常有用的特性如下：在运行时使用服务代码编程实现对拦截器配置的设置，以及编程使用特定的授权链来保护特定的 WSRF 资源。这已经超出了本文的范围，更多信息请参阅 GT4 WS Authentication 和 Authorization 文档（参阅 参考资料）。
模拟允许覆盖授权算法
由于 GT4 授权链处理算法实现了一个拒绝覆盖 链，如果 PDP 返回 DENY，处理过程就停止了，这个链的值就是 DENY。在将来的 Globus Toolkit 版本中，可以使用一个允许覆盖 链，如果 PDP 返回 DENY 或另外一个授权决定 NOT APPLICABLE，那么这个过程就不会停止，但是只有在 PDP 返回 PERMIT （或者已经遍历完整个链之后）时，这个处理过程才会停止。在本节中，我们将讨论一个允许覆盖算法。
在 PDP 所返回的决定的 OR 非常重要时，一般都需要允许覆盖链。例如，考虑这样一种情景：配置了两个 PDP，一个是逻辑策略 PDP，另外一个是远程 PDP，而且按照这种次序使用。在允许覆盖中，如果第一个 PDP 返回允许，那么这个过程就可以结束了。这节省了调用远程 PDP 的时间，该调用会增加一个数量级的处理时间。如果本地策略允许，这种机制目前在 GridShib 中可以用来为 GT 授权处理模块（请参阅 参考资料）来防止调用属性服务器。
为了支持允许覆盖链，可以使用一种简单的技术来配置主（master） PDP。主 PDP 然后可以直接调用其他的 PIP 和 PDP，而不是让授权引擎调用它们。主 PDP 是授权链配置中的惟一 PDP，配置引擎只从这个主 PDP 上接收 PERMIT 或 DENY。
为了展示这种用法，我们使用 SamplePIP 和 ManagerPDP 作为从 PDP。我们还假设有另外一个 PDP，名为 RemotePDP，它通过访问一个远程授权服务来返回一个决定：
图 4. 具有从 PDP 的主 PDP
将主 PDP 的内部工作放到单独的 PIP 和 PDP 看起来似乎非常浪费。如果需要，这样做就可以自行使用拦截器了。另外，将来当新属性和授权引擎可以支持更复杂的行为时，您的主 PDP 的特定逻辑就可能是多余的；将这些逻辑放入单独的拦截器中可以帮助将来对代码进行检验。
一个简要的代码的例子应该可以让这种技术变得更加清晰。这些从拦截器是在 MasterPDP 的 initialize 方法进行初始化的，实际上是在 isPermitted 方法中进行调用的。
清单 6. 在 MasterPDP 中对从拦截器进行初始化
public void initialize(PDPConfig config, String name,
String id)
throws InitializeException {
// Sample PIP
this.PIP = new SamplePIP();
try {
this.PIP.initialize(config, name, id);
} catch (InitializeException e) {
logger.error("Problem initializing PIP: " + e.getMessage());
this.PIP = null;
throw e;
}
// ManagerPDP
this.managerPDP = new ManagerPDP();
try {
this.managerPDP.initialize(config, name, id);
} catch (InitializeException e) {
logger.error("Problem initializing PDP: " + e.getMessage());
this.PIP = null;
throw e;
}
// RemotePDP
this.remotePDP = new RemotePDP();
try {
this.remotePDP.initialize(config, name, id);
} catch (InitializeException e) {
logger.error("Problem initializing PDP: " + e.getMessage());
this.PIP = null;
throw e;
}
}
|
然后在主 PDP 的 isPermitted 方法中，PIP 和 PDP 都只有在必需的时候才会被调用：
清单 7. 在 MasterPDP 中调用从拦截器
try {
this.PIP.collectAttributes(subject, ctx, operation);
} catch (AttributeException e) {
logger.error("error calling PIP: " + e.getMessage());
}
boolean decision = this.managerPDP.isPermitted(subject, ctx, operation);
if (decision) {
return true;
} else {
// first PDP did not return permit, try remote PDP
return this.remotePDP.isPermitted(subject, ctx, operation);
}
|
一旦调用必需的 PIP 之后，就可以在主 PDP 的 isPermitted 方法中实现授权逻辑了，而不是调用各个 PDP isPermitted 方法。但是上面的设计可以更好地分隔授权逻辑，并能更好地实现代码的重用。
如果您要允许多个入口指向您的 PIP，可以提供一个对普通 collectAttributes 方法的替代品，它会直接返回您要查找的信息。在调用这个方法时，如果 PIP 也会将这个属性放到一个知名的位置，这样就可以更好地利用它们。
GT 授权引擎的将来
我们现在正在增强 GT4 的授权框架来更好地利用基于属性/角色的授权，并可以对细粒度的权限委托的表示提供更灵活的支持。
对于属性搜集模块的增强可以允许这个框架处理属性的不同表示，PDP 可以使用策略中的属性值。要允许这种特性，就需要使用这些属性的一种标准格式在整个链中对它们进行通信。
权限委托是网格计算中的另外一个关键特性，也是 Globus Toolkit 目前的一种关键特性，它是使用 X.509 代理证书实现的。我们正在构建一个更加复杂的授权引擎，它可以实现细粒度的权限委托的表示。这个框架可以用来从原来的请求者中找到有效的决策链，这可以通过使用不同的策略语言表示的不同授权语句进行计算。
在将来的发行版本中，我们还要计划添加一些特性，例如可插入授权引擎，属性懒惰搜集，决策/属性缓存，以及有关属性/拦截器的元数据 —— 以及一些可以帮助提高性能的特性。
下载
参考资料 学习
获得产品和技术
-
下载 Globus Toolkit，这是一个开放源码的软件工具包，可以用来构建网格系统和应用程序。
-
GridShib 是一个具有网格技术的集成联邦授权基础设施（Shibboleth），可以为分布式科学社团提供基于属性的授权。
讨论
作者简介  | | | Tim Freeman 与 Rachana Ananthakrishnan 一起合作开发了很多 Globus 授权项目，包括 SAML 和 VOMS 的属性处理，以及将来的属性和授权框架。他还将动态执行环境（workspace）集成到了 Globus Toolkit 中，这是使用 UNIX 帐号和经典的虚拟机技术实现的。 |
| | | Rachana Ananthakrishnan 开发了目前 Java Globus Tookit 4.0 核心中的授权引擎，以及很多插件，现在她负责领导所有的 Java Globus Tookit 安全性开发的工作。她还从事了 GT3 中安全性基础设施方面的工作，开发了 Community Authorization Service（CAS）以及 GT4 Delegation Service。现在，她正与 GT 小组一起设计和开发下一代的属性和授权框架。 |
对本文的评价
| 
