CN103258159A - 可扩展和/或分布式授权系统和/或提供类似的方法 - Google Patents

Abstract

一种可扩展/分布式授权的安全系统被提供。所述安全系统为第一应用的资源提供授权。在所述第一应用中，创建安全上下文并且所述客户端被所述第一应用认证。来自所述客户端的请求被接收，以访问在所述处理系统中可执行的所述第一应用的至少一个资源。所述第一应用通信以确定所述认证的客户端是否被授权访问所述至少一个资源。在所述第二应用中，所述授权流程是在所述处理系统上执行基于来自所述第一应用和所述创建的安全上下文的通信。对于所述授权流程内的至少一个步骤，与非所述第二应用的另一个应用通信，以便确定所述客户端是否被允许访问所述至少一个资源。基于这一步骤确定所述第一应用允许或不允许客户端的至少一个资源访问。

Description

可扩展和/或分布式授权系统和/或提供类似的方法

技术领域

此处描述的特定的示例实施例涉及可扩展和/或分布式安全系统。更特别地，特定的示例实施例涉及用于与计算机系统有关的使用的可扩展和/或分布式授权技术。

背景技术

计算机应用在社会中变得越来越普遍。笔和纸、机械系统和其它的设备已经被由计算机程序控制的电子设备所替代。现在这些计算机应用处理财务信息、汽车装配过程、动力系统和许多其它种类的功能、系统和流程。

在基本层面上，计算机应用包括流程（例如，批准财务交易、在汽车装配线中操纵机械臂）和数据（例如，交易花费多少、谁将批准交易、确定机械臂移动的坐标值和/或速率）。这样的应用操作的流程和在其上操作的数据具有值并且应当被保护。

由于计算机应用的普遍性已经增长，对保护这样的应用的技术的需求也已经增长。安全可以分类为两个子类别，也就是，认证和授权。

认证可能被执行以检验人（或流程）是如其所说的。比如，对登录网站的人认证那个人是用户。这是一个相当简单的认证形式，因为可能登录的人事实上不是与那个账户“关联的”人。因此，更多的严格的认证形式可能被采用（例如，2-因素认证（2-factor authentication）），以便提高这个人是他/她说他/她是的那个人的可靠性。

安全的第二个方面被称为授权，其可能被用于授予对资源（例如，流程、数据等）的访问。授权的一个元素与这些被授权的访问如何被认为是安全上下文相关。安全上下文可包括涉及所述用户、分配的任务、当所述用户认证时提供的权限数据等的信息。这些上下文随后可被用于确定所述用户（或其他实体）是否与授权以给定的一段数据（或流程）交互的所述上下文相关。

假定确定用户（及其相关上下文）可以访问哪部分可能是为涉及所述资源的特定应用，在某些情况下，它不可能提供抽象授权模式（如，框架）。新开发的应用可包括关于如何/什么用户或目标可访问或查看所述流程的特定应用逻辑和所述应用的数据。例如，在云计算场景中的一组应用，所述应用分享可能不了解其他算法、流程等的数据，促进这些数据使用（或查看）的授权。

一些对认证和授权起作用的现有框架，例如：

1）Spring Security（前身为Acegi）：所述Spring框架提供了与Spring框架、依赖注入模式和面向方面编程设施的其他部分的最高级合作。在它们之上的认证和授权能力都被提供。二者都陈述（与XML）并存储在LDAP、RDBMS或XML文件中。授权使用了访问控制列表（Access Control Lists，ACL）。所述ACL存储在代表客户安装的预配置模式中的客户端数据库内部。授权是直接通过注释方法或呼叫方法内部的所述授权API来实现。所述安全上下文通过静态方法和存储在为区分的线程局部变量被提供。这一行为设定了一个请求总是处理一个线程的先决条件。所述同步接收（synchronization sink）为所述数据库，意味着每个应用可以读取这些ACL和进行授权。

2）JEE安全：JEE包括基于通过中央容器管理认证信息的所述Java认证和授权服务（Java Authentication and Authorization Service，JAAS）。所述认证信息包括用户和任务，并且用于通过编程或注释技术授权。保持实体以特定领域语言（domain specific language，DSL）写入的授权性文件被提供，所述DSL用一个预定义权限集合描述授予资产的规则。所述规则被陈述地（declaratively）应用，并且自动地通过在所述容器内所述提供的安全管理扩展。

3）Apache Shiro：这个框架提供在权限级别上的授权。用户可以描述权限、存储所述权限作为所述用户的属性、将它们应用在资产（asset）上、以及检查访问是否能通过匹配定义权限的所述用户与定义在所述资产上的所述权限来被授予。

这些传统解决方案尝试为在单一应用中的简单和可能最普遍的需求，解决所述认证和授权问题。

然而，上述（及其他）技术在提供应用安全上可包括一个或多个缺陷：

