编写自己的登录与访问控制模块

jungleford如是说 安全性是Java鼓吹得最多的特性之一，的确，Java的安全特性涵盖了从应用级别到语言级别乃至JVM本身。以前大家都知道有个Sandbox，但仅有Sandbox尚不能满足，或者说不能很方便地做到我们所需要的全部安全需求，譬如现在一个系统首先起码需要一个登录功能，更进一步的话，还需要对用户访问资源的行为进行约束，下面我想大致讲一下Java是怎样做这些事情的，基本上是一个总结或者说是“读后感”的性质，同时给出一个简单的实现例子，这个例子其实还是模仿人家的，呵呵……
1．Java的访问控制机制
谈到访问控制，或者说“授权”，这里有两层含义，一是从资源的角度，这个socket端口是否被允许操作？这个文件是可读的？可写的？还是可执行的？还是以上都行？这就是我们在UNIX下用“ls -l”命令列出当前目录下文件时，那些“-rwx-”之类的含义；二是从访问者的角度，我想通过80端口看Web上新浪欧洲杯的新闻，在这个系统中有没有这个资格？我想播放D盘上一个名为“friends.rm”的视频文件，我得到了访问这个文件的权限了吗？我有运行播放器的权限吗？ Java在访问控制策略上同时考虑了这两方面内容，你说“不对呀，我用FileOutputStream写文件，用Socket类连接远程主机都用得好好的，没什么限制呀”，这我们得先谈谈什么叫做“安全管理器”（SecurityManger）。安全管理器从JDK 1.0就开始有了，多古老啊！Java从设计的那一天开始就考虑了安全因素，安全管理器是Sandbox的最重要的一个部分，也是访问控制的总协调者，我们能够在通常情况下正常使用网络和文件，那是因为当启动application的时候（注意是application，不是Applet！），如果你不加“-Djava.security.manager”选项，JVM是不会启动Sandbox的，这时你可以“为所欲为”，而不会碰到SecurityException之类的异常；一旦加入了“-Djava.security.manager”选项，你就会发现有一连串的异常出现喽！Exception in thread "main" java.security.AccessControlException: access denied (……)……Java内置了一个默认的安全策略，这种情况下安全管理器首先装载的是这个默认的策略，不信啊，不信你检查一下你的“%JAVA_HOME%\jre\lib ecurity\”目录，是不是有个叫“java.policy”的文件？用notepad打开看看：

// Standard extensions get all permissions by defaultgrant codeBase "file:${java.home}/lib/ext/*" { permission java.security.AllPermission;};// default permissions granted to all domainsgrant { // Allows any thread to stop itself using the java.lang.Thread.stop() // method that takes no argument. // Note that this permission is granted by default only to remain // backwards compatible. // It is strongly recommended that you either remove this permission // from this policy file or further restrict it to code sources // that you specify, because Thread.stop() is potentially unsafe. // See "http://java.sun.com/notes" for more information. permission java.lang.RuntimePermission "stopThread"; // allows anyone to listen on un-privileged ports permission java.net.SocketPermission "localhost:1024-", "listen"; // "standard" properies that can be read by anyone permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; permission java.util.PropertyPermission "java.vendor.url", "read"; permission java.util.PropertyPermission "java.class.version", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "os.version", "read"; permission java.util.PropertyPermission "os.arch", "read"; permission java.util.PropertyPermission "file.separator", "read"; permission java.util.PropertyPermission "path.separator", "read"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "java.specification.version", "read"; permission java.util.PropertyPermission "java.specification.vendor", "read"; permission java.util.PropertyPermission "java.specification.name", "read"; permission java.util.PropertyPermission "java.vm.specification.version", "read"; permission java.util.PropertyPermission "java.vm.specification.vendor", "read"; permission java.util.PropertyPermission "java.vm.specification.name", "read"; permission java.util.PropertyPermission "java.vm.version", "read"; permission java.util.PropertyPermission "java.vm.vendor", "read"; permission java.util.PropertyPermission "java.vm.name", "read";};可以看到，JVM给沙箱内的application分配的权限仅限于中止线程，监听1024以上的TCP端口，以及对一些系统属性的读取权限，像一般的socket操作和文件操作的权限都没有。 了解了安全管理器的概念以后我们回到授权问题上来。对用户来说，最担心的莫过于机器中病毒，病毒本质上是一种恶意的程序，所以访问控制首先是要对代码的权限进行控制，上面我一直都在谈Sandbox，也就是所谓的“沙箱”，熟悉Java安全性发展历史的朋友大概对它不会陌生，初期的Java是采用这样一种安全策略，即：本地代码是可信的，而远程代码是不可信的，譬如applet是一种从网络上下载到本地并在浏览器上运行的一段远程代码，因而是不可信的，所以早期的applet被完全置于Sandbox当中，得到的权限是非常有限的；在1.0以后，直至Java 2出现之前，安全策略作了一些灵活的改变，applet不再是完全被歧视的“二等公民”了，因为有了签名applet，用户可以选择信任这种经过签名的applet，从而applet也可以做一些以前被认为是“出格”的事情；到了Java 2，情况又变了，以前一向被信任的本地代码似乎也变得不是那么可靠了，这还真说不准，难保谁不会在你出去跟女朋友逛街的时候，偷偷溜进来在你机器上拷个病毒什么的 ^_^ ，这样本地代码就落到了和远程代码相等同的地位了，这是比较符合现实世界场景的，在Java 2中的安全策略被称之为“可配置的安全策略”，任何代码，只要是通过安全管理器访问，就必须为它预先设定好访问权限，在这个之外的资源还是别的什么东东，对不起，java.security.AccessControlException: access denied……此路不通！

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有