WebLogic Server的Identity Assertion时间:2011-02-06 00:07来源:dev2dev 作者:Sudhir Upadhyay 点击:182次本文详细介绍了BEA WebLogic Server 如何提供一种机制来通过Identity Assertion执行周边身份验证。当前端访问管理器执行身份验证,而多个后端服务器相信来自前端的请求是经过认证的,并且不需要额外身份验证时,这种 方法就非常有用。 应用服务器根据Web应用程序部署描述文件中定义的安 全约束来授权用户。然而,在已配置安全约束用于提供身份验证之前,Web容器需要确定用户经过了身份验证才能开始工作。也就是说,前端访问管理器需要提供 一些信息给后端Web容器,以保证Web容器不会试图重新认证经过身份验证的用户。要实现这一点,前端访问管理器可能需要把用户凭证(用户名/密码)交给 后端服务器。然而,这会由于下面两个原因受挫: 在典型部署中,前端身份管理软件和后端应用服务器之间的连接不通过安全套接字层(SSL),这意味着用户证书将以非加密的纯文本形式传递。 简介 从高级观点出发,Identity Assertion是通过从前端访问管理器向后端应用服务器传递令牌来实现的。从根本上来说,断言是关于主体(比如用户)的一些事实(陈述)的声明。令牌 是从一个系统传到另一系统的一条信息,它可被用于确认某个特定用户的身份。令牌和断言相结合,即构成了Identity Assertion的基础。本质上,Identity Assertion提供程序是一种特殊的身份验证形式,它让用户或系统流程能使用令牌进行身份断言。 Web应用程序安全 在介绍Identity Assertion的实现细节前,让我们简要说明Web应用程序安全模式的原理。servlet规 范提供了通过servlet容器实现Web应用程序安全的指导方针。规范指定的两种安全形式是声明性的和程序性的。当Web应用程序安全为声明性时,安全 性通过部署符(web.xml)在应用程序之外进行配置。身份验证方法,或者说提示用户登录的方法,将通过Web描述符文件web.xml中 的<login-config>元素来指定。如果登录配置出现并且包含一个不为零的值,在访问任何<security- constraint>约束的资源之前,用户必须进行身份验证。 当用户试图访问受保护的Web资源时,Web容器就会激活身份验证机制,该身份验证机制已经为部署描述文件(web.xml)中的资源进行了配置,它位于<login-config>元素内部的<auth-method>标签之间,就像这样: <login-config><auth-method>BASIC</auth-method></login-config> 以下是实现Web应用程序安全的有效身份验证方法: NONE:不提示用户进行身份验证。 Web应用程序部署 图1代表Web应 用程序常用的部署模型。如图所示,当用户试图访问受保护的Web应用程序时,前端访问管理器将对这些用户进行身份验证,并把认证过的用户路由到后端应用服 务器。如果Web应用程序在部署描述文件中定义了安全约束而且角色/属性存储在目录服务器上,servlet容器调用安全API从底层目录获得用户/组的 信息。 让我们大概了解一下有效用户访问受保护资源必须经过的步骤,如部署模型中所示。 用户请求受保护的Web资源。 令牌概述 令牌主要是两方之间传递的秘密代码。本质上,令牌是关于主体的断言或声明,该主体被断言方看作是声明性的(可信任的)。当接收方收到令牌,它会进行一组 操作验证传入的令牌。如果令牌被验证过,就假定请求来自可信任的资源,接收方就不会进行额外的身份验证。在典型的Web环境中,令牌是通过HTTP头部或 cookie传递的。 在当前实现中,WebLogic Server 的默认Identity Assertion 提供程序支持下列令牌:X.509、CSI.PrincipalName、CSI.ITTAnonymous 和CSI.X509CertChain CSI.DistinguishedName。“支持”令牌类型本质上意味着Identity Assertion 提供程序的运行时类(也就是IdentityAsserter SSPI实现)能用assertIdentity方法来验证令牌类型。 由于上述令牌可能无法满足所有应用程序的需求,您可以为自己的环境轻松地建立新的自定义令牌。建立自定义令牌需要编写自定义Identity Assertion 提供程序,该程序能实现IdentityAsserter Security Service Provider Interface (SSPI)。WebLogic Server 的SSPI 提供了开发自定义安全提供程序的途径。自定义令牌类型可以像一段字符串那样简单。例如,在Custom Identity Assertion Provider Implementation中定义下列代码片段,也就定义了一种新的令牌类型。 public final static String MY_TOKEN_TYPE = "MyCustomIAToken"; 定义了新的令牌类型后,可以按BEA产品文档中描述的WebLogic Console 一样,对其进行配置。一旦配置完成并进行了激活,这些令牌就可被WebLogic Security 架构用于断言传入请求的身份。 序列图 图2给出了执行Identity Assertion 期间的步骤顺序: Web应用程序部署过程中,Web容器首先确定Web应用程序的身份验证方法被配置为CLIENT-CERT。 有一点很重要,Identity Assertion不受到JAAS 的保护,也就是说JAAS对实现Identity Assertion不提供任何特定的指导。Assertion和JAAS唯一的关联是Identity Assertion 的实现返回一个javax.security.auth.callback.CallbackHandler(http://java./j2se/1.4.2/docs/api/javax/security/ auth/callback/CallbackHandler.html)。 您可能会想起,当 JAAS LoginModule 需要与用户通信时(例如,要求用户输入用户名和密码),它是通过调用CallBackHandler 实现的。然后CallBackHandler()方法生成适当的 CallBack 来获得请求的信息。在Identity Assertion的情况下,自定义安全提供程序验证请求中传递的令牌是有效的,随后生成唯一的NameCallBack。 多重身份验证机制 在本文前面,我们回顾了Web应用程序安全模型。在登录配置中关于指定身份验证方法的问题之 一是,在某个指定时间,一个Web应用程序只能配置一个身份验证方法。然而在某些情况下,需要从多个源为用户提供服务,也就是说,来自包含已定义令牌的可 信任来源(前端访问管理器)的用户和那些不是来自可信任来源的用户。可能包括来自内部网络的用户,他们可以直接访问应用服务器。换句话说,依赖于请求的来 源,servlet 安全实现可能需要生成两种不同的CallBackHandlers。然而,servlet 规范中没有规定允许多重身份验证方法。这需要调用特定于Web容器提供程序的编程式解决方案。正如我前面指出的,WebLogic 为Web应用程序内部的程序式身份验证提供weblogic.servlet.security.ServletAuthentication。 ServletAuthentication 方法为身份验证提供了两种重要的方法: weak():从请求中获取用户名和密码后,为AUTHENTICATED或FAILED_AUTHENTICATION返回一个int值,对该用户进行认证,并将其设置到会话中。 替代解决方案 Identity Assertion不是这个问题唯一可行的解决方案。其他解决方案包括在两方之间传递共享秘钥(或令牌)。在这种情况下,发送方和接收方要事先都同意共享 的秘钥。如果带有正确共享秘钥值的请求到达时,接收方就能相信请求是来自可信任来源并允许访问底层资源。 其他解决方案诸如基于IP的信任也可以在此使用。在这种情况下,在请求被授权进行访问之前,应用程序会检查请求是否来自预配置的、可信任的IP地址。通常是DMZ中Web服务器的IP。 结束语 本文详细介绍了BEA WebLogic Server 如何提供一种机制来通过Identity Assertion执行周边身份验证。当前端访问管理器执行身份验证,而多个后端服务器相信来自前端的请求是经过认证的,并且不需要额外身份验证时,这种 方法就非常有用。 |
|