大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台

摘要

本发明公开一种大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台，包括跨域认证管理模块、授权管理模块、机构管理模块、人员管理模块、菜单管理模块和日志管理模块；跨域认证管理模块设在SAML处理服务器上，授权管理模块设在子系统XACML服务器上，机构管理模块、人员管理模块、菜单管理模块和日志管理模块均设在业务处理系统服务器上。该平台利用XACML对用户进行授权和访问控制，利用SAML跨域数据交互对用户进行身份认证。采用基于RBAC访问控制模型的XACML框架，通过读取用户的XACML文件来对用户权限进行限制，大大增强了对用户细粒度的授权。分布式系统中不同平台通过互相交换SAML信息来提供断言的方式，使得平台之间传输信息更加安全，数据传输量更少。

说明书

技术领域

本发明涉及大数据环境下分布式平台管理技术领域，具体是一种大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台。

背景技术

在当今一些大型企业的大数据分布式系统应用中，分布式结构比较复杂，各应用系统使用不同的授权和访问控制方式，并采取不同的安全策略。对于不同的应用系统，数据之间的存储和交互，如账户管理、登录、人员组织管理、访问控制授权、跨域认证等。随着应用的越来越复杂，管理这些信息也愈加复杂，难以控制。不同的用户对应不同的应用系统，不同的应用系统仅对本系统的资源进行认证管理和访问控制，同一用户在不同的应用系统中的权限可以完全不同。因此，在分布式系统中，对用户在不同系统中的认证、授权就会非常凌乱，各系统不同的登录方式、用户角色/权限冲突、账户管理都会带来系统管理员负担繁重、权限细粒度管理复杂、用户跨域访问不便、系统可扩展性、可移植性较差等一系列问题。

发明内容

发明目的：针对现有技术中存在的不足，本发明的目的是提供一种大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台，主要完成对企业分布式集成平台的管理和设置，提供机构管理、菜单管理以及人员管理权限管理等功能。

技术方案：为了实现上述发明目的，本发明采用的技术方案为：

一种大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台，包括跨域认证管理模块、授权管理模块、机构管理模块、人员管理模块、菜单管理模块和日志管理模块；跨域认证管理模块设在SAML处理服务器上，授权管理模块设在子系统XACML服务器上，机构管理模块、人员管理模块、菜单管理模块和日志管理模块均设在业务处理系统服务器上；其中，

所述跨域认证管理模块：Web客户端在两种情况下需要向SAML服务器端发送数据：（1）用户成功登录时，客户端必须告诉SAML服务器端，用户已经在某个子系统登录，服务器端记录下用户登录的子系统IP地址和时间，并根据业务需求选择是否需要回复信息；（2）用户进行跨域访问时，客户端必须告诉SAML服务器要访问的子系统IP地址，服务器根据请求回复用户账户状态信息，各子系统根据不同业务认证要求进行判定并告知客户端，如果符合要求，则用户成功登录，否则需要重新认证；

所述授权管理模块：客户端以用户名/密码、指纹识别或电子身份卡等方式登录，或符合跨域认证要求时，授权管理服务器通过管理和维护XACML访问控制策略，利用策略管理点PAP来维护用户、角色、权限和策略之间的关系；

所述机构管理模块：用于管理系统所有一级与二级机构，二级机构权限必须限制在一级机构权限范围内，机构的权限信息存储在XACML文件内，其他信息存储在数据库中；

所述人员管理模块：对用户的增加需要确定用户所属部门，获得该部门的权限信息，人员的权限信息存储在XACML文件内，其他信息存储在数据库中；

所述菜单管理模块：菜单分为一级菜单和二级菜单，当添加菜单时，必须输入不同的菜单名，通过Ajax进行后台验证后即可，二级菜单必须隶属于某个一级菜单；

所述日志管理模块：日志模块记录了所有人员的所有正常和异常操作信息，管理员可以根据人员和时间查看所有人员的操作信息。

所述的大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台，用户在该平台的访问权限则通过读取XACML文件来完成；XACML文件上保存该用户允许访问的资源地址以及可以进行的操作；通过读取XACML文件，直接获取用户所有权限，简化策略决策点PDP和策略执行点PEP执行过程。

所述的大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台，用户在跨域访问的认证与授权服务中，源站点平台并不需要关心目的站点的用户认证与授权问题；不同的站点拥有不同的认证方式，即使是同一用户也会拥有不同的权限；目的站点只要和SAML服务器进行数据交互，获取用户已在源站点进行认证的结果，通过分析SAML服务器返回的SAML信息，根据信息来确认用户是否认证；整个过程对用户是透明的，用户在进行跨域访问时，好像登录的是同一个系统的不同应用模块一样。

