| 使用AquaLogic Enterprise Security实现集中式安全策略：第1部分 |
 |
| 作者是 WilliamDettelback-080220 | |
| 2008-02-21 06:01:15 | |
摘要AquaLogic Enterprise Security (ALES)为应用程序和服务提供了一个集中式的安全策略工具。ALES与WebLogic Server和基于WebLogic Server的产品构建于相同的核心安全框架之上。这样便可以使用ALES替代这些工具来执行授权决策，并可以将此类安全策略集中到一个存储库中。这种方法的好处是更易于策略维护并且降低了管理的复杂性，因为许多授权决策都需要在多个产品中执行。 本文将讨论如何在WebLogic Portal和AquaLogic Data Services Platform（ALDSP）中结合使用ALES，并且将探究为何ALES所带来的安全策略机制对门户或数据的创建方式几乎没有影响。 理解ALESAquaLogic Enterprise Security基于一个固有的分布式架构。它在Administration Server中提供了一个集中式的策略管理点（Policy Administration Point，PAP），并以安全服务模块（Security Service Modules，SSM）的形式提供了一些分布式的策略决策点（Security Service Modules，SSM）。SSM拥有各种形式，其中有一种SSM用于插入基于WebLogic Server的应用程序。比如说，如果在WebLogic Portal中插入了一个SSM，那么门户应用程序的授权就可以通过ALES来处理（而不是默认的安全提供程序）。 ALES提供了一种集中式管理授权策略的机制，可应用于任何数量的域和应用程序，并且可以将这些策略分发给正确的SSM。如果您拥有许多全异的WebLogic Portal域，并且它们都需要一些公共的安全策略，那么这种机制将带来巨大的好处。在ALES的帮助下，您可以在一个地点管理这些策略，将让基础架构为您执行分发任务。如果考虑在众多BEA产品（如WebLogic Server、WebLogic Integration、AquaLogic Data Services Platform和AquaLogic Service Bus）中都插入ALES，那么它带来的好处将会更多。 更确切地说，“插入”的实现需要依靠 WebLogic Server中的核心安全框架。该框架的内部原理是基于可插入的 安全提供程序，以提供身份验证、授权、角色映射、凭证映射和审计功能。ALES SSM代表一个高度专门化的身份验证提供程序和角色映射提供程序。由于构建在WebLogic Server之上的任何BEA产品都使用该安全框架保护自己，因此它们可以自动将授权决策传递给ALES（如果这样配置的话）。 这样，ALES安全策略便会覆盖基于WebLogic Server的各个产品中所定义的安全策略。这意味着安全策略已经完全从应用程序和服务本身具体化出来了，这确实是一件好事。 示例应用程序架构 我们来看一个非常简单的示例架构：WebLogic Portal将调用AquaLogic Data Services Platform上托管的数据服务。 图 1. 结合ALES、WebLogic Portal和AquaLogic Data Services Platform架构 如图1所示，ALES为门户和数据服务提供了一个公共安全策略存储库。我们将让部署在WebLogic Portal和AquaLogic Data Services Platform (ALDSP)域上的SSM采用这个集中管理点的策略。注意，虽然SSM将与Admin Server通信以实现策略分发，但SSM的运行并没有运行时依赖性。如果Admin Server突然不在了，SSM将会继续运转（如果SSM自己也发生故障，则可以从持久性策略存储库恢复数据）。 Avitek Investments 由于ALES需要某种安全机制，我们可以考虑投资银行的帐户和基金管理中存在的一个简单问题。Avitek Investments正在努力创建一个门户基础架构，以满足各种类型用户的需求。比如说，客户应该能够登录到门户查询账户余额，基金管理人应该能够登录门户监控基金的业绩，金融理财人员应该能够登录门户帮助管理客户的投资组合。显然，我们需要在这些角色之间划分责任，以确保客户不必访问基金管理人的功能，等等。 图2显示了这样的一个管理界面。 图 2. 金融理财人员的Avitek Investments门户视图 Avitek Investments门户的用户应遵循以下规则：
显然，其中一些策略需要在WebLogic Portal层执行，而另一些需要在ALDSP层执行。注意，角色指派使用了一个技巧，即可以根据客户的帐户总额确定其是否为“高资产净值人士”。 在本文中，我们不讨论如何构建Avitek Investments；我们假定该门户已经构建好，并且需要在门户中应用这些新策略。这种情况在现实世界中很常见，门户经过需要修改策略以满足新客户的需求。首先，我将介绍如何配置WebLogic Portal和ALDSP以处理此场景。 配置WLP SSM安装WebLogic Portal SSM意味着配置适当的授权和角色映射安全 提供程序，以覆盖默认的WebLogic Portal 安全提供程序。有关配置的具体步骤，请参阅 电子文档。本文列出了基本步骤： 第一步，配置WebLogic Portal域，使用ALES SSM替代域中预先安装好的安全提供程序。首先，安装ALES SSM。我们将提供可用于Web服务器、WebLogic Server（9.x和8.1）和POJO应用程序的SSM，以及一个可在SOAP上通信的独立SSM。 要使用SSM，我们必须根据需要创建一个合适类型的实例。就本文目的而言，我们将创建一个WebLogic 9.x SSM（在Windows中，开始->程序->BEA AquaLogic Enterprise Security->Security Service Module->WebLogic 9.x Security Service Module->Create New Instance），结果将创建一组用于SSM的文件（通常位于\instance目录）。然后，我们需要修改Portal域的startWebLogic.cmd，使它引用SSM目录的安全提供程序（方法是修改CLASSPATH）以替代原来的域目录。 图3显示了ALES Administration Console中Portal域（wlprealm）的SSM配置。 图 3. ALES Administration Console中wlprealm的安全配置 在ALES中，我们配置了一个 ASIAuthorization安全提供程序和一个ASIRoleMapping安全提供程序（它们是ALES产品中自带的特定于ALES的安全提供程序）。如果我们使用的是WebLogic Server 8.1，那么配置已经完成。但是如果使用的是WebLogic Server 9.2，则需要在WebLogic Server Administration Console中加入相同的信息，如图4所示。 图 4. WebLogic Server Console中的ASIAuthorizationProvider定义 在本例中，我们将把用户身份存储在ALES Administration数据库中。我们将注册一个Identity Directory（称作aldsp）用于保存WebLogic Portal域和ALDSP域的用户信息。为此，我们需要确保对身份验证提供者进行了配置，让它使用ALES Administration数据库作为用户身份的数据源。 图 5. ALES Administration Console中的ALDSP Identity Directory（显示了用户和属性）。 还有一点值得注意，我们在 Identity Directory 上启用了对 Identity Attributes 的支持。通过Authorization Provider MetaDirectory选项卡可以完成这一操作。基本上，我所要做的就是确保MetaDirectory信息与Administration Database连接信息匹配。这样，我们就可以确定SSM在策略计算时知道如何检索身份Attributes。我们将使用Identity Attributes保存金融理财人员的状态（请参见上图的策略5）或客户总财产（请参见上图的策略2）之类的信息。 在本例中，我们可以使用硬编码的方式直接写入属性值，不过在现实环境中则需要建立一个 属性检索程序，以在运行时从企业数据源获得属性值。注意，策略只要求属性值存储在Identity Attribute中，而不管该值是从哪里获得的；这样我们便可以在开发环境中运行策略，而在稍后再加入属性检索程序。 在ALES中建立WLP数据源建立门户的数据源相当简单。ALES附带有一组样板数据源和策略，因此我们可以就地取材。您将发现大多数与授权相关的资源都位于节点PORTAL_EAR/wlp/PORTAL_WAR/com_bea_p13n中。图6显示了门户安全域“wlprealm”的扩展资源树。 图 6. ALES Administration Console中的wlprealm资源树 当然，如果希望在门户中使用ALES保护特定于域的资源，那么可以在该资源树中指定策略。下文在讨论JSP标志库时将给出一个示例。 从portlet调用数据服务由于WebLogic Portal和ALDSP运行于各自的域中，因此还需要将已确认门户访问者的身份传播给数据服务。有多种方法可以实现这一目的。对于基于页面流的portlet来说，最简单的方法就是使用 ALDSP Data Service控件，该控件将自动完成这一任务（前提是配置了两个 受信任的域）。 在WebLogic Portal中使用ALES有两种方法可用于在WebLogic Portal应用程序中使用AquaLogic Enterprise Security策略：
我们将依次介绍这两种方法。 使用AquaLogic Enterprise Security策略替换WebLogic Portal访问者授权机制熟悉WebLogic Portal的人可能会问：ALES SSM的这种配置对WebLogic Portal的 嵌入式Entitlements引擎 有何影响？通过配置SSM，您可以有效地将授权策略引擎替换为ALES策略引擎。这意味着我们将通过ALES策略（而不是WebLogic Portal Administration Console）来建立门户授权规则。虽然这对WebLogic Portal的老用户可能会造成一些不安，但是实际上并没有发生什么大的变化。WebLogic Portal将它的授权决策委托给Authorization Provider实现，我们要做的只是修改它的决策制定者。将ALES作为决策制定者之后，我们便拥有了更广泛的策略，供WebLogic Portal授权决策时应用。 要更好地理解这一点，请考虑角色映射的机制。通过WebLogic Portal Visitor Roles，我们可以动态地关联门户用户的角色。但是，这些WebLogic Portal Visitor Roles在门户之外却不可用。如果使用ALES Role Mapping取代它，我们便可以使用单个策略根据复杂的逻辑和属性关联用户的角色（比如说基金管理人）。然后，角色映射策略可以在WebLogic Portal和ALDSP层之间共享，这样基金管理人在两个运行时中表示的便是同一角色。如果在应用程序中添加了一些层和运行时，我们便会发现集中式管理策略能够带来相当大的好处。 我们来看看上述门户所使用的ALES策略。这是金融理财人员的管理界面，其中显示了MyCustomers页面。下面是四个相关的策略： grant(//priv/view, 每一条策略语句的格式都是“Grant/Deny, privilege(s), resource(s), subject(s),”，接着是一些可选的约束表示式。这四个“grant”策略的意思分别是：
注意，ALES与WebLogic Portal授权有所不同，它提供了一个封闭世界模型。封闭世界模型表示默认情况下拒绝访问资源。另一方面，WebLogic Portal提供了一个开放世界模型，它表示若没有定义授权策略，则默认情况下允许一切访问。ALES是一款安全产品，因此不得不采用这种方法。因为封闭世界模型可以确保定义策略时的疏忽不会导致资源的意外公开。 关于ALES授权，还有最后一点需要注意：我们只在定义访问者授权时才采用这种方法。传统流程仍然在使用ebLogic Portal Administration Console执行委托管理。 AquaLogic Enterprise Security JSP标记库在上面的策略4中，我们看到英国的基金管理人在下午4点之后将不能使用基金操作功能。在这种门户的开发中，实际上这些基金操作控制是嵌入在Fund Management portlet中的。如果它们是一个独立的portlet，那么我们可以使用WebLogic Portal授权来限制访问，因此portlet内部还需要一种策略执行方式。由于Fund Operations控制将公开为HTML标记，因此可以使用以下portlet代码： <ales:isAccessAllowed resource="/fundoperations" action="view"> 授权调用内部的策略： deny ( 该策略表示“16：00点（4:00 p.m）以后，英国的任何基金管理人将不允许查看基金操作资源。”您会注意到，由于该调用是从门户WAR本身发起的，因此可以认为资源位于//app/policy/wlprealm/CRMDemoEAR/url/CRMDemoWAR。 在非JSP Portlet中使用AquaLogic Enterprise Security在非JSP portlet内部，我们可以使用ALES Java API编写代码来访问SSM进行授权决策。该API对于简单的portlet来说稍微有点繁杂，它的设计目的是由WebLogic Server之外的各种运行时容器中的已有授权框架使用。常见的方法是建立一些工具类，在该API之上提供一个抽象层（如果ALES调用将发生在多个portlet中）。未来的ALES发行版将提供一个Apache Beehive Control，该控件可以相当大地减少在基于Java或页面流的portlet中编写的代码量。 结束语本教程已经介绍了AquaLogic Enterprise Security可以在应用程序的各个层中建立公共安全策略，本文使用的是WebLogic Portal和AquaLogic Data Services Platform。在WebLogic Portal中配置域时，ALES SSM可以成为授权决策制定者和在portlet代码中可通用的策略决策点。ALES扩展了的WebLogic Portal 执行授权的方式，并且可以在构建好门户应用程序之后添加到门户中。在ALES JSP标记库的帮助下，从portlet中编写代码调用SSM将得到极大的简化，并且提供了一种实现内部portlet授权的方式。 第2部分将介绍如何在应用程序的AquaLogic Data Services Platform层中应用AquaLogic Enterprise安全策略，以完全实现本文所描述安全策略。 参考资料
|
|
| 最近更新 ( 2008-02-21 06:01:15 ) |
