用于服务器安全和权限处理的系统和方法技术方案

一种可插入的体系结构允许安全和商业逻辑软插件被插入到由服务器（２０６）作为主机接纳的安全服务中，并且控制对于在那个服务器上、在安全域（２０８）内的另一个服务器上或在安全域之间的一个或多个所保护资源的访问。安全服务（２２２）可以作为用于安全实施、访问权利确定的焦点。并且在一个登录处理中使用或确定的信息可以透明地和自动地流到其他的登录处理。权限表示在特定的上下文中特定的用户（２０４）可以或不可以对于特定的资源（２２６）做什么。权限不仅反映安全环境的技术方面（许可或拒绝概念），而且可以用于表示由服务提供者要求的商业逻辑或功能。以这种方式，权限填补了简单安全平台和复杂商业策略平台之间的空档（ｇａｐ）。（*该技术在2022年保护过期，可自由使用*）

【技术实现步骤摘要】

本专利技术一般地涉及服务器安全机制，具体涉及用于服务器安全的体系结构。
技术介绍
这些年来，用于服务器技术、特别是电子商务服务器的术语“安全”已经扩展为覆盖安全环境的几个方面。这个术语的原始定义总是涉及一种机制，用于验证特定用户(或客户)的身份，并且防止用户检索、查看或否则访问不允许访问的、在服务器上的信息。图1示出了今天通常使用的安全机制。客户102、104经由多个协议来访问诸如应用服务器106的安全资源，所述协议包括例如http(超文本传送协议)110和IIOP(因特网inter-ORB(交互对象请求代理)协议)112。通过安全层108来过滤访问请求，安全层108通常根据一组硬连线的规则来确定是否允许或不允许所请求的访问。安全层可以是所保护资源的一个组成部分(例如应用服务器本身)，或者可以作为独立的实体(例如作为防火墙系统或器件的部件)。当前的系统很少或不分析访问请求的特征、客户的类型或被保护的资源的类型。因而，安全经常被看作简单的“允许或拒绝”机制，它被设计使得明白由服务器提供的所保护资源，并且向那些资源附加预定的一组管理用户或客户的访问权的规则。很少或不明白进行请求的方式或其中特定用户可以请求访问资源的环境设置，并且安全机制不有助于容易地修改所述规则以反映在关于安全的商业策略中的新变化。已经做出努力来发展安全、尤其是服务器安全的概念，以包括反映用户的特定环境的信息和以短语表示访问特定的所保护资源的请求的方式。类似地，已经做出努力来提供可以容易地进行修改以反映商业策略、安全方针和访问权中的变化的安全机制。这些方法通常仍然需要应用编程者负责将一组商业策略查询组合在一起并且问问题“这样好吗？——这个访问按照安全规则是可以接受的吗？”。所需要的是这样一种机制它使得这个过程包括全部，以便编程者不必明白商业语义和商业策略规则而能够开发咨询安全相关的商业策略问题的程序和应用。近来，一组新的涉及所保护资源的要求已经通过与应用服务器客户和系统集成者的讨论而出现。这些新的要求从应用而不是基础结构的观点以安全的形式被表达。在这些新要求内的关键区别是存在商业策略实施。通常以用户根据他们充当的角色和商业请求的上下文被“授权”执行的行为的形式来描述商业策略的实施。客户和系统集成者对于需要他们将实施商业策略的代码嵌入到应用程序中的事实感到沮丧。嵌入这种逻辑产生了配置问题每次改变商业策略时必须修改、测试和重新配置应用程序。根据商业策略改变的频率，当前的用于修改和重新配置的要求是不可接受的。客户和系统集成者理想上希望将这些新的授权能力普遍地应用到不同类型的执行和资源容器，例如包括用于企业JavaBeans组件模型(EJB)、万维网应用程序(小服务程序，JSP)以及其他类型的商业和资源容器的那些新的授权能力。基于角色的访问控制(RBAC)正在变为由客户和系统集成者请求的授权的主要形式之一。在角色使用中的趋势使得当进行授权决定时组织身份被用作身份的抽象形式。角色的使用提供了一种降低在应用安全的管理中的成本和误差的机制，因为它简化了管理量。Java 2企业版(J2EE)定义了基于角色的访问控制的说明形式。但是，因为它基于说明性方案，因此角色与主方的联系是静态的。另外，当前的Java2企业版规范未提供任何手段，通过该手段，当确定与给定的主方相关联的角色时可以考虑诸如请求的参数或目标的身份的商业请求上下文。结果，需要应用程序开发者在应用程序中实现商业策略规则以计算动态角色关联，以便支持诸如“拥有者”的概念。客户和系统集成者现今要求比由Java 2安全所定义的基于许可的安全和在Java 2企业版中定义的基于角色的访问控制的那些授权能力更丰富的一组授权能力。可以在诸如访问控制列表的传统授权机制和商业策略实施的交集中找到用于这个更丰富级的授权的要求的基础；所述基础包括当进行授权决定时考虑到商业请求的上下文的能力。所述请求上下文可以包括目标对象的身份、请求的参数的值、诸如网络或启动客户的IP地址的可能的环境信息。对于通过其来集成这些新的授权能力而与执行或资源容器类型无关的单独机制的缺少是客户和系统集成者的沮丧点。服务提供者接口(SPI)是由几个应用服务器使用的机制，以便允许与外部授权提供者的集成，其中所述几个应用服务器包括加利福尼亚San Jose的BEA系统公司的WebLogic服务器产品。这种SPI领域具有多个限制，这些限制限制了它被用作集成第三方的授权机制的成功手段或由客户和系统集成者要求的新授权能力的能力。对于当前“领域”SPI的最大的限制之一是实施的范围。当前领域机制的实施范围不包括诸如企业JavaBeans组件模型和万维网应用程序的资源。具体上，所述领域着重于RMI(远程方法调用)型资源，诸如JMS(Java消息传递服务)目的地、在JNDI(Java命名的目录接口)中的输入项和在粗略等级(course-grained level)上的小服务程序。虽然所述领域可以想象地被更新以保存支持这种资源的保护所需要的授权策略的定义，但是其他的限制是最后使得所述领域成为处理所有的授权要求的不切实际的机制。当前的领域SPI的第二个限制是实施点。当前领域机制不允许在所述领域本身中存在进行决定以允许访问所保护资源的点。相反，实施点在应用服务器本身中。因为这种处理，当前的领域被定义为仅仅支持基于许可的授权机制，其中所述领域仅仅作为访问控制列表的数据库。多数厂商也不能接受这样的复杂性提供也可以支持Java 2砂盒(运行程序安全区)规则的一个Java 2策略对象。另一个限制是当前领域SPI的实施机制支持。如同实施点的情况一样，由当前领域SPI允许的实施机制限于以基于许可的授权机制为基础的那些。这与主导的第三方授权提供者的能力相反，其集成被客户和系统集成者以日为基础来请求。这些限制一起约束了可以与企业应用服务器集成而不最小化提供者的价值问题的授权提供者的类型。不存在获得请求上下文以便提供丰富的被请求的授权的当前能力。
技术实现思路
本专利技术一般地涉及一种服务器安全机制，具体涉及提供服务器安全和权限处理的体系结构。一种可插入的体系结构允许安全和商业逻辑软插件被插入到由服务器作为主机接纳的安全服务中，并且控制对于在那个服务器上、在安全域内的另一个服务器上或在安全域之间的一个或多个所保护资源的访问。安全服务可以作为用于安全实施、访问权利确定的焦点，并且在一个登录处理中使用或确定的信息可以透明地和自动地流到其他的登录处理。本专利技术也引入了用于访问上下文内的权限的概念。在本申请的上下文中使用的“用户”或“客户”可以指同一事物——自然人、在自然人控制下的硬件装置或软件应用程序、或者在自动控制下运行而不需要用户干预的硬件器件或软件应用程序。用户(客户)是试图访问在服务器上的所保护资源的实体。这个所保护资源可以例如是运行在服务器上的软件应用程序、网站的特定的网页或一部分、或者数据库等。当用户试图访问资源时，安全服务可以确定访问请求的类型、目的地(所保护资源)和其中进行请求的设置——以下称为访问上下文或简称为上下文。从这个信息，安全服务可以确定用于用户的一个“权限”或一组权限。权限清楚地表示在特定的上下文中特定的用户可以或不可以对于特定的资源做什么。权限不仅反映安全环境的本文档来自技高网...

【技术保护点】
一种安全系统，用于使得客户可以访问所保护资源，包括：应用接口机制，用于接收用于访问所保护资源的、来自客户端应用程序的访问请求，并且将所述访问请求通告给安全服务；安全服务，用于确定许可或拒绝所述访问请求；资源接口，用于 向所述所保护资源通告被许可的访问请求。

【技术特征摘要】
...

【专利技术属性】
技术研发人员：保罗帕特里克，
申请(专利权)人：BEA系统公司，
类型：发明
国别省市：US[美国]