专利名称：提供对数据库的访问的数据管理系统、方法和安全性结构的利记博彩app
技术领域：
本发明涉及数据管理系统、为机构提供对作为该系统组成部分的公共数据库的访问的方法以及实现该系统和方法的安全性结构。
背景技术：
在单个机构的计算机系统内，常见的是提供可供该机构成员访问的例如服务器上的中央数据库。众所周知，采用安全性结构来控制成员对该数据库内各种数据文件的访问。具体地说，这些数据文件可能归各个成员所有，给予这些成员对数据文件的特定访问权。同样，可以针对各数据文件来授予许可权，以允许就那些许可权定义的成员执行那些许可权中定义的功能，例如读、写、编辑等。其它功能，例如控制用户ID和用户密码可以仅限于具有管理权的特定成员。这些成员可以完全自由地访问或更改数据库的任何部分。
从WO 01/77863中已知，提供一种可被许多不同机构访问的多媒体素材的外部数据库。任何经授权可使用该数据库的机构可以查看所有的多媒体素材，根据内置于系统中的程序规则获取经授权的所请求多媒体素材的拷贝。
发明内容
本发明基于这样的认识需要提供外部数据库以用于存储例如多媒体素材，以便不同各方可使用以及处理同一数据。本发明还认识到在同一数据库上提供不同机构拥有的数据的问题。具体来说，一些机构可能不希望其它机构查看其数据或者甚至是知道其数据在该数据库上或者知道他们使用该数据库。应当明白，先前在内部供各机构使用的系统并不适合，因为即使不允许一些成员观看某些文件，这些成员仍会知道存在这些文件。实际上，更严格地说，拥有管理权的成员始终可以查看任何文件。
本发明的目的在于避免或至少减少这些问题。
根据本发明，提供一种数据管理系统、如媒体管理系统，它包括用于存储多个数据库存的数据库；以及用于控制数据库的数据库存中数据的存储以及允许多个外部机构对数据访问的接口，每个机构包括一个或多个各自的成员；其中所述接口包括控制机构成员对数据的访问的安全性结构。
根据本发明，还提供一种向多个外部机构提供对包含多个数据库存的公共数据库的访问的方法，每个机构包括一个或多个各自的成员，所述方法包括用于控制机构成员对数据库存的访问的安全性结构的步骤。
根据本发明，还提供一种安全性结构，供存储多个数据库存的数据库使用，所述安全性结构实现不同外部机构与数据库存的数据之间的接口，每个机构具有一个或多个各自的成员，所述安全性结构控制不同机构的成员对数据库存的数据的访问。
这样，无论各个机构内的各种成员的权限如何，安全性结构允许多个不同的外部机构使用同一数据库，但是控制所有成员的访问。通过以此方式提供安全性结构，可以提供一种公共数据库，允许不同的机构及其成员共同使用特定数据文件的数据，而其它机构可能没有充分的访问权来知道存在那些数据文件或知道上述机构在使用该数据库。即使一个以上机构的成员拥有对同一数据的访问权，利用安全性结构，就可以只允许一些成员进行比其他成员级别低的操作，例如只能查看。
应当指出，通常这些机构将操作相应的数据存储/通信系统，并且包括到该数据库的外部连接。
因此，安全性结构实现不同机构的系统与公共数据库之间的接口。数据库中的数据在安全性结构的控制下，可以被多个不同机构的系统访问和处理。
数据存储/通信系统可以包括对各系统的相应管理员权限。
利用安全性结构，所有机构的每个成员的访问权的确定与各个数据存储/通信系统无关。因此，一个机构的成员无需具有对其它机构拥有的数据库存的数据的任何权限。
最好是成员对数据的访问至少包括读、写和编辑数据。
因此，对于每个成员，安全性结构可以控制从特定数据库存读、写和编辑数据。对于安全性结构来说，还可以控制其它的访问特征，包括不直接涉及数据库存中数据的处理的功能。
最好是数据库存具有不同的相应所属权。
安全性结构可以根据查找的数据所在的数据库存的所属权来控制成员对数据的访问。
一个或多个数据库存可以归不同的各个机构所有。
因此，每个机构可以拥有其自己的存储大量不同数据文件的数据库存。拥有特定数据库存的机构的成员可以拥有对该数据库存的完全访问权，而安全性结构可以阻止其他机构的成员对该数据库存的数据执行特定功能。具体地说，安全性结构可以阻止其它机构成员被授予删除该数据库存的文件的许可权。
最好是，安全性结构允许成员请求有关该数据库的功能操作，这些功能包括对数据的访问。
由此，成员可以请求写、读或编辑特定数据。成员还可以请求其它功能，比如更改数据库的密码。
最好是，当这些机构之一的成员请求一项功能时，安全性结构要求该成员的ID通过验证。
这样，当尝试访问该数据库时，除非访问者是ID可通过验证的成员，否则安全性结构拒绝此访问。
最好是，安全性结构包括这些机构的各个成员可用功能的列表，当这些机构之一的成员请求一种功能时，安全性结构要求确定所请求的功能是否可供该成员使用。
这样，可以在该系统上给不同的成员授予不同级别的功能。具体地说，此安全性结构可能只允许特定成员读数据，这样，不论可能向该成员授予对特定数据什么许可权，该成员仍是只可以读取该数据。这样，一个机构的成员不能向另一个机构的成员授予超越根据对该机构的这个成员或多个成员所允许的预定范围的许可权。
最好是，安全性结构包括关于每个机构的一个或多个角色，每个角色涉及一个或多个功能，并且定义有资格操作该角色的一个或多个功能的机构成员。
这样，定义了可供成员使用的功能。当一个成员被定义为角色的一部分时，它就有资格(通常至少)操作为该角色定义的功能。
这提供了一种为特定成员定义各种功能的相对直接的方法。它还允许安全性结构以相对直接和方便的方式来操作。具体地说，不是针对个别成员定义随意选择的不同功能(这样难以跟踪什么功能可供哪些成员使用)，预定角色定义一个完整的功能集，通过作为各个角色的一部分而赋予这些成员一个或多个功能集。
最好是，安全性结构包括一个或多个模板，每个模板提供一个或多个功能的列表，角色具有指向这些模板的指针，以便指示为该角色定义的成员可使用的一个或多个功能。
鉴于角色可能与各个机构有关，可以建立模板以供任何机构使用。这样，不同的机构可能拥有同名角色，但是指向不同的模板。因此，例如拥有数据库存所有权的机构可能包括称为“用户”且指向提供完全读、写和编辑功能的模板的角色，而相关的机构可能具有也称为“用户”而指向只具有读和复制功能的模板的角色。
最好是，安全性结构包括关于每个相应机构的、所有可见到所述相应机构的其它机构的指示，当这些机构之一的成员请求一项功能时，安全性结构需要确定该功能未要求访问该机构成员不可见的机构所拥有的数据库存的数据。
这样，使用数据库的机构就只对已经在安全性结构中专门如此记录的其它机构是可见的。因此，无论拥有任何其它权力，机构的成员都无法访问、查看或使用对其不可见的机构所拥有的任何数据。实际上，在此方面，一个机构的各成员不知道正在使用该数据库的另一个机构的存在，除非允许可见性的其它机构专门将它们列出。
最好是，安全性结构规定每个功能的目标具有与之相关的一个或多个许可权，这些许可权允许定义的功能被定义的成员执行，当机构之一的成员请求一项功能时，安全性结构需要确定该功能目标的许可权中包括所请求的功能和成员。
这样，无论发出请求的成员拥有什么权限，安全性结构都提供一种机制来确保功能本身对于该成员是允许的。因此，如果相关成员或拥有适当机构的管理权的成员发出更改该成员密码的请求，该请求只由安全性结构许可。对于拥有另一机构的管理权的另一机构的成员，不一定会许可。
最好是，安全性结构规定每个功能允许多个目标。此功能的最终授权将取决于对可以与每个功能相关联的可选商业逻辑(为了授权)的评估。这使系统能够对(可能)涉及多个机构的多个目标执行复杂的操作。
最好是，数据库存的数据文件具有相关许可权，这些许可权允许定义的成员对相应数据文件执行定义的功能，当机构之一的成员请求对数据文件执行一项功能时，安全性结构要求确定该数据文件的许可权中包括所请求的功能和该成员。
这样，即使特定成员确实有权执行特定功能、例如删除，除非该数据文件本身包括对该成员执行该功能的许可权，否则安全性结构也不允许执行此功能。
根据本发明，还提供一种计算机程序，它包括当该程序运行于计算机上时执行安全性结构的所有步骤的程序代码装置。
根据本发明，还提供一种计算机程序产品，它包括存储在计算机可读媒体上、在该程序产品运行于计算机上时执行安全性结构的步骤的程序代码装置。
参考附图，通过下文仅以举例的方式给出的说明，可以更加清楚地理解本发明。
图1说明实施本发明的配置；图2说明用户/应用服务器的交互作用；图3至6说明安全性结构的目录结构；图7说明组、用户/成员、角色和模板之间的关系；图8至10说明安全性结构检查流程；图11说明系统的参与者；图12说明安全性结构的概况；以及图13说明用户更改密码的流程图。
具体实施例方式
本申请提出一种媒体管理系统(MMS)，它被设计为允许多个公司或机构在数字媒体的管理和工作流程中进行合作。例如，MMS可让两个公司就同一个广告宣传活动进行合作，共享和处理该数字媒体(例如视频和图像)。MMS采用公共数据库，其中数据被划分到各数据库存中，以便将数据库划分为各个不同部分。通常，至少一部分采用MMS的机构对相应的数据库存拥有所有权。
如图1所示，设置数据库2用于存储数据。该数据被安排在数据库存4中，数据库存又可再划分成数据文件6。多个机构8可以通过外部网络10、诸如因特网或万维网访问数据库2。每个机构可以包括一个或多个成员12，它们本身可以通过属于各机构自有内部系统的网络链接。
外部机构8通过安全性结构14与数据库2实现接口。正如下文将要阐述的，安全性结构14包括存储有关机构8、成员12、数据库存4和数据文件6的信息，并管理哪些成员允许什么访问。当成员12请求有关数据库2的任何功能时，它还实现对可允许访问执行校验的过程。
安全性结构14可以构成物理接口或数据库的集成部分。但是，建议它以软件实现，并用于控制常规硬件。
MMS范围内的安全性可以认为包括两个主要部分。这两个部分是系统安全性和应用安全性。
系统安全性是与构成MMS体系结构的组件以及作为个体和整体时如何保证其安全性有关的系统方面的描述。系统安全性定义各个组件的如下事项-访问各组件(如数据文件6)的路径，即在系统内如何访问该组件。对于数据库服务器，这会描述哪些组件可以连接到服务器并执行SQL操作。为了理解(在常规操作下)可用来达到组件的网络路径，这是很重要的。
-访问该组件的实体(如成员12)的标识。对于万维网应用的情况，应用服务器充当系统内后端组件的代理。这意味着，后端组件除知道它正在被该应用服务器访问外，不太可能知道其它任何事，不知道用户身份。这对应用服务器内运行的应用程序提出更高的要求，以便确保它只执行允许用户进行的操作。
-在MMS系统范围内传递验证凭证的方法。这包括如何获得系统的用户(即机构8的成员12)的用户ID/密码，以及移动和存储应用服务器所要求的凭证，以便它可以访问后端服务。
-系统内各组件的备份和恢复过程。为使组件在受损的情况下可以可靠地恢复到先前的有效状态，这是需要的。
-系统安全性的最后一个要点是理解测试和验证为每个组件编写的策略的机制。
需要为之定义系统安全性的组件有目录服务器、万维网服务器、数据库、UNIX系统、FTP服务器、应用服务器以及资产贮存器和网络。
应用安全性解决应用如何在其内部实施安全性。这在n-层系统(尤其是基于万维网的系统)中尤其重要，因为万维网服务器/应用服务器在用户和后端资源(如图2所示)之间充当代理。
只要涉及到用户或成员，用户与应用程序的唯一交互是通过应用服务器。任何进一步的交互由应用服务器上运行的应用程序传递到要求的资源。从确保用户只能看到一个系统(实际有许多)的角度来看，这是一个优点。问题是后端资源不是直接知道用户的。它们只能完全相信应用程序所告知它们的。在常规布署方案中，应用服务器拥有一个用户和用于连接到诸如数据库之类的东西的密码。此ID拥有数据库内足够的许可权，可以执行所有用户的动作。这意味着，应用服务器是一个可对系统中其它组件实施攻击的潜在弱点。此问题可以被描述为“困惑的代理”问题，因为可以存在这种可能性将数据发送到应用服务器，并让它执行用户或许不能做的动作。其结果是应用服务器内的代码在处理任何动作时都需要知道如下三件事1.谁在执行动作；2.他们执行的是什么动作；3.他们对什么执行该动作。
本发明特别考虑到系统安全性。
为了实现安全性结构14，采用特定结构来完成目录服务器和LDAP(轻载目录访问协议)的工作。LDAP是一种作为用于访问在分层目录内组织的信息的机制而开发的协议。此结构树内的任何项目均可以通过识别其鉴别名(DN)来查找。该结构树在初始后缀下面组织。DN的组元列出其在层次结构中的位置。
图3表示其中拥有三个条目的树。该树的后缀DN为o＝mms。对应于存储在MMS中的各机构的其它条目及其DN分别为o＝SonyMarcomms，o＝mms和o＝Design Agency，o＝mms。值得注意的是，DN是新属性值对与其父叶的DN的组合。因此，如果需要在o＝SonyMarcomms，o＝mms下添加新的机构单元people，则DN可以为ou＝People，o＝Sony Marcomms，o＝mms。对应于树中的每个DN存储数据，可以表示的字段由目录方案来管理。
LDAP协议本身非常简单，其设计目的在于高效地访问条目，而非能够为之提供表示和功能查询接口。LDAP包括7种操作ADD、MODIFY、DELETE、MODRDN、BIND、UNBIND和REBIND。
存储在MMS的目录服务器中的层次结构是理解数据如何进行组织以及如何才能实现定义安全性所要求的映射的关键。在MMS目录服务器内，所有用户信息的基后缀均为o＝mms。此下的层次结构则被设计为反映应用的需要。
第一层分组属于预订MMS的机构。这些机构和相关角色、组和成员(将在下文中说明)彼此分开，这需要在树结构中予以反映。图3的实例显示其中拥有二个机构的树。在DIT(目录信息树)中，关于这些机构的条目附于该机构之下。机构还包括可见到此机构的其它机构的列表。机构的可见性是一个重要特征，将在下文予以说明。
机构8中拥有一定数量(0至多个)用户/成员12。这些用户/成员被分组归到机构的成员分支下，并按uid属性(用户ID)存储。如图4所示。
机构8还包括一定数量的组，为了管理用这些组将用户/成员12集合在一起，机构8还包括一些资产的访问许可权。这些组按cn属性(公共名)存储在机构的组分支之下。如图5所示。这些组本身由本身就可以是组的各成员构成。每个成员是指向用户或另一个组的鉴别名。
机构8还包括一定数量的角色，这些角色用于确定机构8内用户/成员的功能许可权。每个角色包括一个成员列表以及它所引用的角色全局(global of role)。MMS的角色信息以全局方式存储在DIT的模板部分。模板部分包括多个模板，各个模板定义特定的功能集，诸如读、写、编辑等。也可以规定模板只定义一个相应的功能。
为机构8创建的角色引用DIT模板部分内的单个模板。进而可以引用模板区内的其它模板。机构的角色在DIT中角色分支下查找，如图6所示。
为了使角色在系统内发挥作用，需要有一个不同机构所引用的角色全局主列表。该信息存储在DIT的ou＝Roles，cn＝Globals，o＝mms部分下。模板信息包括机构的缺省信息和在整个树中被引用的角色。
图7中表示组与角色之间在谁与谁相关方面的关系。
为了概述图7，一个组20包括零个或零个以上成员12以及零个或零个以上组20，一个角色22包括零个或零个以上成员12并引用一个和一个模板24，一个模板由零个或零个以上角色22引用并且引用零个或零个以上模板24。隐含意义是，成员12可以是零个或零个以上组20和角色22的成员。
给定目录服务器的结构和所存储的数据，定义获取用户的组关系可采用的过程是非常必要的。此过程需要满足DIT灵活性的要求，还要允许将来进行优化的可能性。这种优化必须通过将结果高速缓存来实现。此过程按如下所述进行。
-获取用户DN需要有用户或成员12的鉴别名才能开始此操作。可以采用以下LDAP过滤器利用用户的uid属性(因为它在该目录内是唯一的)来获取。
(uid＝用户ID)-列出用户直接所属的组利用你要查找其成员资格的用户12的DN，使用以下LDAP过滤器获取该用户12直接所属的组20的列表。
(&(objectclass＝mmsGroup)(|(uniquemember＝userDN)(mmsAdministrator＝userDN)(mmsOwner＝userDN)))-遍历这些组以找出完整列表对于每个组20，通过组20内的uniquemember字段内的dn引用获取它所属的组20(此操作是递归性的)。组20的用户12的当前列表是需要存储在一个集合内以便检查循环引用的成员。利用以下LDAP过滤器检查组20所属的那些组20(&(objectclass＝mmsGroup)(uniquemember＝groupDN))。
下文描述获取用户12能够执行的角色22的列表的过程。在高吞吐量环境中，此过程需要通过对结果进行高速缓存来优化。此过程按如下所述进行。
获取用户DN-需要有用户或成员12的鉴别名才能开始此操作。这可采用以下LDAP过滤器利用用户的uid属性(它是唯一的)来获取(uid＝用户ID)列出用户所属的角色-下一个阶段是列出机构8内为用户12分配的角色22。这通过以下LDAP过滤器来完成。
(&(objectclass＝mmsRole)(uniqumember＝userDN))遍历这些模板角色以创建最终列表-一旦已知机构8内的角色22的列表，就需要将各个角色(通过模板信息)映射到许可角色22和通过引用模板24定义的功能的最终列表。对于机构8的每个检索的角色22，必须进行查找以获取并入其中的子角色。这是一个遍历角色层次结构的递归操作，可以通过装入每个角色22的属性并利用uniquemember属性查找子角色来完成。
媒体管理系统提供一个可从外部机构8访问的数据库2，每个机构8具有一个或多个成员12。因此，成员12是本系统的用户12。
当用户12首先尝试在系统上执行一项功能时，安全性结构14尝试对用户12进行验证。
为了满足验证的要求，安全性结构支持如下两项1.验证一组凭证的能力对于要验证的用户12，它们必须向系统提供一组凭证。这些凭证之一始终是用户身份(对应于它们的用户ID)。第二个要求是用户还要提供可以被确认的令牌、如密码。然后，MMS可以提取这些凭证，并将它们与集中存储在目录服务器中的那些进行比较，以判断是否证实用户12有效。
2.在任何给定时间知道当前凭证的能力一旦用户通过验证，系统在执行过程中任何时候调用该信息。这意味着在应用控制流程中的给定点处，可以获取当前通过验证的用户12的身份。
一旦用户12在系统内通过验证，授权的三个要求之一被满足，因为应用程序就已知动作或功能的始发者。它还意味着，安全性结构14还可利用此信息，从而能够核查谁在MMS系统内执行了动作。
根据安全性结构的决策流程，给出图8所示作业链的第一步。
功能访问要求定义MMS内限定对系统内功能的访问权的要求。MMS内限定对功能的访问权的方法是通过角色22来实现的。如上所述，角色22定义可以在MMS内执行的功能。在其最简单级别，角色22是功能对所允许用户12的映射。因此，角色22涉及所有允许使用它的用户12。此外，还要求可以对角色22进行组合，以构成功能块(更类似于组中有组的形式)。
在MMS的范围内，提供两条信息，以便能够授权用户12执行动作。用户12必须通过MMS验证(如上所述)，用户12必须是他们尝试执行的角色22的成员。角色22本身是由MMS根据系统要求固定设置的(不可能定义新的角色)。需要有一个用于定义角色22和角色22的组的中心源。机构8可以根据它们的需要从其中提取。这可使不同机构在可以于MMS内使用的功能方面受到限制。这还意味着可以通过更改集中引用容易地对MMS添加功能和从中删除功能。
在用户交互方面，角色关系模型赋予开发者根据用户12拥有许可权来执行的功能向用户12呈现界面的能力，例如只有录入员看到录入标签。
遵循流程图，其中详细说明了为了判断用户是否被允许执行动作而需要进行的决策流程，给出图9所示的更新图。
图9表示检查操作或功能是否可允许的前两个步骤。功能本身不一定很重要(其目标才是重要的)。为了能够使用此方法，要点是给系统的最终用户12呈现可供管理角色22的分配和委托的界面。表示此功能的最佳方式视使用情况和参与者定义而定。此处的使用情况稍微与为资产管理定义的情况重叠，但这是在系统内分配角色22的最初源。
执行操作/角色此动作在用户12尝试在MMS内执行动作的情况下进行。这是适用于MMS内任何类型动作的通用使用情况。对此的授权是基于用户12是否是相应角色22的成员，同时也基于该动作所操作的数据是否属于他们拥有许可权的数据。下文参考图10进行说明。
创建角色此动作是在创建新角色22的情况下进行。这是管理功能。此动作所需的信息是要创建的角色的角色详情。角色22在机构8的范围之外创建，并被用作那些能够使用此角色的机构的模板。
删除角色此动作是在删除现有角色22的情况下进行。删除角色22连同MMS内对它的所有引用。这高效删除每个人的角色。这是管理功能。
赋予角色此动作为机构8内用户12赋予角色22的成员资格。此动作的必需信息是对用户8的引用以及将要为之授予他们许可权的角色22。此赋予可采取简单成员资格的形式，也可采取角色管理员的形式。对此动作的授权基于用户是否是用户管理员或机构管理员。
对角色添加角色此动作用于在角色22内对角色22组合。这可将一个角色22添加到另一个角色中。这可以创建角色包来对功能组合，更易于管理应用安全性。此动作要输入的是对正在添加的角色的引用，以及要添加到其中的角色的引用。这是管理操作。
从角色中删除角色此动作用于将角色22与另一个角色脱离组合。此动作是上一个动作的逆功能。此动作要输入的是对要删除的角色的引用以及对要从其中删除的角色的引用。这是应用环境外的管理操作。
撤销角色此动作从角色中删除用户的许可权。它可用于删除角色成员资格和角色管理员特权。此动作要输入的是对角色的引用以及对要从其中删除的用户的引用。此动作只可供作为用户管理员和机构管理员的用户使用。
将角色分配给机构此动作用于将角色22(或角色集)分配给机构8。使用此动作，使不同的机构8可被赋予不同的功能。此动作要输入的是对要分配的角色的引用以及对要分配到的机构的引用。这是管理动作。
从机构撤销角色此动作用于将角色22(或角色集)从机构8删除。此动作要输入的是对要删除的角色的引用以及对要从其中删除该角色的机构的引用。此动作是管理操作。
如上所述，安全性结构14所执行的安全性流程的建立是从对要验证用户8的初始要求直到确定他们是否拥有在MMS内执行功能或角色的许可权。安全性结构14为了可以授予对特定动作或功能的访问权还需要理解该动作目标指向的资源。采取这个要求得出安全性结构的最终决策流程，如图10所示。
作为此步骤的一部分，安全性结构14判断就相关目标是否列出拥有执行所请求功能的许可权的用户12。在对数据文件6本身执行动作或功能的情况中，数据文件6已将其本身与用户12的详情以及他们被允许执行什么功能(诸如读、写、编辑等)相关联。同样，在目标是有关用户12的数据时，只有用户12对他/她自己的数据进行动作或用户12拥有机构8的相应管理权时才允许该动作。图13说明用户尝试更改密码的流程图。
安全性结构包括用于存储针对数据和文件夹的许可权的机制。这些许可权基于用户12本身或用户12是否是已经分配有这些许可权的组20的成员。
还可以在资产元数据级指定许可权。
建议提供一种许可权层次结构，这将允许用户12授予其他用户12许可权以执行编辑。下表通过指定在LDAP中授予/撤销的许可权的平直列表来说明可能配置的方案
授予在撤销之前执行以确保一致性。例如，授予删除和撤销查看按确保两个动作互相抵消的顺序执行。
在用户交互方面，许可权模型为用户界面的开发者赋予根据资产和元数据许可权向用户呈现界面的能力。例如，如果用户没有对资产的编辑许可权，在都柏林核心元数据(Dublin Core metadata)屏幕上可以禁用输入字段和按钮。
资产具有所属的机构8和拥有者。拥有者可能是创建该资产/文件夹的用户，虽然此所有权关系可能随时间而改变(例如最初的拥有者离开公司)。所属机构可能是拥有者的机构，但是可能代表另一个机构创建资产。
代理资产与其主机具有同一机构。在如下情况时执行此规则-代理被录入-在主机上改变所属机构同样，“新版本”资产与它们的“前一版本”具有同一机构。在如下情况时执行此规则-版本被录入理解资产控制要求的最佳方式是查看与MMS内资产相关的使用情况，以及与资产和资产管理相关的角色种类。
使用情况是与文件夹和MMS内资产的管理相关的可执行动作。
创建根文件夹此动作的功能是创建用户或组文件夹。
创建子文件夹此动作的功能是在文件夹内创建文件夹。
编辑文件夹此动作的功能是编辑文件夹，例如更改有效日期。
设置文件夹拥有者此动作的功能是更改文件夹拥有者或所属机构。
删除文件夹此动作的功能是删除文件夹和它参与的任何包含关系(作为父文件夹和/或子文件夹)。软删除或硬删除均可供使用(可使用LDAP来配置)。软删除结束日期以使文件夹不再有效，而硬删除删除记录。
查看文件夹的访问权此动作的功能是查看文件夹的访问许可权。
授予文件夹的访问权此动作的功能是授予对文件夹的访问权。
撤销文件夹的访问权此动作的功能是撤销对文件夹的访问权。
编辑文件夹都柏林核心元数据此动作的功能是编辑文件夹的都柏林核心元数据。
添加文件夹的用户定义的元数据此动作的功能是向文件夹添加用户定义的元数据。
编辑文件夹的用户定义的元数据此动作的功能是编辑文件夹的用户定义的元数据。
删除文件夹的用户定义的元数据此动作的功能是删除文件夹的用户定义的元数据。
查看对文件夹用户定义的元数据的访问权此动作的功能是查看对文件夹用户定义的元数据的访问许可权。
授予对文件夹用户定义的元数据的访问权此动作的功能是授予对文件夹的用户定义的元数据的访问权。
撤销对文件夹用户定义的元数据的访问权此动作的功能是撤销对文件夹的用户定义的元数据的访问权。
创建链接此动作的功能是创建文件夹与其它文件夹/资产之间的包含关系。
删除链接此动作的功能是删除文件夹与其它文件夹/资产之间的包含关系。软删除或硬删除均可供使用(可使用LDAP来配置)。软删除结束日期以使链接不再有效，而硬删除删除记录。
录入资产此动作的功能是录入/创建资产。
录入代理此动作的功能是录入/创建作为另一个资产的代理的资产。代理应该为只读的，即不允许对代理的编辑许可权。如果用户授予编辑许可权，则MMS系统将会在业务层中出故障且不返回信息。
录入版本此动作的功能是录入/创建作为现有资产的新版本的资产。现有资产日期结束，从而不再有效。新版本被放置于现有资产所在的文件夹中。
编辑资产此动作的功能是编辑资产，例如更改有效日期。
设置资产拥有者此动作的功能是更改资产的拥有者或所属机构。
删除资产此动作的功能是删除资产和它所参与的任何关系。软删除或硬删除均可供使用(可使用LDAP来配置)。软删除让资产结束日期以使之不再有效，而硬删除删除记录。
查看对资产的访问权此动作的功能是查看资产的访问许可权。
授予对资产的访问权此动作的功能是授予对资产的访问权。
撤销对资产的访问权此动作的功能是撤销对资产的访问权。
编辑资产的都柏林核心元数据此动作的功能是编辑资产的都柏林核心元数据。
编辑资产格式元数据此动作的功能是编辑资产的格式元数据。此动作仅会在再次提取资产的格式元数据时执行，例如新格式元数据提取器被设为可用时。
添加资产的用户定义的元数据此动作的功能是向资产添加用户定义的元数据。
编辑资产的用户定义的元数据此动作的功能是编辑资产的用户定义的元数据。
删除资产的用户定义的元数据此动作的功能是删除资产的用户定义的元数据。
查看对资产用户定义的元数据的访问权此动作的功能是查看对资产用户定义的元数据的访问许可权。
授予对资产用户定义的元数据的访问权此动作的功能是授予对资产的用户定义的元数据的访问权。
撤销对资产用户定义的元数据的访问权此动作的功能是撤销对资产的用户定义的元数据的访问权。
创建代理关系此动作的功能是创建两个资产之间的代理关系。代理应该为只读的，因此所有对代理的编辑许可权都将被取消。
删除代理关系此动作的功能是删除两个资产之间的代理关系。
创建组任何验证的用户具有在MMS内创建组的功能。此组创建在他们的机构的范围内，用户被自动安装为该组的拥有者。然后就可以使用组来保存其它组和用户的集合，并且可用于限定对MMS内资产的许可权。此动作要输入的是要创建的组的名称。
删除组删除组是将其从系统中删除。它删除该组以及从其它位置对该组的任何引用(注意，如果存在对该组的引用，则应该显示警告消息)。此动作要输入的是对该组的引用。对此动作的授权是根据用户是否是组的拥有者、机构管理员或MMS管理员而定的。
授予组的成员资格这是用户授予另一实体(用户或组)某个组内成员资格的动作。此动作要输入的是要授予的成员资格所属的组和对要添加到该组的用户/组的引用。对此动作的授权是根据用户是否是组的拥有者、机构管理员、域管理员或MMS管理员而定的。
从组中撤销成员资格这是从某个组删除一个实体(用户或组)的动作。此动作所要输入的是对该组的引用和对要从其中删除的实体的引用。对此动作的授权是根据用户是否是组的拥有者、机构管理员、域管理员或MMS管理员而定的。不能对组的拥有者撤销成员资格。
本部分定义文档中用到的术语。原因是在ASP(应用服务提供商)环境中提供基于角色的安全性体系结构是一个复杂的操作。
记住，现在安全性结构14要求能够理解给定动作所操作的目标，下一阶段定义表示MMS内目标的方法。参考图3到图6进行上述讨论。表示需要的方法足够通用，使得安全性管理器只需知道到哪里查询请求是否被允许，而无需知道所有可能的目标。这相当于知道如何转换角色的规则即可，而无需知道所有现存的角色。因此，框架对于所考虑的资源是中立的，它提供用于访问数据库内诸如资产和文件夹等的基础，同时还能够处理对目录服务器内的角色22、用户12和机构8的查询。
图10所示的目标定位的最后一个方面是MMS内的资源和信息所具有的可见性。任何机构8需要能够指定它们准备与之合作的机构8。这种关系需要明确。这需要是在流程的“动作目标是否允许”部分中的第一检查之一。因此，诸如数据库存4或数据文件6的任何资源都需要为某个机构8所有，并且任何访问都需要由所属机构的机构优选来作为中介。
在运行MMS时，允许各个操作员或参与者根据他们属于MMS的职责拥有不同级别的控制权。图11说明参与MMS的各种参与者。
用户12是MMS内的基本单元。用户12能够在系统内执行除录入新资产以外的大多数动作。用户可以修改他们自己的数据和他们拥有访问权的数据、创建和控制组20以及搜索/下载资产。用户12对系统拥有的访问权取决于他们所属的机构8和组20。
用户管理员30被允许执行用户12可以执行的任何动作，并且另外还拥有关于在MMS内创建和管理用户12的功能。用户管理员30可以在与它们自己相同的机构8内控制角色22、密码和用户12的个人详细信息。他们还可以在他们的机构内创建新用户12。
允许文件夹管理员32执行用户12可以执行的任何动作，以及另外还拥有关于文件夹(即数据文件6的集合)管理的功能。文件夹管理员32可以管理他们机构8范围内的任何文件夹。这包括创建、删除和许可。
允许组管理员34执行用户12可以执行的任何动作以及另外还拥有关于组管理的功能。组管理员34可以管理他们自己机构8范围内现有的任何组。
允许资产管理员36执行用户12可以执行的任何动作以及另外还拥有涉及资产的职责和功能。资产管理员拥有对他们机构所有的任何资产的管理特权以及录入新资产的功能。
机构管理员38拥有对属于他们自己机构8范围内的任何对象的管理特权。
录入员40是一个特殊角色，供可以将新资产引入系统但不能搜索和查看现有资产的人使用。此职责应该被指派给负责批量录入新资产的人，或者此职责可以添加给用户12，以赋予他们录入文件的附加特权。
MMS还可以包括核查功能。
就安全性而言，有两种使用术语核查的方式。它们是核查应用或系统的安全性的功能以及核查应用内发生什么的功能。这两个功能都很重要。要理解这些要求，重要的是理解在MMS环境中如何控制安全性。
如图12所示，通过应用内的安全性结构14的基本流程，动作才会被执行。如上所述，安全性结构根据尝试执行该动作的用户12的许可权、他们的角色以及尝试执行动作所针对的对象作出关于是否执行该动作的决策。在这一点，该结构记录所尝试的动作以及该动作是被允许还是被拒绝。然后，就可以尝试执行该动作，并向调用者返回任何响应或告知调用者他们没有足够许可权执行所请求的动作。
在发行应用程序之前会测试其安全性。万维网应用程序在此方向上提出引起关注的难题，因为HTTP协议是无状态的。因此，可能请求一个页面，但是不一定访问过紧邻的前一个页面。一旦用户12进行授权的会话，他们可(在理论上)触发系统内的任何动作。因此，需要一个彻底审查和测试过程，以便确保安全性结构14在限定应用程序内的访问权时正常发挥作用。从这个角度来看，极重要的是该结构拥有尽可能少的入口点(在本例中为一个)，这样就只有一个为执行此检查而需要实施的接口。
一旦应用程序运行，用户12就可以访问具有不同级别许可权的功能。可以记录谁在系统内何时做过什么是非常重要的，这样可以追踪系统内的潜在问题。应用程序内的所有动作按动作粒度被记录，这是重要的。可以使用软件来分析万维网服务器记录并且达到非常接近此功能。此处的问题是，请求该动作的用户12不一定会被捕捉到，而且也可能未捕捉到该动作的参数和详细信息。因此，该系统内进行的所有动作都会被记录。能够实现这一点就允许如下事项支持桌面任何技术支持功能都将(在某个阶段)需要知道用户12一直在尝试什么动作，以便帮助他们处理问题。从帮助桌面的观点来看，最好有关于用户正在做什么的两个角度，使得它们可以从用户那里获取用户认为他们正在做什么的信息，以及从系统获取系统认为他们正在做什么的信息。这还可在系统的用户界面内提供到不一致性区域的极好反馈路径。
可计量性如果核查数据库中出现某个情况，则可能是用户执行(或尝试)了该动作。这在机构与技术支持交谈时申明应用程序出错以便盖住用户错误的支持情况中非常有帮助。在ASP环境中，各公司可能彼此共享资产，在法律角度上来说，这对于MMS供应商也是重要的。在此情况下，两个竞争对手公司不希望对方具有其资产/公司架构的可视性。在可能授予此访问权的情况下，能够证明此访问权不是因为应用程序出错而授予的，这对于MMS供应商来说非常重要。在允许访问权的用户ID泄密时，仍允许MMS供应商能够说明违反安全性的发生是因为特定帐户泄密。
验证安全性受损理论上，黑客可能获取进入运行MMS的系统的入口，在应用环境外对一些东西进行更改。核查跟踪提供一些东西来对照比较，以便可以判断此类更改的性质和范围。
识别可能的非法入侵尝试核查数据库也记录对用户无访问权的东西进行访问的尝试。如果用户界面完善，就应该不会发生这种情况。实际上，这种情况会出现，只是应该不会经常出现。若能看到失败执行()动作的次数，就可以初步确认可能的入侵尝试和所尝试的安全性侵犯。例如，用户帐户可能被泄密，黑客利用它来操纵HTTP请求以尝试触发其它动作。此类活动会在日志记录的分析时显示，这可供MMS的管理员决定是否需要监控或锁定用户帐户。
为了完整，下文给出上文所用的一些术语的定义。
ASP(应用服务供应商)ASP是多个机构的应用供应商。这表明此类应用供应商为个人组成的多个集体提供服务。从应用的角度来说，意味着对每个机构提供一个功能块，且这些功能块不一定相同。另外，应用需要同时知道用户身份及其所属机构，以便理解其安全性要求(这也会影响数据的可见性)。
组在此文档中，组是为了组织涉及资产访问的用户的集合而使用的实体。组可以跨机构，即单个组可以包含多个机构的成员。组还可以分层设置，这样可以在MMS框架内组中有组。
角色角色是用于在MMS内定义职责和可用功能的机制。角色是用于对用户的操作功能进行分组的机制。它们存在于单个机构的范围内，而不能跨多个机构。原因是为了保持角色与组之间非常明确的区分。角色以对于整个MMS来说全局的方式存储，然后根据各个机构的需求被引用，这样不同的机构就可以被赋予不同的功能。全局角色可以包含所包括的角色列表，这样可以将角色组合到角色包中。这种分组不在机构级进行。
验证验证是从MMS的最终用户提取一组凭证并对照中央保存储存内容来验证它的过程。最终结果可以说具有合理的可信度，被验证的用户是他们所声称的身份。
授权授权是选择通过验证的用户并决定允许他们在MMS内执行动作或操作。授权只能对通过验证的用户进行。
用户用户是使用MMS应用的个体。用户属于单个机构。用户还可以属于零个或零个以上组，并被指派零个或零个以上角色。
机构机构是使用MMS来管理它们的数字资产的实体。一个机构由许多用户、组和角色组成。
资产资产是存储在MMS内的数字媒体。
目录服务器目录服务器是MMS系统内的组件，它存储MMS内所有用户、组、机构和角色的目录。这是完成关于安全性判断的决策的中央库。
应用服务器应用服务器是MMS应用所在的平台。它提供创建应用所基于的基础设施(例如/J2EE万维网和豆容器)。
动作动作是用户在MMS系统内执行的功能/操作。它也可以称为操作。
文件夹文件夹是MMS内对项目分组的方式。MMS实质上可以视为媒体资产的虚拟文件系统。在此上下文中，文件夹是一系列资产或其它文件夹的容器。
可见性理解ASP环境中的可见性的概念是很重要的。通常，机构都不具有对ASP内其他机构的任何可见性。在MMS的情况中，机构之间彼此许可对方的可见性，为了在机构之间对媒体协同工作和共享媒体，这确实是必要的。缺省情况下，机构(及其所有相关资源)对于MMS内的任何其他机构是不可见的。可以更改此可见性来允许完成机构间协同工作(但其关系是明确的而非暗含的)。
权利要求
1.一种数据管理系统，它包括用于存储多个数据库存的数据库；以及用于控制在所述数据库的数据库存中数据的存储以及允许多个外部机构访问所述数据的接口，每个机构包括一个或多个各自的成员；其中所述接口包括控制所述机构的成员对所述数据的访问的安全性结构。
2.一种为多个外部机构提供对包含多个数据库存的公共数据库的访问的方法，每个机构包括一个或多个各自的成员，所述方法包括用于控制所述机构的成员对所述数据的访问的安全性结构的各步骤。
3.一种供存储多个数据库存的数据库使用的安全性结构，所述安全性结构实现不同外部机构与所述数据库存的数据之间的接口，每个机构拥有一个或多个各自的成员，而且所述安全性结构控制不同机构的成员对所述数据库存的数据的访问。
4.如权利要求1、2或3所述的系统、方法或结构，其特征在于，所述机构操作各个数据存储/通信系统并且包括至所述数据库的外部连接。
5.如权利要求4所述的系统、方法或结构，其特征在于，所述数据存储/通信系统包括用于相应系统的各种管理员权限。
6.如前述任一权利要求所述的系统、方法或结构，其特征在于，所述成员对数据的访问至少包括读、写和编辑所述数据。
7.如前述任一权利要求所述的系统、方法或结构，其特征在于，所述数据库存具有不同的相应所有权关系。
8.如前述任一权利要求所述的系统、方法或结构，其特征在于，一个或多个所述数据库存为相应的机构所有。
9.如前述任一权利要求所述的系统、方法或结构，其特征在于，所述安全性结构允许所述成员请求有关所述数据库的功能的操作，所述功能包括对数据的访问。
10.如权利要求9所述的系统、方法或结构，其特征在于，所述机构之一的成员请求功能时，安全性结构要求所述成员的ID通过验证。
11.如权利要求9或10所述的系统、方法或结构，其特征在于，所述安全性结构包括可供所述机构的相应成员使用的功能列表，当所述机构之一的成员请求功能时，所述安全性结构要求判断所请求的功能是否可供所述成员使用。
12.如权利要求11所述的系统、方法或结构，其特征在于，所述安全性结构包括关于每个机构的一个或多个角色，每个角色与一个或多个功能相关并且定义有资格操作所述角色的所述一个或多个功能的机构的成员。
13.如权利要求12所述的系统、方法或结构，其特征在于，所述安全性结构包括一个或多个模板，每个模板提供一个或多个功能的列表，以及所述角色具有指向所述模板的指针，以便指示所述一个或多个功能可供为所述角色定义的成员使用。
14.如权利要求9至13中任一个所述的系统、方法或结构，其特征在于，所述安全性结构包括关于每个相应机构的、可见到所述相应机构的所有其他机构的指示，当所述机构之一的成员请求功能时，所述安全性结构要求确定所述功能未要求访问对于所述成员的机构不可见的机构所拥有的数据库存的数据。
15.如权利要求9至14中任一项所述的系统、方法或结构，其特征在于，所述安全性结构规定功能的每个目标具有与之相关的一个或多个许可权，所述许可权允许定义的成员执行定义的功能，以及当所述机构之一的成员请求功能时，所述安全性结构要求确定所述请求的功能和所述成员包含在所述功能的目标的所述许可权中。
16.如权利要求9至15中任一个所述的系统、方法或结构，其特征在于，所述安全性结构规定每个功能允许多个目标。
17.一种系统、方法或结构，其中所述数据库存的数据文件具有相关的许可权，所述许可权允许定义的成员对相应数据文件执行定义的功能，以及当所述机构之一的成员请求对数据文件执行的功能时，所述安全性结构要求确定所请求的功能和所述成员包含在所述数据文件的所述许可权之中。
18.一种计算机程序，它包括用于在计算机运行所述程序时、执行前述权利要求中任一个的所有步骤的程序代码装置。
19.一种计算机程序产品，它包括存储在计算机可读媒体中、用于在计算机上运行所述程序产品时执行权利要求1至17中任一个的所有步骤的程序代码装置。
全文摘要
一种数据管理系统，它包括用于存储多个数据库存的数据库；以及用于控制在所述数据库的数据库存中数据的存储并允许多个外部机构访问所述数据的接口，每个机构包括一个或多个各自的成员，其中所述接口包括控制机构成员对数据的访问的安全性结构。
文档编号G06F21/62GK1495638SQ0315797
公开日2004年5月12日 申请日期2003年9月2日 优先权日2002年9月2日
发明者J·W·赫斯, J W 赫斯, A·瓦尔克 申请人:索尼英国有限公司