所述的大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台，系统管理员通过菜单管理提供新功能，并给指定的部门设定指定的菜单权限；部门权限管理同用户权限管理相同，都通过修改XACML文件来实现。

所述的大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台，Web服务提供者向用户提供服务之前，必须经过平台的认证并获得授权后才具有访问Web资源的权限。

在所述跨域认证管理模块中，SAML服务器仅用于存储、接收/回复子系统信息请求，本身并不作为判定认证的关键节点。

在所述机构管理模块中，存储在数据库中的其他信息包括机构名称、机构描述、创建日期、机构状态等；在所述人员管理模块中，存储在数据库中的其他信息包括用户名、密码、注册日期、登录日期、用户状态、所属机构、账户安全状态等。

所述授权管理模块包括部门授权管理模块和用户授权管理模块，部门授权管理模块中的部门XACML授权方法如下：

1）建立<PolicySet>元素，<PolicySet>中包含了部门<Target>访问过滤素和规则算法；

2）建立<Target>元素，在该元素中包含了所有的部门权限：主体、可访问资源、主体操作；

3）建立<Subject>主体限制，<Subject>采取的匹配条件是字符串相同；用户所属部门的ID必须和<Subject>中的AttributeValue保持一致，即限定只有该部门的用户才可以访问一定的可访问资源和采取一定的主体操作；

4）建立<Resource>资源限制；部门权限的设置仅仅是该部门用户可以看到权限内允许看到的菜单，即URL地址；一个部门拥有对多少菜单的权限，即建立多少个<Resource>元素，如果没有找到对应的匹配地址，则该部门内所有用户均不能访问；

5）部门内不同的用户拥有的Action不同，因此部门权限并不设置具体的<Action>元素，即对部门权限而言，所有动作均可以；

6）建立<Policy>策略和确认Rule；当用户被系统成功认证后，首先读取的是<Target>元素，得到该部门可以访问的<Resource>元素即对应菜单栏；不同用户在每个菜单栏下的可以进行的具体Action操作，则通过用户权限管理的用户XACML文件获得，因此，部门权限中对所有用户的Policy中的Rule均为“Permit”；

7）确认该部门PolicyCombiningAlgId和RuleCombiningAlgId算法；部门权限中对所有用的Policy和Rule均为Permit，所以策略和规则算法选择“deny-overrides”（拒绝覆盖），即全部通过。

所述用户授权管理模块中的用户XACML授权方法如下：

1）建立<PolicySet>元素，<PolicySet>中包含了用户<Target>访问过滤元素和PolicyCombiningAlgId：deny-overrides；

2）建立<Target>元素；在该元素中仅包含了<Subject>（主体），只有当session中的用户主体ID和<Subject>中的ID一致时，才可以获取必要的用户权限；<Subject>采取的匹配条件（MatchId）是“string-equal”（用户ID字符串相同）；

3）建立用户策略<Policy>和规则算法RuleCombiningAlgId，用户的策略包含若干个<Rule>（规则），每个<Rule>规定了该用户对每个模块URL的访问权限，每个模块中的CRUD操作权限均通过读取该模块<Rule>实现；所有的<Rule>元素均需要遵守规则算法：deny-overrides（拒绝覆盖）；

4）建立每个模块的<Rule>；在该元素中包含了该模块的<Resources>和<Actions>。<Resources>限制了用户可以访问的URL地址，<Resources>采取的匹配条件（MatchId）是“anyURI-regexp-match”（模块URL地址正则匹配）；在一个模块内的CRUD操作均可以采用类似的地址，仅仅是地址后的匹配参数不同。<Action>限制了在该模块URL中可以实施的动作，即CRUD。<Actions>采取的匹配条件（MatchId）是“string-regexp-match”（动作名称正则匹配），如查询动作是find开头，添加动作是add开头等；

5）制定<Rule>的Effect（效果）；在每个<Rule>中，只要MatchId匹配即可访问，所有<Rule>的Effect都为Permit（允许）；如果用户没有读取到部门权限中允许的URL地址，则不能访问该部门内的URL；通过对<Rule>的读取，用户操作的细粒度大大增加。

在所述跨域认证管理模块中，在传递SAML请求时，对XML消息进行局部加密，加密传输XML过程如下：