1）在某些情况下，RDBMS中的XML配置和静态ACL表可能不太灵活，并且可能不是可扩展的。所述权限可能更静态或固定，且不能作为灵活性去定义。虽然用户可以配置所述授权流的检查策略，但是所述授权流的扩展是不可能的。

2）在某些情况下，所述认证信息可包括主体（用户）和任务（roles）。这个基于任务的方法可能在所述授权流程上太限制，并且可能不支持一些普通使用的情况。更进一步，所述属性文件可能是静态的且不能在运行时通过其他组件被扩展以提供可扩展的授权扩展。

3）在某些情况下，所述权限可能是只定义所述权限是否匹配的静态校验。更进一步，从其他组件/应用/系统贡献的解译规则也许是不可扩展的。

因此，在本技术领域需要为应用提供安全的改进技术，例如，在商务或工艺流程环境中，多个进程和/或应用互相通信。某些特定实施例为对授权检查的注册扩展提供功能和/或为在特定非应用方式中的安全和连同特定应用安全提供分布式授权检查。

发明内容

在某些特定实施例中，一种考虑如何为给定资源的发生授权的灵活性的授权系统被提供。在某些特定实施例中，所述授权系统提供允许关于实现为已实现的组件的所述授权规则的所述组件抽象化的扩展点。于是，某些特定实施例可能是不引人注意的（unobtrusive），并且为在扩展一个给定扩展点的所述组件上的所述授权组件供给。

某些特定实施例可委托授权请求至扩展组件，以便履行这个授权请求。这个可包括转发所述当前安全上下文至所述扩展组件。某些特定实施例可在注册表（或其他类似实现）中注册可靠组件，以提供一种寻找和/或委托授权请求的方式。某些特定实施例可为可扩展性提供挂钩（hook），可通过所述扩展组件被使用，以至于特定应用（如，局部化）进程或数据授权请求可能被实现。

在某些特定实施例中，一种分布式授权的计算机实现方法被提供。所述方法在至少一个处理器和一个执行复数个软件应用的存储器的处理系统上被提供。在所述处理系统中可执行的第一应用的客户端创建一个安全上下文。在所述第一应用中，接收从所述客户端到所述第一应用的连接。所述客户端被认证，且来自所述客户端的请求被接收，以访问在所述处理系统中可执行的所述第一应用的至少一个资源。所述第一应用与第二应用通信以确定所述认证的客户端是否被授权访问所述至少一个资源。在所述第二应用中，所述授权流程是在所述处理系统上执行基于来自所述第一应用和所述创建的安全上下文的通信。对于所述授权流程内的至少一个步骤，与非所述第二应用的另一个应用通信，以便确定所述客户端是否被允许访问所述至少一个资源。基于这一确定，所述第一应用允许或不允许访问。

在某些特定实施例中，一种用于授权对计算应用的资源进行访问的授权系统被提供。所述系统包括配置为存储与所述资源相关的三部分权限结构的存储媒介。所述三部分权限结构包括：（1）包括所述资源的域或类型的第一部分；（2）定义在所述资源上完成的至少一个动作的第二部分；以及（3）包括根据评价产生包含所述资源的指令的输出的正则表达式的第三部分。所述系统包括至少一个处理器的处理系统，所述处理系统被配置为基于所述第三部分权限结构评价对所述资源的授权请求。

在某些特定实施例中，一种评价处理系统上的授权应用中的授权请求的计算机实现方法被提供。所述授权请求由第一计算应用产生。所述授权请求从所述第一计算应用被接收。安全上下文的创建是基于所述授权请求，所述安全上下文包括：请求客户端、与所述请求关联的资源和与所述资源关联的至少一个权限上的信息。至少一个规则被检索，所述规则与调用在第二计算应用中定义的认证流程的回调函数关联。抽象语法树的建立是基于所述安全上下文和所述至少一个规则。所述抽象语法树被评价。在所述抽象语法树的评价过程中，回调是对定义在所述第二计算应用的所述认证流程所执行。所述授权请求的结果的返回到所述第一计算应用是基于所述抽象语法树的所述评价。

一种永久计算机可读存储介质，可触地（tangibly）存储进行通过某些特定实施例以及相应的计算机程序提供的上述概括和/或其他方法的指令。

基于设备的系统和或计算机也可配置或改编为实现在特定实施例中提供的上述概括和/或其他方法。

这些特性、方面、优点和特定实施例可分别使用和/或多种不同组合应用以实现本发明的进一步实施例。

附图说明

通过参考下面结合附图的具体特定说明描述实施例，这些和其他的特性和优点可能更突出和完整。

图1是根据某些特定实施例结合授权与用户管理控制的应用的示例；

图2是对于应用的分布式授权的示例；

