第九讲安全服务.pptVIP

内 容 一、动因 二、安全技术与安全体系 三、Java 的安全体系 四、J2EE的安全服务 一、动因 合作的前提之一 数据的存储、加工、传送过程中 皆需要进行保护 Security and Transaction Security and Openness Security and Safety 安全是一个涉及系统多个功能的 非功能性需求 分布式系统的安全隐患 分布式软件系统中客户与服务器之间存在 大量的消息交互 网络基本设施安全吗？ 硬件 软件 客户身份属实吗？ 客户对欲进行的操作有权限吗？ 不安全的后果 机密数据可能被窃取 公司规划 标书 员工薪资 健康数据 财产数据 数据可能被篡改 财务数据 测试结果 最终导致： 计算机信任度受损: 无法继续使用计算机系统 二、安全技术与安全体系 1、加密 2、认证 3、访问控制 4、审计 1、加密 就是信息的编码和解码 包括 保密性加密 完整性加密 四、J2EE的安全服务 减轻应用开发者（如构件生产者）在安全管理上的负担 通过EJB角色达到最大的覆盖率 容器厂商实现安全基础设施(infrastructure) 部署者和系统管理员指定安全策略(policy) 安全策略的设置更灵活 由组装者或部署者指定 而不是构件生产者开发时硬编码 保证EJB的可移植性 不同的服务器可能采用不同安全机制 构件生产者的安全责任 调用其它EJB EJB体系没有为构件生产者提供编程接口控制调用者的主体(Principal) 在不同EJB互相调用过程中传递的主体由部署者或系统管理员以特定于容器的途径建立 构件生产者和组装者只能在部署信息中描述相关的需求 访问资源 构件生产者的安全责任（续） 访问底层操作系统的资源 EJB体系没有定义访问OS资源的主体 EJB不能访问OS资源 EJB体系假设应用仅使用如数据库之类的资源管理器，不会直接使用OS级别的资源 推荐的编程风格 构件生产者在业务方法中 既不会实现安全机制，也不会硬编码安全策略 通过部署信息委托部署者和系统管理员 构件生产者的安全责任（续） 如何编程访问调用者的安全上下文 Caller’s security context 声明 安全管理一般由容器执行，对构件透明 只有在极少数情况下，业务方法才会访问安全上下文信息 在javax.ejb.EJBContext中定义了两个方法 java.security.Principal getCallerPrincipal(); Boolean isCallerInRole(String roleName); 如果调用请求中没有客户的安全上下文，则产生java.lang.IllegalStateException getCallerPrincipal() 返回当前调用者的主体 java.security.Principal的接口定义 boolean equals(Object?another)；  比较主体代表的对象是否与指定对象相同； String getName()  返回主体的名字； int hashCode()  返回主体的hashcode. String toString()  返回主体的字符串形式 例子： isCallerInRole(String roleName) 检查当前调用者是否具有指定的安全角色 安全角色由组装者在部署信息中定义 并被部署者分配给不同的主体（组） 用以实现基于角色作用于请求的安全检查 这种安全检查不适于在部署信息的方法访问权限中声明 例子： 安全角色的声明 如果代码中使用了某些安全角色，就必须在部署信息中声明被引用的角色名字 在部署信息中的格式为 security-role-ref description … /description role-name … /role-name /security-role-ref Security-role-ref 应用组装者的安全责任 定义安全视图(security view) 包含在ejb-jar文件中 简化部署者的工作 如果没有安全视图，部署者将不得不了解业务方法的内容才能部署相关的安全策略 而业务方法的细节不是部署者应该/可以了解的 工作包括 定义安全角色，方法许可，安全角色及其引用的关联，安全标识 安全视图由一组安全角色组成 安全角色（Security role） A semantic grouping of permissions 用户必须拥有某种安全角色才能成功使用相应的应用 是一种逻辑角色，因为部署者可能根据