1）各子系统资源站点首先与SAML站点约定不同的固定密钥，采用AES双向加密；此密钥仅仅用于各子系统首次向SAML站点发送通信请求，不包含认证请求或结果；此密钥可以与各子系统约定定期更换；

2）SAML站点中用自身的密钥保存各站点首次通信的固定密钥。用来保证首次通信的安全；

3）各子系统首次向SAML站点发送通信请求，此请求可以是IP地址或者是该子系统的标识，可以用明文发送；

4）SAML站点根据各子系统发来的请求找到对应子系统首次通信的密钥，并产生一个临时密钥(session-key)，用双发约定好的固定密钥将此临时密钥加密，传递给该子系统；

5）各子系统用固定密钥解密，得到临时密钥，产生SAML请求或本系统用户验证结果，用临时密钥将XML消息部分加密，发送给SAML站点；

6）SAML站点接受子系统发来的SAML请求或结果，用临时密钥将XML消息解密获得数据对象及其属性，并产生身份验证声明，发送给请求子系统；

7）请求子系统根据SAML决策结果决定是否访问XACML站点和资源站点。

有益效果：与现有技术相比，本发明大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台，主要完成对企业分布式集成平台的管理和设置，提供机构管理、菜单管理以及人员管理权限管理等功能，具有以下优点：

1）在大数据环境下分布式系统，不同系统、不同部门对用户认证方式、访问控制的需求和采用的访问控制策略可能完全不同。传统基于SQL结构化数据库访问控制读取方式，仅限于考虑角色、属性或政策等，当用户需求发生更改时，扩展性较差，资源访问的粗细粒度不易掌握，也无法适应NoSQL等大数据非结构化数据环境。本发明能够以统一及可移植的方法和更丰富的XACML词汇来描述这些访问控制的内容，使系统管理员能够对用户进行更细粒度的访问控制，极大的增强了访问控制的可扩展性。

2）在大数据环境下分布式系统环境下，资源访问控制由集中管理方式变成了分布式管理方式，资源访问验证逻辑复杂，缺乏整体考虑。为防止各子系统用户授权违规和非法用户的访问，本发明基于XACML的分布式系统访问控制语言，支持对上下文和环境资源属性的考虑，支持对策略规则的条件约束、冲突检测及消除，弥补了系统的安全性问题。用标准的XML标签在分布式不同系统间交换访问控制信息，使系统可以交换或共享授权策略。

3）在大数据环境下分布式系统环境下，各子系统将差异化的用户信息放置在自身平台的存储中，可以使用XACML或其它方式管理自己的用户登录与授权信息，避免使用统一的用户信息管理点。本发明利用一个共享的单点登录身份认证平台，仅接受、发送和记录SAML信息。SAML仅仅是交换信息的标准，本身并不负责对信息进行判定，各子系统根据自身需求对该信息进行判定。当该认证平台出现异常，仅仅影响单点登录，不会影响各子系统的认证和授权。

4）本发明利用Kerberos传输方式：通过与单点登录身份认证平台接收/发送自定义的SAML信息，企业可以在不改变自身访问认证与授权框架的基础上，就可以与其他平台安全地交换关于用户登录或交易等信息。且SAML信息与开发语言及平台数据库无关，相互独立。在传输中，使用AES对其局部核心信息进行加密，安全性高，传输量小，适用于频繁的跨平台登录。

附图说明

图1是平台硬件系统示意图；

图2是管理平台的工作过程示意图。

具体实施方式

下面结合具体实施例对本发明做进一步的说明。

实施例1

本发明的大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台，如图1所示，硬件主要由客户端、SAML处理服务器、子系统XACML服务器、业务处理系统服务器组成。其中，客户端可以为计算机、手机、平板等；SAML处理服务器可以选用戴尔R730，双CPU，数据中心级固态硬盘300G，32G内存，Raid5阵列；子系统XACML服务器可以选用戴尔R730，双CPU，数据中心级固态硬盘600G，64G内存，Raid5阵列；业务处理系统服务器可以选用戴尔R730，双CPU，数据中心级固态硬盘600G，64G内存，Raid5阵列。工作时，客户端发送跨域请求给SAML处理服务器，SAML处理服务器回复用户账号状态信息给子系统XACML服务器，用户通过客户端以用户名/密码、指纹识别或电子身份卡等方式直接访问子系统XACML服务器；子系统XACML服务器调用业务处理系统服务器进行处理。业务处理系统服务器主要通过对应的模块处理人员管理、机构管理、菜单管理、日志管理、其他业务管理等。