图3是根据某些特定实施例的分布式授权系统的示例实现；

图4是根据某些特定实施例的评价授权请求的示例过程的流程图；

图5是对扩展域模型的说明；

图6是对安全上下文的说明；

图7是根据某些特定实施例用于定义授权的示例类图；

图8是根据某些特定实施例为了存储权限的实现的说明；

图9是根据某些特定实施例对授权框架的扩展的说明；

图10展示了根据某些特定实施例的示例处理系统。

具体实施方式

本发明实施例提供了由应用使用的授权逻辑的灵活性。特别地，某些示例性实施方式提供的扩展点，对于扩展通过所述基本实现来提供功能性功能组件是容易、抽象和强大的。这些扩展点也可以是开放和/或独立于为授权实现规则。因此，在某些情况下，那个实现可能是不显眼的，且可能会允许扩展组件侧上的授权逻辑的实质的（有时甚至完成）实现的。因此，本发明实施例可以提供一个分布式、可扩展的授权方案的计算系统。

图1是根据特定的示例实施例结合授权和用户管理控制的应用的例子。在这个例子中，客户端100请求对网页应用102的认证。用于所述网页应用102的认证可能由用户管理中心(UMC)系统/组件104（其可能是应用、应用程序界面API、框架、或扩展应用的其它类型的组件）通过安全实现106提供。一旦被认证，客户端可能与流程流108交互。在认证后，用于认证的用户的安全上下文可能被建立或加载。这可能包括在用户/客户端、租户（tenant）、相关的角色和/或权限上的信息，等。在特定的示例实施例中，可能在UMC框架104、网页应用102或其结合中提供这样的安全上下文信息（例如，用户信息存储在UMC中，而应用特定的信息通过扩展（extension）、权限信息存储）。

客户端100可能继续与网页应用102中的所述流程流（process flow）108交互以便满足一些客户请求。在特定的情况下，在所述流程可能继续之前，一些特定的业务逻辑可能要求一些形式的授权（例如，特性（feature）或资产(asset)）。在这种情况下，在UMC104中的授权API110可能被用于确定加载的安全上下文是否为给定的资源（例如，特征、流程子集、数据等）被授权。

当授权被请求，所述授权流程流112被执行以确定是否正在请求的实体被允许访问给定的资源。所述流程流112可能使用存储的权限、安全上下文、和/或在规则服务提供者接口(SPI)114运行的规则。在特定的例子中，所述SPI可能被用于扩展和/或执行类/接口/方法等来达到一个目的。

用于规则SPI114的规则可能从UMC规则116数据库和/或所述网页应用102中的规则数据库18中获取。在宿主应用（例如，网页应用102）中定义的规则可能促进用于授权的应用特定的业务逻辑的规定。在这种情况下，在授权流112作为随安全上下文增强的回调的过程中，UMC104可能调用该规则扩展。该上下文的结果可能是授权确定的结果。

因此，宿主应用（例如，网页应用102）可能使用示例的UMC104的授权API110，但可能也提供怎样基于给定的应用的需要确定授权的扩展。这样的场景也可能工作在分布式应用环境中。

图2是应用的分布式授权的例子。此处，客户端200通过安全层208请求网页应用202的授权。在一些情况下，在客户端200访问所述应用202的过程中，可能要求授权检查。在这种情况下，应用202可能与UMC204的授权API212接口。如上所述，所述UMC可能执行确定正在请求的客户端（或它们的安全上下文）是否被授权于给定的资源的流程。该流程的部分可能包括与规则SPI216和Umc规则数据库214接口。在这个例子中，应用202的授权规则可能在应用206中被描述。应用206可能包括被称为UMC处理的部分的注册扩展，即使应用202不“知道”应用206。因此，回调功能被执行以便当运行与应用202相关的规则，UMC204可能确定扩展以相关的规则被注册。

基于所述关联，所述规则SPI可能与应用206和在其中定义的规则数据库218交互以解决来自应用202的授权请求。

因此，在特定的示例实施例中，当应用206消失或离线，包含在应用206中定义的规则的所有客户端请求可能被定义。在特定的示例实施例中，这样的特性可能提供另一个安全网，以便当没有找到可以授权访问的组件，访问被拒绝。

图3是根据特定的示例实施例分布式授权系统的示例的实现。在这个例子中，应用302可能包括通过入口304可访问的“搜索列表”组件310。应用302可能也包括AMZ组件308和ABS组件。在某些情况下，所述AMZ组件可能是形成即时申请的受让人的可用产品，例如，ARIS MashZone。在某些情况下，所述ABS可能以通过即时申请的受让人所提供的产品形式，例如，ARIS业务服务器（Business Server）。每个所述组件可功能化实现UMC，且也可与各种服务交互，如包括所述UMC的所述动物园管理员（zookeeper）组件312。

