作者：Som Sengupta, Venkatakrishnan Padmanabhan
在开发周期中，往往要到后期才会考虑安全性的问题。结果，许多安全实现具有以下问题：
- 应用程序的开发人员过多地参与安全性方面的决策。但是实际上，安全性是一个专门的领域，最好由安全管理员进行管理。
- 把安全逻辑开发和部署为应用逻辑的一部分。因此，当管理员需要更新安全逻辑时，同时必须更新并重新部署应用逻辑，这导致了应用程序开发周期不连续。
- 安全管理是分散式的。
- 跨应用程序启用单点登录需要投入可观的工作量。
本文提出了一个用于跨域启用集中式身份验证的面向服务架构（SOA）。这种方法具有以下优势：
- 使安全逻辑与应用逻辑相互分离，使安全管理员能够在修改安全逻辑的同时，无需更新应用逻辑。
- 提供集中式的安全管理。
- 跨应用程序启用单点登录。
- 提供一个可以在企业范围内为其他业务应用程序所共享的安全基础架构。
这种方法基于WebLogic Server 8.1 SP3。
基于SOA的方法概览
基于面向服务的架构（service-oriented architecture ，SOA）的方法使用网关作为验证用户身份的中心点。网关使用开放式标准，并通过单点登录的功能，支持对各种应用程序的无缝访问。通过授权已验证的用户访问所有参与的应用程序，而不需要用户重新输入用户凭证，单点登录简化了企业内的身份验证流程。
这种方法具有以下优点：
- 具体化身份验证服务
对于用于验证用户身份的身份验证服务，其维护是独立于应用程序代码的，而且身份验证信息被保存在LDAP目录中。
要实现域间的身份验证，您可以使用WebLogic LDAP身份验证提供程序，并使用您首选的LDAP配置它。使用外部LDAP支持安全管理员跨多个域进行集中式的用户管理。
- 把身份验证GUI转移到表示层
所提出的方法确保：
o 与登录有关的GUI独立于身份验证服务域。
o 用于呈现登录GUI的资源在表示层中提供。
o 对GUI和身份验证服务进行的修改相互独立。
- 支持基于安全性声明标记语言（Security Assertion Markup Language，SAML）的安全身份传播
跨应用程序的单点登录是使用SAML——一个用于交换安全性信息的、基于XML的框架——来实现的。
- 支持多个安全性令牌的同时无需修改应用程序
这个方法和基于SAML的安全性令牌不相关。通过配置不同的Credential Mapper和Identity Asserter对（稍后会说明），可以支持其他的安全性令牌类型，而无需修改应用程序。
该方法最小化了部署身份验证服务所需的定制代码量。任何熟悉以下任务的用户都可以轻松配置该方法：创建WebLogic域，配置Web应用程序和利用WebLogic 安全基础[1]。
身份验证网关架构
身份验证网关架构基于周边身份验证（perimeter authentication）的概念，这个概念支持单点登录。周边身份验证是这样一个机制：它基于外部身份验证实体生成的安全性令牌建立用户身份。
下图阐明了身份验证网关架构，包括：
- 使用LDAP的集中式用户管理。
- 使用下列三种组件的基于SAML的身份声明：Credential Mapper、HttpProxyServlet和Identity Asserter (“身份验证网关架构的组件”一节将详细讲述这些组件)。
- 具体化以门户Web应用程序为宿主的登录页面。
图1. 身份验证网关架构
如上图所示，安全域（security domain）功能是作为外部的身份验证实体。安全域担任“身份验证服务”的宿主，提供安全网关给应用程序域。用户在被允许访问应用程序域中的应用程序之前，必须通过安全域的身份验证。
下面给出了流程流的描述。（稍后“身份验证网关架构的组件”一节将详细描述图中的每个组件。）
- 用户登录到系统中。安全域代理Web应用程序接收基于FORM的请求。
- 代理Web应用程序把用户证书传递给身份验证服务提供程序。
- 接下来，身份验证服务提供程序使用LDAP用户管理系统验证用户凭证。
- 验证完毕之后，身份验证服务提供程序生成一个已验证的ID，并将其传递给代理Web应用程序。
- servlet过滤器把已验证的ID传递给Credential Mapper。
- 接下来，Credential Mapper生成一个代表已验证用户的安全性令牌，然后把它传回给代理Web应用程序。
- servlet过滤器把安全性令牌附加到HTTP请求，然后把请求发送到应用程序域。
- 应用程序域中的WebLogic Security Framework把安全性令牌分派给匹配的Identity Asserter。用于验证安全性令牌并将其转换为用户身份的机制称为身份声明（identity assertion），由Identity Asserter（WebLogic Security Framework的一个组件）进行处理。要启用身份声明，您必须更新Web应用程序的部署描述符，把
auth-method
设置为
CLIENT-CERT
- Identity Asserter验证令牌，如果验证成功，就把它映射到WebLogic用户，并把它转发给身份验证服务提供程序。
- 接下来，身份验证服务提供程序使用LDAP用户管理系统验证用户的存在。
- 验证完毕之后，身份验证服务提供程序通知Identity Asserter用户已经通过身份验证。
- Identity Asserter把已验证的身份传回给Web应用程序。因此，无需重新进行身份验证就可以建立一个HTTP会话。
正如流程中描述的那样，用户身份验证与应用程序没有耦合，而且被具体化。
顺序图: 之前、之中和之后的身份验证
下面三个图显示了三个UML顺序图，分别说明了身份验证之前、之中和之后的事件顺序。
图2. 身份验证之前的UML顺序图
图3. 身份验证之中的UML顺序图
图4. 身份验证之后的UML顺序图
安全性考虑
安全域和应用程序域之间的通信渠道必须是安全的。这可以通过禁用纯文本端口，而只允许SSL请求到达应用程序域来实现。另外，必须使用防火墙或连接过滤器对应用程序域进行配置，只允许属于安全域中的机器发送的请求通过。
身份验证网关架构的组件
下面对每个组件进行描述，说明如何配置或定制它们以满足企业需求。描述组件的顺序是按照用户请求流的顺序，从安全域到应用程序域。这种组织方式有助于理解组件之间的各种相关性。
这里描述的大部分组件都可以用于WebLogic Server，而且您可以使用WebLogic Server工具很容易地配置它们。
安全域组件
- 代理Web应用程序
WebLogic Server使您能够创建代理Web应用程序，允许通向应用程序的请求流过防火墙。代理Web应用程序对于部署在应用程序域中的每个业务应用程序都是必需的，而且必须使用和相应应用程序相同的名称来部署它们。
代理Web应用程序由一个部署描述文件web.xml和一个servlet过滤器组成。代理Web应用程序的部署描述文件中的配置决定了以下内容：
o 身份验证的方法。
o 初始的权限检查。
o 周边令牌的类型（通过配置一个相应的servlet过滤器，稍后将会说明）。
o 用于重定向HTTP请求的应用程序URL（通过配置HttpProxyServlet，稍后将会说明）。
您必须在安全域内创建和部署这个代理Web应用程序。
- 代理Servlet (HttpProxyServlet)
通过使用代理servlet HttpProxyServlet[3]，每个通向代理Web应用程序的请求被重定向到应用程序域。基于表单的身份验证模型允许通过从应用程序域获得与登录相关的资源，从而呈现一个定制的、内容丰富的用户界面。
身份验证进行完毕之后，用户被重定向到位于应用程序域内的欢迎页面index.jsp。index.jsp的功能就像一个路由器，基于指派给用户的角色来转发请求。另外，通过使用门户权利，可以呈现个性化的视图。
HttpProxyServlet是WebLogic Server的一部分，必须在代理Web应用程序部署描述文件中对其进行配置。代理servlet过滤器参数定义了应用程序域的URL。
- Servlet过滤器
servlet过滤器修改HTTP请求的头，以便添加Credential Mapper（接下来将会说明）生成的安全性令牌。
这是您必须在这个方法中实现的惟一组件。
通过使用HttpServletRequestWrapper，安全性令牌被附加给HTTP请求头。所附代码提供了一个示例servlet过滤器。
- Credential Mapper
Credential Mapper把已验证的用户映射为安全性令牌。通过修改Credential Mapper，可以生成不同的安全性令牌，并把它们传递给应用程序域中相应的Identity Asserter。
servlet过滤器可以把生成令牌的任务委托给配置好的Credential Mapper。在这种情况下， servlet只负责调用Credential Mapper和使用输出修改请求头。
WebLogic Enterprise Security (WLES)提供基于SAML的Credential Mapper[5]。
用户可以实现定制的Credential Mapper，以支持各种安全性令牌。
- 身份验证服务提供程序（外部的LDAP服务器）
身份验证服务提供程序使用代理Web应用程序传递的参数对用户进行身份验证。安全域和应用程序域配置身份验证服务提供程序，以指向共享的外部LDAP服务器。外部LDAP的使用简化了用户管理，并允许安全管理员进行集中式的管理。
应用程序域组件
- 登录应用程序（WebLogic门户Web应用程序）
登录应用程序提供表示层中的登录资源。这解除了与登录有关的GUI和身份验证服务之间的耦合。
可以使用WebLogic Portal开发登录应用程序，以便支持各种客户端类型和丰富的用户界面。
在所提出的方法中，WebLogic Portal Web应用程序提供登录资源，使用以下形式的上下文根（context root）把它部署到应用程序域中，以简化web.xml中的HttpProxyServlet配置：
<Proxy webapp Name> /<login app>
必须针对包含登录资源的WebLogic Portal Web应用程序配置匿名访问，以允许成功登录。确保代理Web应用程序的cookie和应用程序不同，具体方法是配置weblogic.xml文件中的session-param参数，如下：
<session-param>
<param-name>CookieName</param-name>
<param-value>SECURITY-COOKIE</param-value>
</session-param>
- 身份声明
Identity Asserter把安全性令牌映射为已验证的用户。
WebLogic Server允许您配置多个安全提供程序。一个安全提供程序通常实现一个Identity Asserter和Credential Mappper。例如，为了支持各种安全性令牌，比如Kerberos 票证，您可以实现一个定制的Identity Asserter，或者从第三方厂商获得一个Identity Asserter。可以在不修改应用程序代码的情况下对它进行配置。
WLES提供一种SAML实现，该实现中包括识别WLES Credential Mapper生成的SAML声明的Identity Asserter。
小结: 基于SOA的方法的优点
保护一个基于SOA的生产环境是一个难题。相互连接的系统之间的松散耦合（SOA的一个主要特色）要求使用非传统的安全性基础架构。
本文给出了一个用例，其中身份验证机制被公开为一个服务，而SOA之下可用的所有其他服务都重用该服务。这种方法的重要优点包括：
- 当部署新的业务或基础架构级别的服务时，您不需要实现另外的身份验证机制。您只需要重新配置Identity Asserter。
- 受过训练的安全管理员可以集中管理企业的身份验证机制。
- 业务服务可以很容易地从较弱的安全配置迁移到更加全面的安全配置。例如，一个使用基于密码的身份验证的J2EE应用程序可以与SSL保护一起使用，只要修改应用程序级别的部署描述文件，然后重新部署应用程序即可。
- 同一台J2EE服务器可以同时作为受到SSL保护的和非SSL的J2EE应用程序的宿主，而无需针对特殊的SSL端口和证书重新配置。
- 您可以以一种集中和安全的方式审计通向部署在SOA伞下的任何服务的所有流量，这提供了一种有用的方式来监控各种业务服务的使用模式。
- 集中式的身份验证方法限制了支持业务服务所需昂贵硬件的数量；它只需要计算密集型的身份验证服务。
- 身份验证服务的用户界面与实际的身份验证机制之间是松散耦合的。这使您能够使用相同的身份验证服务支持各种设备的各种用户界面。
- 更新身份验证界面不需要安全管理员或者身份验证服务参与。
|
