在版本1.2的安全体系结构中，对应于整个Java应用程序的一个访问控制策略是由抽象类 java.security.Policy的一个子类的单个实例所表示的。在任何时候，每一个应用程序实际上都只有一个Policy对象。获得许可的代码可以用一个新的Policy对象替换当前的Policy对象，这是通过调用Policy.setPolicy()并把一个新的Policy对象的引用传递给它来实现的。类装载器利用这个Policy对象来帮助它们决定，在把一段代码导入虚拟机时应该给它们什么样的权限。
安全策咯是一个从描述运行代码的属性集合到这段代码所拥有的权限的映射。在版本1.2的 安全体系结构中，描述运行代码的属性被总称为代码来源。一个代码来源是由一个 java.security.CodeSource对象表示的，这个对象中包含了一个java.net.URL,它表示代码库和代表了签名者的零个或多个证书对象的数组。证书对象是抽象类java.security.cert.Certificate的子类 的一个实例，一个Certificate对象抽象表示了从一个人到一个公钥的绑定，以及另一个为这个绑 定作担保的人（以前提过的证书机构}。CodeSource对象包含了一个Certificate对象的数组，因 为同一段代码可以被多个团体签名（担保)。这个签名通常是从JAR文件中获得的。
在版本1.2中’所有和具体安全管理器有关的工具和访问控制体系结构都只能对证书起作用， 而不能对“赤裸”的公钥起作用。如果附近没有证书机构，可以用私钥对公钥签名，生成一个 自签名的证书。Java 2 SDK 1.2中的keytool程序在生成密钥时，总是会产生一个自签名的证书。 例如’在本章上面给出的代码签名的例子中，keytool不仅产生了公钥/私钥对，还为别名friend和 stranger产生了自签名的证书。
权限是用抽象类java.security.Permission的一个子类的实例表示的。一个Permission对象有三个厲性：类型、名字和可选的操作。权限的类型是由Permission类的名字指定的，例如：java.io. FilePermission，java.net.SocketPermission,以及java.awt.AWTPermission。权限的名字是封装在Permission对象内的。例如，某个FilePermission的名字可能是“/my/finances.dat”，某个SocketPermission的名字可能是 “applets.artima.com:2000”，某个AWTPermission的名字可能是 ”“showWindowWithoutBannerWaming“。Permission对象的第三个属性是它的动作。并不是所有的权限都有动作。例如，FilePermission的动作是“read, write”，SocketPermission的动作是“accept，connect"。如果一个FilePermission的名字为/my/finances.dat，并且有动作 “read, write”， 那么它就表示对文件/my/finances_dat可进行读写操作。名字和动作都是由字符串来表示的。
Java API有一个很大的权限层次结构，表示了所有可能潜在危险的操作。可以根据自己的目 的，创建自己的Permission类来表示自定义的权限。例如，可以创建一个Permission类来表示对 属性数据库的特定记录的访问权限。定义自定义的Permission类也是一种扩展版本1.2的安全机 制来满足自己需要的方法。如果你创建了自己的permission类，可以像使用Java API中的 Permission类一样来使用它们。
在Policy对象中，每一个CodeSource是和一个或多个Permission对象相关联的。和一个 CodeSource 相关联的 Permission 对象被封装在java.security.PermissionCollection 的一个子类实例
中，类装载器可以调用Policy.getPolicy()来获得一个当前有效的Policy对象的引用。然后它们 可以调用Policy对象的getPermission ()方法，传入一个CodeSource,从而得到和那个 CodeSource对应的Permission对象的PermissionCollection。类装载器然后可以使用这个从Policy中得到的PermissionCollection来帮助判断应该给导入的代码授予什么权限。
策略文件：
java.security.Policy是一个抽象类，具体Policy子类的实现细节之一就是该子类的实例怎样知 道策略应该是什么。子类可以采取多种方法，例如对一个已序列化的Policy对象进行并行化，从 数据库中抽取策略，或者从文件中读取策略。由Sun提供的在Java 1.2平台下的具体Policy子类采 用了最后一种方法：在一个ASCII策略文件中用上下文无关文法描述安全策略。
一个策略文件包括了一系列grant子句，每一个grant子句将一些权限授给一个代码来源。在 上面已经讲过，一个代码来源包含了一个代码库和一系列签名，代码库是指出这个代码从那里 下载的URL。在策略文件中，签名用别名来代表，这些签名是保存在keystore文件中的签名者的 公钥。这个keystore可以在策略文件中用一个keystore语句显式说明。
策略文件的例子如CD-ROM中security/ex2目录下的policyfile.txt义件：
在这个policyfile.txt文件中，第一条语句是keystore语句:
keystore "ijvmkeys"；
这个keystore语句说明，密钥别名（策略文件其余部分将提到）指向存储在名为“ijvmkeys” 的文件中的证书。因为这个文件名没有包含路径，这个文件必须是存储在当前目录下——Java应 用程序使用该策略文件的启动目录。
这个策略文件中的第二条语句是一条grant语句：
grant signedBy "friend" {
permission java.io.FilePermission "question.txt", "read"; permission java.io.FilePermission "answer.txt" , "read";
})
这条语句将授予由别名为“friend”的实体签名的所有代码两个权限。被授予的权限是：读 取question.txt文件的权限，以及读取answer.txt文件的权限。因为这些文件名没有路径，所以它 们必须是存储在当前目录下的，也就是这个应用程序的启动目录。因为这个grant子句中没有提
到代码库，所以由friend签名的代码可以来自任何代码库。任何由friend签名的代码，不管是来自哪个代码库的，都将被授予对question.txt和answer.txt进行读操作的权限。
在策略文件中的第四条、也是最后一条语句仍然是一个grant语句：
grant codeBase "file:${com.artima.ijvm.cdrom.home}/security/ex2/*" {
permission java.io.FilePermission "question.txt","read";
permission java.io.FilePermission "answer.txt","read";
);
这条grant语句将两个权限授给所有从一个特定目录中装载的代码：对question.txt文件的读权限以及对answer.txt文件的读权限。这两个文件都必须在当前目录下，也就是这个应用程序的 启动目录。注意，这个grant子句没有指明任何签名者，所以，这个代码可以是被任何人签名的， 或者是未被签名的。只要它是从指定的目录下被装载的，它就可以被授予上面所列出的权限。
这条grant语句中的代码库URL采用了文件的形式：它包含了一个属性${com.artima.ijvm.cdrom.home}。如果要运行本章后面描述的AccessControl实例程序，必须将这个com.artima.ijvm. cdrom.home属性设置为本书附带的CD-ROM,或者是将这个CD-ROM移动后的目录。这个 Policy对象是基于policyfile.txt的内容被实例化的，在它为这个grant子句的CodeSource构建URL将考虑com.artima.ijvm.cdrom.home展性。