所述搜索列表组件310可以提供有关模型和混搭（mashups）的数据。这可能是每一个用户或客户端可能无法访问的担保资产。因此，授权方案可以实现对这些资源的访问控制。在某些特定实施例中，门户网站304可能不知道如何授予对这些资源的访问。此外，因为确定对资源的访问可能需要业务逻辑，后端UMC也可能不能够提供一个确定（例如，因为它是业务逻辑无关的）。因此，在某些情况下，所述UMC可以“找到”<模型>和<混搭>扩展的委托授权检查，以这些扩展名（例如，像在ABS和AMZ组件306和308中实现）。这些扩展的结果可确定资产是否对客户端/用户显示。

权限

确定一个给定的客户端是否被授权访问资源可能包括权限的规格。在某些特定实施例中，一个权限对象可能包括通过冒号划分的三个部分。例如，<部分1>：<部分2>：<部分3>。

在这样的实现，所述部分可描述所述权限以一般性质（general aspects）和更具体的个体可能以不多余和可结合的方式被描述。

在某些特定实施例中，

<部分1>描述了所述权限被应用的域或被应用资产的类型。

<部分2>描述了在所述域或所述资产类型中完成的操作。

<部分3>描述了可能被评价来过滤类型的所述资产的ID和/或正则表达式。

在某些特定实施例中，一个或多个下列符号都可能被用到：

1）允许的符号（在部分内部）：

a）*（如，所有域/类型、操作、ID）

b）-（如，无）。在某些特定实施例中，权限的部分3可被留空。

c）逗号分隔列表（如，对于操作以定义一个以上的不重复许可定义）

d）正则表达式（正则表达式可通过符号“/”来定义，例如，“/<regex>/”，此出regex是由用户实现的所述正则表达式）

2）不允许的形式：<部分1>::<部分3>

3）可选部分：<部分2>,<部分3>

如表1所示,各种权限可被定义。这些权限可被用于与某些特定实施例联合。权限1和2显示了何处的一个或两个操作在流程的域（如，管理或执行）中被允许。在某些特定实施例中，通过“部分3”留白，所述系统可在空白部分3自动填充表示“所有”的*。

第三权限包括伴随ID列表的多重操作。第四权限被指设置为允许ID列表上的所有操作。第五权限显示所述符号“-”的例子。具体地，减号的使用表明在所述域“文档”中的所有写入操作都是被允许的，只要没有指定ID。这一权限可被使用，例如，在文档创建对每人都允许的场景，除了通过ID指定的存在文档的升级。这个例子可被用于所有权保护场景。

第六权限显示了一个过滤所述ID列表正则表达式，以至于只有带T123-前缀的ID可被选定和授予的例子。第七权限可用于扩展所述权限逻辑。给定假设“GUID12345”作为树中根节点的ID，一个扩展模块随后可检查不得不被授予的某个文件夹是否是为了授予访问这个节点的子文件夹。这些场景可用于权限继承在所述权限被放在父资产（parent asset）和用于确定是否授予儿童访问权限的地方。

授权流

在某些特定实施例中，授权流作为通用过程被提供。随后，这一过程可为给定的安全上下文解译可选择扩展的抽象规则语法树。所述通用过程可能完全不懂实现的扩展，并且关于那里有多少和所述拓展在哪里驻留都可能是不可知的。因此，所述过程可以是灵活性的，而不需要已知每个特殊实现的驻留位置。在某些特定实施例中，只有在运行时注册表被问及以提供已注册的回叫（callbacks）。任意数量的回叫可能被实现，且之后在任何宿主上被提供。

图4是一个示例流程的流程图，用于评价根据某些特定实施例中的授权请求。图4中的所述流程可包括三个广泛的任务，即：（1）创建所述安全上下文；（2）解译授权请求；（3）返回（或交付）所述解译结果。在图4中，初始权限请求是当用户在400请求一个资源时生成的。为所述给定资源的所述权限从所述权限存储402在406被“创建”或加载。类似地，加载权限、资源和/或请求用户的所述规则从所述加载注册表404被加载于408。如上所述，在某些特定实施例中，所述规则可能从中央管理存储（如UMC）或在特定应用的（application-specific）逻辑被提供。所述逻辑可存储于所述请求应用或另一个从所述请求应用（如图2所示）中分离出的应用。

一旦所述用户、权限和规则都被加载，这个授权的所述安全上下文可能是完整的。伴随所述完整的安全上下文，所述授权检查可通过从412至所述检查权限步骤410的处理来进行。如上所述，在某些情况下，其他应用可为一个应用提供授权处理。在这样的情况下，如果所述其他应用被设为提供所述授权逻辑无效，所述过程可转到为所述给定资源的授权被拒绝的位置414。