Web服务提供者向用户提供服务之前，必须经过平台的认证并获得授权后才具有访问Web资源的权限；该平台的处理系统包括：跨域认证管理模块（设在SAML处理服务器上）、授权管理模块（设在子系统XACML服务器上）、机构管理模块（设在业务处理系统服务器上）、人员管理模块（设在业务处理系统服务器上）、菜单管理模块（设在业务处理系统服务器上）和日志管理模块（设在业务处理系统服务器上）。

跨域认证管理模块：Web客户端在两种情况下需要向SAML服务器端发送数据：（1）用户成功登录时，客户端必须告诉SAML服务器端，用户已经在某个子系统登录，服务器端记录下用户登录的子系统IP地址和时间，并可以根据业务需求选择是否需要回复信息；（2）用户进行跨域访问时，客户端必须告诉SAML服务器要访问的子系统IP地址，服务器根据请求回复用户账户状态信息，各子系统根据不同业务认证要求进行判定并告知客户端，如果符合要求，则用户成功登录，否则需要重新认证。其特点是SAML服务器仅用于存储、接收/回复子系统信息请求，本身并不作为判定认证的关键节点。

授权管理模块：当客户端以用户名/密码、指纹识别或电子身份卡等方式登录，或符合跨域认证要求时，通过授权管理模块来获取访问控制权限。授权管理服务器通过管理和维护XACML访问控制策略，利用策略管理点PAP来维护用户、角色、权限和策略之间的关系。

机构管理模块：用于管理系统所有一级与二级机构，二级机构权限必须限制在一级机构权限范围内，机构的权限信息存储在XACML文件内，其他信息存储在数据库中。

人员管理模块：此模块对用户的增加需要确定用户所属部门，获得该部门的权限信息，对用户的其他操作，通过用户名即可，用户的其他信息存储在数据库中。

菜单管理模块：菜单分为一级菜单（主菜单）和二级菜单，当添加菜单时，必须输入不同的菜单名，通过Ajax进行后台验证后即可，二级菜单必须隶属于某个一级菜单。

日志管理模块：日志模块记录所有人员的所有正常和异常操作信息，管理员可以根据人员和时间查看所有人员的操作信息。

用户在该平台的访问权限则通过读取XACML文件来完成。XACML文件上保存该用户允许访问的资源地址以及可以进行的操作。通过读取XACML文件，直接获取用户所有权限，简化策略决策点PDP和策略执行点PEP执行过程。

用户在跨域访问的认证与授权服务中，源站点平台并不需要关心目的站点的用户认证与授权问题。不同的站点拥有不同的认证方式，即使是同一用户也会拥有不同的权限。目的站点只要和SAML服务器进行数据交互，获取用户已在源站点进行认证的结果，通过分析SAML服务器返回的SAML信息（XML格式的字符串包），根据信息来确认用户是否认证。整个过程对用户是透明的，用户在进行跨域访问时，好像登录的是同一个系统的不同应用模块一样。

该平台主要完成对企业分布式集成平台的管理和设置。它提供机构管理、菜单管理以及人员管理权限管理等功能。系统管理员通过菜单管理提供新功能，并给指定的部门设定指定的菜单权限。部门权限管理同用户权限管理相同，都通过修改XACML文件来实现。

如图2所示，该大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台的工作过程：

用户子系统登陆请求，发送SAML信息给跨域认证管理模块，跨域认证管理模块查询用户账户状态。跨域认证管理模块接受SAML信息，子系统判定SAML信息，如结果为未在分布式环境下登陆或账户会话已经失效时，进行子系统自身认证方式判断（用户名/密码、指纹、电子身份卡等），获取子系统会话，在跨域认证管理模块中写入跨系统认证管理模块日志，更新用户账号状态，同时在授权管理模块中读取分析用户XACML文件，获取资源操作权限；如结果为已在分布式环境下登陆或账户处在有效期内时，直接实现单点登录，在授权管理模块中读取分析用户XACML文件。授权管理模块判定是否为超级管理员，当为否时，进行相关的系统自身业务操作（如数据查询、决策分析等）；并在日志管理模块中进行日志记录、分析；当为是时，通过菜单管理模块中进行菜单信息管理、菜单层级管理等，通过用户管理模块以及机构管理模块进行用户管理、机构管理、XACML权限设置管理等，并在日志管理模块中进行相关日志记录、分析，以及可以进行相关的系统自身业务操作（如数据查询、决策分析等）。

实施例2

