主题
企业架构
使用 AquaLogic Enterprise Security 实现集中式安全策略：第1部分
页面： 1, 2, 3
配置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策略：
- 使用授权
- 使用Java API或JSP标志库编写代码。
我们将依次介绍这两种方法。
使用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,
[//app/policy/wlprealm/CRMDemoEAR/wlp/CRMDemoWAR/com_bea_p13n/Desktop/invest/desktop,
//app/policy/wlprealm/CRMDemoEAR/wlp/CRMDemoWAR/com_bea_p13n/Book/Investments_Book,
//app/policy/wlprealm/CRMDemoEAR/wlp/CRMDemoWAR/com_bea_p13n/Portlet/Login_Portlet,
//app/policy/wlprealm/CRMDemoEAR/wlp/CRMDemoWAR/com_bea_p13n/Page/Welcome_Page],
//role/Everyone);
grant(//priv/view,
//app/policy/wlprealm/CRMDemoEAR/wlp/CRMDemoWAR/com_bea_p13n/Portlet/AccountOperations_Portlet,
//role/FinancialAdvisor);
grant(//priv/view,
//app/policy/wlprealm/CRMDemoEAR/wlp/CRMDemoWAR/com_bea_p13n/Page/MyCustomers_Page,
//role/FinancialAdvisor);
grant(//priv/view,
//app/policy/wlprealm/CRMDemoEAR/wlp/CRMDemoWAR/com_bea_p13n/Page/Research_Page,
[//role/FinancialAdvisor,//role/HighNetWorthCustomer]);
每一条策略语句的格式都是“Grant/Deny, privilege(s), resource(s), subject(s),”，接着是一些可选的约束表示式。这四个“grant”策略的意思分别是：
- 准许任何人查看invest desktop、Investments_book、Login_Portlet和Welcome_Page资源。
- 准许金融理财人员查看AccountOperations_Portlet资源。
- 准许金融理财人员查看查看MyCustomers_Page资源。
- 准许金融理财人员查看查看Research_Page资源。
注意，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">
<ales:then>
<!-- Fund Operations Controls Here -->
</ales:then>
<ales:else>
<hr><p/>
We're sorry, fund operations are not available after 4pm.<p/>
<hr>
</ales:else>
授权调用内部的策略：
deny (
//priv/view,
//app/policy/wlprealm/CRMDemoEAR/url/CRMDemoWAR/fundoperations,
//role/UKFundManager ) if hour > 16
该策略表示“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安全策略，以完全实现本文所描述安全策略。
William Dettelback目前工作于AquaLogic Enterprise Security小组。他致力于帮助客户实现SOA Security，特别是Authorization和Entitlement解决方案。
Printer View