然而，如果应用程序是可用的，对于所述资源的问题中的所述权限在410被检查。如果所述检查在418成功，那么在416步骤权限被授予。如果所述权限不成功，这个过程可能循环，看是否通过另一条规则授予权限。

在某些特定实施例中，允许授权的流程中，如果有明文禁止（例如，不允许用户X访问资源T），那么所述处理可能会停止并转到414。

安全和登录

在某些特定实施例中，在托管组件上阻止外部攻击可能是可取的。在这种情况下，应用接口可通过本地部署的接口，可达成只是内部运行的JVM或通过HTTPS将请求发送到/自授权的需求/要求到远程客户端。此外，在某些特定实施例中，对托管组件的请求可通过根据对适当的授权负责的小服务程序规格的安全过滤被过滤。如果所述提供的认证信息不充分，这种要求可能会伴随合适的错误信息和HTTP状态码被拒绝、过滤和退回到客户。然而，如果所述安全过滤被成功通过，一个授权请求可能被作出。

在某些特定实施例中，如果授权请求不被授予，一个授权流程可随着相应的HTTP响应码提供错误信息。这些失败授权请求可能随着一个默认的警告日志级别被注销，以至于管理员或其他用户可容易地监控这些请求。在某些实例中，授予授权请求可随着一个较低的日志级别（如调试）被注销。在某些特定实施例中，这样的事件记录文件因为生产环境可能被关闭。

灵活性

在某些特定实施例中，授权系统可具有提高系统如何被使用、设计、开发、呼叫、扩展等类似的所述灵活性的特点。

