jaas:默认Policy的实现及Policy语法

 
 
Default Policy Implementation and Policy File Syntax
Last Modified: 25 September 2003
Java 应用程序运行时的 环境由一个Plolicy对象代表,特别是由一个Policy类子类的一个对象代表。
Policy 使用的策略信息的地址取决于Policy的实现,Policy参考实现包括了来自静态策略config文件的信息。
Policy Changes in the Java TM 2 SDK, Standard Edition, v 1.4

Note: Starting with this version (v 1.4), policy files used by the default policy implementation must be encoded in the UTF-8 encoding scheme. You can use the native2ascii tool to assist with this conversion.

策略可以在一个或多个策略文件中。.有一个系统策略文件和一个可选的用户策略文件,策略参考实现在第一次执行他的getPermissions方法,或任何执行更新方法时实例化,实例化过程解析policy文件。
默认情况下,系统策略文件位于
java.home /lib/security/java.policy (Solaris)
java.home /lib/security/java.policy (Win32)
系统策略文件允许系统级别的代码许可。随sdk安装的策略文件grant对标准扩展的所有许可,读取安全不敏感的标准属性,如"os.name" and "file.separator"等
用户策略文件默认存在于
user.home /.java.policy  (Solaris)
user.home /.java.policy (Win32)
当Policy实例化时,系统策略先加载,如果没有策略文件,将使用一个内置的策略。这个内置的策略和安装jre时的策略是一样的
策略文件的位置在安全属性文件security properties file,中指定,它位于
java.home /lib/security/java.security (Solaris)
java.home /lib/security/java.security (Win32)
策略文件的位置由形如    policy.url. 的属性值决定
其中,n是数字,在一行内:
policy.url.n=URL
如系统默认的安全策略和用户策略如下:
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
. 可以指定形如 http://的url,也可以注释掉或改变第二条来禁止用户的策略文件。以上的数字n必须连续才能生效,否则不会被加载
Specifying an Additional Policy File at Runtime
可以在运行程序时指定附加的或不同的策略,通过java -Djava.security.manager -Djava.security.policy=someURL SomeApp 可以让指定的someURL附加在所有策略属性文件(java.policy中指定的策略文件之后。
当使用(注意双等号)    java -Djava.security.manager -Djava.security.policy==someURL SomeApp
则只有指定的策略生效,其余的策略都被忽略 。
当想要像appletviewer传递策略时,如果安全属性文件的 "policy.allowSystemProperty"值为false(默认值),则传递的策略将被忽略,
可以用实现了getPermissions方法的Policy子类来替换原来的策略参考实现类(Policy reference implementation class)。 这需要编辑安全属性文件lib/security/java.security, 
    policy.provider=PolicyClassName
PolicyClassName 必须使用全名称. 默认是:
    policy.provider=sun.security.provider.PolicyFile
可以改为   policy.provider=com.mycom.MyPolicy 来定制
源代码可以读取来自源代码url处的文件,而不需许可。
策略文件可能包含一个"keystore"和零个以上的 "grant" entries.
Keystore Entry
Keystore 是一个包含私钥 和 经过链式验证了公钥的证书库 ,该条目被用来查找grant条目中签名者的公钥。
如果测律文件的grant条目指名了一个签名者的别名,keystore条目必须出现。或者grant条目指明了特征别名,就必须只有一个keystore/keystorePasswordURL 条目,如果有多个条目,之后的会被忽略
有如下语法:
keystore "some_keystore_url", "keystore_type", "keystore_provider";
keystorePasswordURL "some_password_url";
some_keystore_url 指明了URL
some_password_url 指明了密码位置
注意,由 some_keystore_url构建的输入流,将被传递给KeyStore.load 方法.
如果不是基于文件的,应该明确的赋值NONE。URL应该是相对于策略文件位置的。
如策略属性文件中指明了安全策略文件:
    policy.url.1=http://foo.bar.com/fum/some.policy
且该安全策略文件有条目:
    keystore ".keystore";
则实际上 keystore 将从
    http://foo.bar.com/fum/.keystore
加载。
当然url也可以是绝对路径的。
keystore type 定义了keystore信息的存储和数据格式,以及keystore的私钥算法,默认类型时“JKS”。
Grant Entries
被执行的代码总有来源.codesource不仅包括来源url,而且还包含对证书的引用,证书中包含公钥。证书通过别名被引用。代码也被认为作为一个或以上的特征来执行。
基本格式如下
 grant signedBy "signer_names", codeBase "URL",
        principal principal_class_name "principal_name",
        principal principal_class_name "principal_name",
        ...
 {
 
      permission permission_class_name "target_name", "action",
          signedBy "signer_names";
      permission permission_class_name "target_name", "action",
          signedBy "signer_names";
      ...
 };
       
The SignedBy , Principal , and CodeBase Fields
signedBy, codeBase, and principal 是可选的,且次序无关。
A signedBy 是keystore中一个证书的别名。 表示授予有此证书的代码权限.
可以逗号分开多个别名,如 "Adam,Eve,Charles", 表示"signed by Adam and Eve and Charles";是 AND关系.更精确的 "Code signed by Adam" 表示"jar文件中的代码,而此jar文件是被私钥签名过的,而对应的公钥证书的别名是Adam ".
signedBy 域是可选的,如果被删除,意味着任何签名者。
 principal 指明了一个 class_name/principal_name 对,该对 必须出现在执行线程的principal set中. principal set 和执行代码通过Subject 相关联。如果被删除意味着许可任何特征。
如果principal 的 class_name/principal_name 对由一个单独的引号括起来的字符串,那么他被当作一个keystore的别名。 这个 keystore 将会被查找响应的 X509证书。如果找到,则 principal class_name被自动的设为 javax.security.auth.x500.X500Principal,而 principal_name被自动的设为证书中subject的别名. 如果没有找到证书的映射,则此grant条目被忽略。
Note: a codeBase value is a URL ,所以应该总是使用斜杠作为分隔符即便在Win32 系统上,所以 Win32 的 C:/somepath/api/,应该在codebase中表示为
    grant codeBase "file:/C:/somepath/api/" {
        ...
    }
Codebase 值的含义取决于字符串尾部的 符号 / 所有类。/*所有文件,/-所有文件包括子目录。
Codebase URL of Downloaded Code
Codebase URL in Policy
Match?
java.sun.com/people/gong/
java.sun.com/people/gong
Y
java.sun.com/people/gong/
java.sun.com/people/gong/
Y
java.sun.com/people/gong/
java.sun.com/people/gong/*
Y
java.sun.com/people/gong/
java.sun.com/people/gong/-
Y
java.sun.com/people/gong/appl.jar
java.sun.com/people/gong/
N
java.sun.com/people/gong/appl.jar
java.sun.com/people/gong/-
Y
java.sun.com/people/gong/appl.jar
java.sun.com/people/gong/*
Y
java.sun.com/people/gong/appl.jar
java.sun.com/people/-
Y
java.sun.com/people/gong/appl.jar
java.sun.com/people/*
N
java.sun.com/people/gong/
java.sun.com/people/-
Y
java.sun.com/people/gong/
java.sun.com/people/*
N
The Permission Entries
A permission entry 一定以permission开头,permission_class_name 应该是一个确定的permission 类型,如java.io.FilePermission 或java.lang.RuntimePermission. 需要为许多permission指明"action",而有些则不需要。.
signedBy 名值对对 permission条目是可选的。如存在,则暗示一个签名许可。,即,permission 类自己必须由给定的别名签名。如:
 grant {
      permission Foo "foobar", signedBy "FooSoft";
 }
如果Foo所在的jar文件,由FooSoft的证书签过,才会有许可,Foo.class是系统类的情况除外。
以上元素在permission语句总必须依次出现,且以分号结尾。permission语句中大小写不重要,但permission_class_name 或任何作为值传入的字符传来说,还是重要的。
Note Regarding File Path Specifications on Win32 Systems
Note: 当不在 codeBase URL 中时,文件路径指定如下
 grant {
      permission java.io.FilePermission "C://users//cathy//foo.bat", "read";
 };
例子
 grant signedBy "sysadmin", codeBase "file:/home/sysadmin/*" {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
      permission java.security.SecurityPermission "Security.setProperty.*";
 };
这表明只有符合一下条件,才能调用Security中的方法,来添加,移除provider或设置安全属性。
·   代码来自一个签名的jar。此jar在本地文件系统的 "/home/sysadmin/" 目录下.
·   签名能够被keystore中别名为"sysadmin"的公钥验证。
如果没有codebase,如下:
 grant signedBy "sysadmin" {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
 };
则所有签名能够被验证的类都可执行以上操作。
如果没有signer,如下
 grant codeBase "file:/home/sysadmin/-" {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
 };
则所有来自本地"/home/sysadmin/" 的类都有权限。
如既没有codeBase 也没有 signedBy,如下:
 grant {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
 };
则任何代码都有权限执行相关操作。
下面是一个 principal-based 条目.
 grant principal javax.security.auth.x500.X500Principal "cn=Alice" {
      permission java.io.FilePermission "/home/Alice", "read, write";
 };
允许任何有特征 X500Principal, "cn=Alice" 的客户代码读写 "/home/Alice".
 
 
 grant codebase "http://www.games.com",
        signedBy "Duke",
        principal javax.security.auth.x500.X500Principal "cn=Alice" {
      permission java.io.FilePermission "/tmp/games", "read, write";
 };
This allows code downloaded from "www.games.com", signed by "Duke", and executed by "cn=Alice", permission to read and write into the "/tmp/games" directory.
The following example shows a grant statement with KeyStore alias replacement:
 keystore "http://foo.bar.com/blah/.keystore";
 
 grant principal "alice" {
      permission java.io.FilePermission "/tmp/games", "read, write";
 };
"alice" will be replaced by
javax.security.auth.x500.X500Principal "cn=Alice"
assuming the X.509 certificate associated with the keystore alias, alice, has a subject distinguished name of "cn=Alice". This allows code executed by the X500Principal "cn=Alice" permission to read and write into the "/tmp/games" directory.
如果 安全属性文件的 "policy.expandProperties"被设为true,则可使用扩展,何字符串中都可使用,如${java.home}和{file.separator}.扩展符不能嵌套使用。
Note: 所有被扩展使用的属性如不存在,条目会被忽略。例如如果系统没有定义属性"foo" :
    grant codeBase "${foo}" {
        permission ...;
        permission ...;
    };
则该 grant条目被忽略。如果:
    grant {
        permission Foo "${foo}";
        permission Bar "barTarget";
    };
则 "permission Foo..." 条目被忽略.
如果
    keystore "${foo}";
则 keystore被忽略。
Win32 Systems, File Paths, and Property Expansion
先处理转移符号“//”,再处理扩展符号${}。所以最好使用${/},如:
    "${user.home}${/}foo.bat"
Policy 文件中也支持扩展的泛化形式。 permission 名称中可能有以下形式的字符串:
${{protocol:protocol_data}}
如果这样的字符串出现在permission名字中,protocol中的值决定了该发生扩展的精确类型,而 protocol_data 被用来帮助实现扩展。protocol_data 可能是空的,那样就可简单的写为以下形式:
${{protocol}}
默认policy文件的实现中支持两种protocols:
1.    ${{self}}
The protocol, self, 指明一个条目字符串中以principal名值对发生的替换。,精确的替换依赖于permissions 跟随的grant子句的内容。
如果grant子句不含任何principal信息, permission 就会被忽略 (包含${{self}} 于target names 的permissions 只有在基于principal的grant子句上下文中才有意义。如下的BarPermission 将总是被忽略:
       grant codebase "www.foo.com", signedby "duke" {
           permission BarPermission "... ${{self}} ...";
       };
  
 
如果grant有principal,那么, ${{self}} 将被同样的principal 信息替换,如下例${{self}} 将被替换为:javax.security.auth.x500.X500Principal "cn=Duke"
grant principal javax.security.auth.x500.X500Principal "cn=Duke" {
    permission BarPermission "... ${{self}} ...";
};
以逗号分割的principal列表,也将以同样的方式被复制。
2.    ${{alias:alias_name}}
The protocol, alias, 知名了一个 java.security.KeyStore 别名替换. The KeyStore used is the one specified in the KeyStore entry. alias_name 代表了 KeyStore中的一个别名.如:
keystore "http://foo.bar.com/blah/.keystore";
 
grant codebase "www.foo.com" {
    permission BarPermission "... ${{alias:duke}} ...";
};
上例中 X.509 证书可以从 foo.bar.com/blah/.keystore.获得。 假设 duke的证书指明了"o=dukeOrg, cn=duke" 作为subject 的区别名称,则${{alias:duke}} 被一下字符串替换javax.security.auth.x500.X500Principal "o=dukeOrg, cn=duke".
一下错误发生时,permission将被忽略:
 
o      没有 keystore条目
o      没有提供 alias_name
o      alias_name 的证书不能获得。can not be retrieved
o      证书不是x.509的
 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值