采用实施例1的大数据环境下基于XACML和SAML的分布式系统认证与权限管理平台，本实施例给出企业大数据分布式应用示例平台的整体设计，同时对授权管理模块、跨域认证管理模块、人员管理模块、菜单管理模块和日志管理模块进行实现，并对其中涉及到的关键技术和算法给予了详细介绍。

1）机构管理

机构管理模块中实现了部门-角色的信息维护。在系统中，用户不直接与角色打交道，用户属于一个具体部门时，也就具备了该部门的角色信息，每个部门可以看到该部门权限内能看到的功能菜单。

当部门权限变化时，用户的策略文件无需改变。如果修改后的部门权限小于当前权限，则用户多余的策略为忽略；当修改的后的部门权限大于当前权限时，则增加用户的策略即可。这样，用户策略文件改动量很少，用户-角色之间的耦合度就大大降低。

2）人员管理

在人员管理模块中，主要包含对用户的增加、修改、删除和查询四种功能。

用户的操作权限存储在XACML文件中。此模块对用户的增加需要确定用户所属部门，获得该部门的权限信息。对用户的其他操作，通过用户名即可，用户的其他信息存储在数据库中，不和XACML打交道。

对于大部分系统而言，用户权限仅限于部门权限限制是远远不够的。通常一个部门还会下辖若干个拥有不同权限的用户，不同的用户所能看到的菜单也是不同的。同时，一个菜单下，也会拥有至少4种对数据库的不同操作，即CRUD（增加、查询、修改、删除）。因此，需要对用户权限进行更加细粒度控制，管理员需要限制不同用户的CURD权限。如该机构管理员拥有所有的权限，而员工只拥有查看自己信息或者增加信息的权限。系统对用户权限的新增、修改均是通过修改XACML文件。当新增一个用户时，系统默认该用户无任何权限，用户只能通过系统认证，而无任何授权。当对用户进行授权时，则对该部门（角色）所允许的菜单分为CRUD四种权限，用户可以获得部分菜单下的部分操作权限，细粒度控制大大增加。

3）菜单管理。

菜单模块中，菜单分为一级菜单（主菜单）和二级菜单。当添加菜单时，必须输入不同的菜单名，通过后台验证后即可。二级菜单必须隶属于某个一级菜单。

4）日志管理

日志模块记录了所有人员的所有正常和异常操作信息，管理员可以根据人员和时间查看所有人员的操作信息。

5）授权管理模块

授权管理模块包括部门授权管理模块和用户授权管理模块，本系统部门授权管理和用户授权管理采用XACML框架，为每个部门、用户建立一个以XACML框架为标准的XML文件。当用户登录系统时，系统读取该用户权限的XML文件，并存入到内存中。用户进入系统后，所有的权限操作都从内存中读取。当系统的部门数目、角色数目和用户数目都急剧增加时，采用传统的数据库描述方式需要从上百万条甚至更多的记录数中查询该用户拥有的多条权限，对数据库压力很大。而采用以标准XACML框架的XML文件时，系统只需要读取几KB的XML文件即可，速度非常快。此外， XACML的描述方式也很容易描述特定的业务需求，如时间、地点、角色交叉限制等等，系统可移植性和可扩展性大大增强。

部门XACML授权方法，每个部门拥有的权限均基于XACML的XML，对部门权限而言，仅仅是限制该部门用户所能看到的菜单。具体步骤如下：

1）建立<PolicySet>元素，<PolicySet>中包含了部门<Target>访问过滤素和PolicyCombiningAlgId（规则算法）；

2）建立<Target>元素，在该元素中包含了所有的部门权限：<Subject>（主体）、<Resource>（可访问资源）、<Action>（主体操作）

3）建立<Subject>主体限制，<Subject>采取的匹配条件（MatchId）是“string-equal”（字符串相同）；用户所属部门的ID必须和<Subject>中的AttributeValue保持一致，即限定只有该部门的用户才可以访问一定的Resource（可访问资源）和采取一定的Action（主体操作）

4）建立<Resource>资源限制。部门权限的设置仅仅是该部门用户可以看到权限内允许看到的菜单，即URL地址。因此，对<Resource>采取的匹配条件（MatchId）可以使用“anyURI-regexp-match”（地址栏正则表达式匹配）。对于同一个菜单栏下的增删改查操作只是请求方法method不同，地址完全可以做到正则表达式匹配。一个部门拥有对多少菜单的权限，即建立多少个<Resource>元素，如果没有找到对应的匹配地址，则该部门内所有用户均不能访问；