例如，权限要求可包括权限如“domain/action/*”。可选或另外地，权限可具有更复杂的权限，例如，“domain/action,action/<regex>”。这些“复杂”的权限可促进一系列关于授权请求怎样才可被处理的可能性的使用。

在某些特定实施例中，所述扩展和/或插件性能可促进系统设计者在怎样实现授权逻辑的灵活性，在某处给定上下文中的给定资源上的保护需求可能更明确地满足（或实现）。

在某些特定实施例中，授权实现可被用于和部署在各架构的大范围。这些架构可从一个应用中的本地JVM场景到遍布不止一个JVM的一组应用，或平均到完成云场景在哪些应用中是需要开启或关闭的。

示例性实现

一种示例性实现可包括一个或多个下列特性：帮助非入侵式应用、灵活性，并且展示许多种迁移路径以采用此处描述的现有应用。

一种实现可包括一个在通过默认管理所有权限的ARIS服务器内部的UMC(User Management Central，用户管理中心)组件。

应用随后可以选择关于如何为所述应用处理授权。在一个场景中，所述应用可管理所有所述授权，并且使用所述UMC提供的所述授权文本。在另一个实现中，所述应用可使用所述UMC作为一个通用授权提供者，但是伴随以自定义规则（可能与这个和/或其他应用有关）的形式的额外扩展。这可被认为是一种混合方法。另一种方法可能是所述应用只使用为管理员、规则存储等功能性提供的UMC。

在某些特定实施例中，关于权限是否与一个特性或资产（如，因为资产权限可能是一个特性权限的更具体形式）相关，其可能只有很少或没有差别。

中心用户接口可能是通过所述UMC发起，并且在某些特定实施例中可能是一个基于网络的接口。在某些特定实施例中，所述权限的存储可能在所述UMC中完成，然后扩展这些功能的应用可存储一个通过在所述UMC的这个接口的用户的权限，并在运行时解译它。

应用程序接口

在某些特定实施例中，一个应用程序接口对于一个示例UMC为了帮助功能性提供的所述UMC，外部应用接口可被提供。

在某些特定实施例中，当在运行时使用授权，可能是使用注释（annotations）的陈述性API。这些声明可帮助对UMC的授权请求的委托。在某些特定实施例中，所述委托可编程完成。这个示例技术可提供一个高水平的控制（但是在尽可能昂贵下，用户与UMC交互更为深入）。因此，在优选实施例中，陈述注释可与为同样使用编程技术的选择一起使用。

一种陈述性实现可具有下列或类似结构（如，每个注释的陈述）：

isInRole(字符串任务)

isPermitted(字符串权限)

一个程序化实现可能是使用以下或类似接口作出的：

接口授权

在某些特定实施例中，所述UMC API可在为存储及其类似的权限上提供CRUD操作（创建、读取、更新、删除）。

某些特定实施例也可为建立一个抽象语法树（AST,abstract syntax tree）提供能力，包括在扩展中以流动方式定义的所述规则，以通向建立于众所周知的建造者模式（builder pattern）的DSL。

在某些特定实施例中，一个AST可能被建立在一个或多个组件上。例如，如图7（下面讨论的）中的所述组件可用于建造一个AST。这样的一个树形结构可具有下述格式：

<MATCH><perm1><OR><NOT><REGEX><perm1>

或类似于下列权限检查逻辑：

IF(perm1matches exactly)OR NOT(perm1matches<RegEx>)

THEN grant

ELSE not grant

虽然“匹配”和“正则表达式（regex）表达”显示于图7中，其他扩展的类型可能被包括在所述AST中，例如，帮助授权检查。在某些特定实施例中，一个建造者模式可考虑到所述树的DSL（特定领域语言，Domain Specific Language）建立。一个示例为Authorization.match(Perm1).or().not().regex(Perm1).check().

上述提到的树的表达可用于为所述树的建造促进一个“流畅的”风格。

图5是一个扩展域模型的说明。在某些特定实施例中，一个权限实体可被提供。这种权限实体504可以与用户502和任务506都相关。这些关系可以是0到许多（例如，一个用户可以有0或多个与它相关联的权限）。一个或多个权限分配的任务可能是所谓的用户组，所述用户组用于通过向所述用户指定这个任务/用户组，授予用户所有的权限集合。

图6是一个安全上下文的说明。在某些特定实施例中，UMC向所述UMC或所述UMC的扩展提供了一个安全上下文。在这方面，umcContext604被提供，其包括请求所述特性或资产的所述用户606、所述用户所属的所述租户、所述用户指定的所有任务608、以及任一任务从属权限602。在某些特定实施例中，所述租户属性可能是一个对象。那么所述上下文604可用于一个权限请求610。在某些特定实施例中，所述数据可通过一种“渴望的”技术或“懒惰的”技术（例如，基于性能、内存使用事项等等）加载。

语法

在某些特定实施例中，所述任务被定义为用于建立一个抽象语法树（AST）的接口，所述抽象语法树（AST）用于确定权限是否授予。

因此，图7是根据某些典型实施例中用于定义授权的示例类别图。Umc上下文(UmcContext)704、匹配表达（Matcher Expression）和正则表达式（RegexExpression）712可能是从一个UMC实现所提供的功能。并且，第三部分谓词706可能是一个扩展点，所述扩展点为宿主组件内定义的授权被实现。接口702可具有实现所述接口，例如，和表达（AndExpression）714、或表达（OrExpression）716和/或非表达（NotExpression）718的功能。其他类型的表达可能也被实现，例如，一个XOR表达。抽象类710可具有各种各样被实现的表达。在这个示例中，匹配器708和正则表达式表达可被实现。然而，此外，附加表达的实现取决于一个给定的实现。

对于一个给定的语法，所述AST可建立在基于发现在所述UMC的所述违责处理规则和定义在一个宿主应用中的任何扩展规则运行时默认的规则。基于建立的AST，一个给定权限可以被评价以确定授权请求是否被授予。例如，如果没有规则授予所述权限结果可能会以“错误”（例如，授权被拒绝）返回。

已扩展的可选规则都是谓词，并且可注册为一个回调。因此，这些可能被称为在运行时返回所述正确的安全上下文（见上文）。因为基本构件模块都是在可扩展的解释器模式中应用的决策表的混合，所述AST是强大的，并且方便特定组件的授权需求表达的提供。

图8是根据某些典型实施例用于存储权限的实现的说明。UMC800包括定义存储在所述UMC的数据库210中的规则802的umc。基于权限804存储的umc是通过所述组件内所述UMC的模式，并且通过常规API访问。因此，如果有人想申请用户或任务的权限，规则的中央资料库（central repository）可被创建。

规则也可通过所述规则接口806被扩展。实现他们自身规则的应用可在所述UMC800中的所述规则注册表注册。

图9是根据某些特定实施例对授权框架的扩展的说明。UMC900可以类似于图8中（如904、906和912）UMC800。在此，<模型>908和<报告>910在服务器902中实现所述规则接口906。在某些特定实施例中，这些插件可以在一个JVM中的宿主组件内注册，不能从外部发现，因为提供来注册的API是在本地发布的，无法从远程协议获得。另外，所述API可能被提供给外部资源（例如，通过网络）。

图10显示了根据某些特定实施例的示例处理系统。处理系统1000可包括一个连通系统总线1004与存储介质1008的中央处理单元1002，所述中央处理单元1002可以是非易失性的（non-volatile）存储。随机存取存储器（Random AccessMemory，RAM）1006（例如，易失性存储器）可通过所述系统总线1004访问。用户输入设备1010，例如，键盘、触摸板、鼠标等可被提供，并且与用户输入适配器1012通信。显示器1018可被提供，以方便用户与在所述处理系统1000上进行的进程的交互。所述显示器1018可以通过显示器接口1014与所述处理系统交互。所述显示器1018可涉及授权流程的发展和通过用户的实现。网络接口1016可被提供与数据库1020和/或外部系统1022通信。所述数据库1020可为UMC或所述UMC的其他扩展保持规则信息。外部系统可包括所述处理系统1000可交互（例如，图2中的应用206）的网络服务器或其他系统。

某些特定实施例可涉及为业务流程模型（Business Process Models）提供安全。

如本文此处所用的术语：系统、子系统、服务、编程逻辑电路、以及类似可被实现作为软件、硬件、固件，和/或类似的任何合适的组合。本发明的存储单元可以是磁盘驱动器、存储单元、固态硬盘、CD-ROM、DVD、磁带备份、存储区域网络（SAN）系统，和/或任何其他适当组合的具体计算机可读存储介质。本文所描述的技术可通过具有存储在非暂时性计算机可读存储介质上的至少一个处理器执行指令来完成。

虽然本发明已结合目前被认为是最实用和优选的实施例来描述，应当理解为，本发明不局限于所公开的实施例，相反，意在覆盖各种包含在所附的权利要求书的精神和范围之内的修改和等效安排。

Claims (37)

1.一种在处理系统中提供分布式授权的计算机实现方法，所述处理系统包括至少一个处理器和一个执行复数个软件应用的存储器，所述方法包括：

为在所述处理系统中可执行的第一应用的客户端创建一个安全上下文；

在所述第一应用中：

接收从所述客户端到所述第一应用的连接；

将所述客户端认证到所述第一应用；

接收来自所述客户端的请求，以访问在所述处理系统中可执行的所述第一应用的至少一个资源；

响应所述请求，与第二应用通信以确定所述认证的客户端是否被授权访问所述至少一个资源；

在所述第二应用中：

通过所述处理系统的至少一个处理器执行基于来自所述第一应用和所述创建的安全上下文的通信的授权流程；以及

对于所述授权流程内的至少一个步骤，与非所述第二应用的另一个应用通信，以便确定所述客户端是否被允许访问所述至少一个资源，

其中，基于在所述第二应用中执行的所述授权流程的结果，所述第一应用允许对所述至少一个资源的访问。

2.如权利要求1所述的方法，其特征在于，所述另一个应用是所述第一应用。

3.如权利要求1所述的方法，其特征在于，所述另一个应用是不同于所述第一应用的第三应用。

4.如权利要求3所述的方法，其特征在于，所述第一应用不与所述另一个应用直接链接，并且不与所述另一个应用直接通信。

5.如权利要求4所述的方法，其特征在于，所述另一个应用只与所述第二应用直接链接，并且只与所述第二应用直接通信。

6.如权利要求5所述的方法，其特征在于，所述第二应用被编程以接收对来自多个不同软件应用的所述处理系统内的资源的多个授权请求。

7.一种用于授权对计算应用的资源进行访问的授权系统，所述系统包括：

配置为存储与所述资源相关的三部分权限结构的存储媒介，所述三部分权限结构包括：

包括所述资源的域或类型的第一部分，

定义在所述资源上完成的至少一个动作的第二部分，以及

包括根据评价产生包含所述资源的指令的输出的正则表达式的第三部分，

包括至少一个处理器的处理系统，所述处理系统被配置为基于所述第三部分权限结构评价对所述资源的授权请求。

8.如权利要求7所述的系统，其特征在于，所述第三部分包括另一个第二资源的标识符。

9.如权利要求7所述的系统，其特征在于，所述三部分权限结构的所述第一、第二和/或第三部分包括允许与包含所述标识符的各自的部分任意匹配的标识符。

10.如权利要求7所述的系统，其特征在于，所述三部分权限结构的所述第三部分包括表明没有资源标识符被允许的标识符。

11.一种评价处理系统上的授权应用中的授权请求的计算机实现方法，所述处理系统包括至少一个处理器和一个存储器，其中所述授权请求由第一计算应用产生，所述方法包括：

接收来自所述第一计算应用的所述授权请求；

基于所述授权请求创建安全上下文，所述安全上下文包括请求客户端、与所述请求关联的资源和与所述资源关联的至少一个权限上的信息；

检索至少一个规则，所述规则与调用在第二计算应用中定义的认证流程的回调函数关联；

基于所述安全上下文和所述至少一个规则建立抽象语法树；

评价所述抽象语法树；

在所述抽象语法树的评价过程中，执行对定义在所述第二计算应用的所述认证流程的回调；

基于所述抽象语法树的所述评价，将所述授权请求的结果返回到所述第一计算应用。

12.如权利要求11所述的方法，其特征在于，所述第二计算应用和所述第一计算应用都是相同的应用。

13.如权利要求11所述的方法，其特征在于，所述第二计算应用不同于所述第一计算应用。

14.如权利要求13所述的方法，其特征在于，所述第一计算应用不与所述第二计算应用直接链接，并且不与所述第二计算应用直接通信。

15.如权利要求14所述的方法，其特征在于，所述第二计算应用只与所述授权应用直接链接，并且只与所述授权应用直接通信。

16.如权利要求15所述的方法，进一步包括从多个不同软件应用接收多个与所述处理系统内的资源相关的授权请求。

17.如权利要求11-16所述的方法，其特征在于，与定义在三部分权限结构的所述资源关联的所述至少一个权限包括：

包括所述资源的域或类型的第一部分，

定义在所述资源上完成的至少一个动作的第二部分，以及

包括根据评价产生包含所述资源的指令的输出的正则表达式的第三部分。

18.如权利要求17所述的方法，其特征在于，所述三部分包括另一个第二资源的标识符。

19.如权利要求18所述的方法，其特征在于，所述三部分权限结构的所述第一、第二和/或第三部分包括允许与包含所述标识符的各自的部分任意匹配的标识符。

20.如权利要求19所述的方法，其特征在于，所述三部分权限结构的所述第三部分包括表明没有资源标识符被允许的标识符。

21.一种永久计算机可读存储介质，当通过计算机的处理器执行时，可触地存储进行根据权利要求1-6中的任一项的所述方法的指令。

22.一种永久计算机可读存储介质，当通过计算机的处理器执行时，可触地存储进行根据权利要求11-20中的任一项的所述方法的指令。

23.一种提供分布式授权的计算机实现方法，所述方法包括通过第二应用进行的下列步骤：

从第一应用接收通信，其中来自所述第一应用的所述通信包括用于客户端的安全上下文，其中，所述安全上下文包括在所述客户端、所述第一应用的至少一个资源，以及与所述至少一个资源关联的至少一个权限上的信息；以及

基于来自所述第一应用的所述通信和所述安全上下文执行授权过程，以确定所述客户端是否被允许访问所述第一应用的至少一个资源。

24.如权利要求23所述的方法，进一步包括：在所述授权流程中的至少一个步骤，与非所述第二应用的另一个应用通信，以确定所述客户端是否被允许访问所述至少一个资源。

25.如权利要求24所述的方法，其特征在于，所述另一个应用是所述第一应用或不同于所述第一应用的第三应用。

26.如权利要求24或25所述的方法，其特征在于，所述第一应用不与所述另一个应用直接链接，并且不与所述另一个应用直接通信。

27.如权利要求24-26中的任一项所述的方法，其特征在于，所述另一个应用只与所述第二应用直接链接，并且只与所述第二应用直接通信。

28.如权利要求23-27中的任一项所述的方法，其特征在于，所述第二应用被编程以从多个不同软件应用接收多个对所述处理系统内的资源的授权请求。

29.一种提供分布式授权的计算机实现方法，所述方法包括通过第一应用进行的下列步骤：

接收客户端到所述第一应用的连接；

将所述客户端认证到所述第一应用；

接收来自所述客户端的请求，以访问所述第一应用的至少一个资源；以及

响应所述请求，与第二应用通信以确定所述认证的客户端是否被授权访问所述至少一个资源；

其中，与所述第二应用的通信包括用于所述客户端的安全上下文，其中所述安全上下文包括在所述客户端、与所述请求关联的至少一个资源以及与所述至少一个资源关联的至少一个权限上的信息。

30.如权利要求29所述的方法还包括：

检索至少一个规则，所述规则与调用定义在第二计算应用中的认证流程的回调函数关联；

基于所述安全上下文和所述至少一个规则建立抽象语法树；

评价所述抽象语法树；

在所述抽象语法树的评价过程中，对定义在所述第二计算应用的所述认证流程进行回调；

基于所述抽象语法树的所述评价，将所述授权请求的结果返回到所述第一计算应用。

31.如权利要求23-30中的任一项所述的方法，其特征在于，所述安全上下文是与所述至少一个资源关联的三部分权限结构，所述三部分权限结构包括：

包括所述资源的域或类型的第一部分，

定义在所述资源上完成的至少一个动作的第二部分，

包括根据评价产生包含所述资源的指令的输出的正则表达式的第三部分。

32.如权利要求31所述的方法，其特征在于，所述第三部分包括另一个第二资源的标识符。

33.如权利要求31或32所述的方法，其特征在于，所述三部分权限结构的所述第一、第二和/或第三部分包括允许与包含所述标识符的各自的部分任意匹配的标识符。

34.如前述权利要求31-33中的任一项所述的系统，其特征在于，

所述三部分权限结构的所述第三部分包括表明没有资源标识符被允许的标识符。

35.一种提供分布式授权的系统，适用于执行根据前述权利要求23-28和/或31-34中的任一项所述的方法。

36.一种提供分布式授权的系统，适用于执行根据前述权利要求29-34中的任一项所述的方法。

37.一种计算机程序，包括执行根据前述权利要求23-33中的任一项所述的方法的指令。

Images