5）部门内不同的用户拥有的Action不同，因此部门权限并不设置具体的<Action>元素，即对部门权限而言，所有动作均可以。；

6）建立<Policy>策略和确认Rule（规则）；当用户被系统成功认证后，首先读取的是<Target>元素，得到该部门可以访问的<Resource>元素即对应菜单栏。不同用户在每个菜单栏下的可以进行的具体Action操作，则通过用户权限管理的用户XACML文件获得，因此，部门权限中对所有用户的Policy中的Rule均为“Permit”。

7）确认该部门PolicyCombiningAlgId和RuleCombiningAlgId算法。部门权限中对所有用的Policy和Rule均为Permit，所以策略和规则算法选择“deny-overrides”（拒绝覆盖），即全部通过。

用户XACML授权方法，每个用户拥有的权限均基于XACML的XML，对用户权限而言，可以根据读取该用户的XML文件分配对应的权限。具体过程如下：

1）建立<PolicySet>元素，<PolicySet>中包含了用户<Target>访问过滤元素和PolicyCombiningAlgId（规则算法）：deny-overrides（拒绝覆盖）；

2）建立<Target>元素。在该元素中仅包含了<Subject>（主体），只有当session中的用户主体ID和<Subject>中的ID一致时，才可以获取必要的用户权限。<Subject>采取的匹配条件（MatchId）是“string-equal”（用户ID字符串相同）。

3）建立用户策略<Policy>和规则算法RuleCombiningAlgId，用户的策略包含若干个<Rule>（规则），每个<Rule>规定了该用户对每个模块URL的访问权限，每个模块中的CRUD操作权限均通过读取该模块<Rule>实现。所有的<Rule>元素均需要遵守规则算法：deny-overrides（拒绝覆盖）；

4）建立每个模块的<Rule>。在该元素中包含了该模块的<Resources>和<Actions>。<Resources>限制了用户可以访问的URL地址，<Resources>采取的匹配条件（MatchId）是“anyURI-regexp-match”（模块URL地址正则匹配）。在一个模块内的CRUD操作均可以采用类似的地址，仅仅是地址后的匹配参数不同。<Action>限制了在该模块URL中可以实施的动作，即CRUD。<Actions>采取的匹配条件（MatchId）是“string-regexp-match”（动作名称正则匹配），如查询动作是find开头，添加动作是add开头等。

5）制定<Rule>的Effect（效果）。在每个<Rule>中，只要MatchId匹配即可访问，所有<Rule>的Effect都为Permit（允许）。如果用户没有读取到部门权限中允许的URL地址，则不能访问该部门内的URL。通过对<Rule>的读取，用户操作的细粒度大大增加。

6）跨域认证管理模块，各子系统的资源站点访问权限既依赖用户在该子系统的权限，跨域访问时也依赖与SAML站点交互的请求结果。为此，在传递SAML请求时，XML消息可以采用类似Kerberos的方式，对XML消息进行局部加密来提高传输效率。加密传输XML过程如下：

1）各子系统资源站点首先与SAML站点约定不同的固定密钥，采用AES双向加密。此密钥仅仅用于各子系统首次向SAML站点发送通信请求，不包含认证请求或结果。此密钥可以与各子系统约定定期更换。

2）SAML站点中用自身的密钥保存各站点首次通信的固定密钥。用来保证首次通信的安全。

3）各子系统首次向SAML站点发送通信请求，此请求可以是IP地址或者是该子系统的标识，可以用明文发送。

4）SAML站点根据各子系统发来的请求找到对应子系统首次通信的密钥，并产生一个临时密钥(session-key)，用双发约定好的固定密钥将此临时密钥加密，传递给该子系统。

5）各子系统用固定密钥解密，得到临时密钥，产生SAML请求或本系统用户验证结果，用临时密钥将XML消息部分加密，发送给SAML站点。

6）SAML站点接受子系统发来的SAML请求或结果，用临时密钥将XML消息解密获得数据对象及其属性，并产生身份验证声明，发送给请求子系统。

7）请求子系统根据SAML决策结果决定是否访问XACML站点和资源站点。

整个流程必须设定时间戳，当各子系统资源站点与SAML站点接受XML消息超时，则本次通信失败，临时密钥作废。这样，即使XML信息被中途截获，由于每次临时密钥都不相同，也难以在短时间内破译。同时，SAML站点也必须设定时间戳，只允许用户在一定的时间范围内进行跨域访问，如果过期，则需要重新获得该子系统的认证。