借助SAML 实现 WebLogic Server 9.2 和 IIS 的单点登录

　　为几个站点实现单点登录（single sign on，SSO）是一个复杂多变、涉及多个解决方案的问题。近五年内出现的Security Assertion Markup Language (SAML) 是其中一种较为标准的方式，而 BEA WebLogic Server 9 提供了对SAML 的广泛支持。但遗憾的是，简单的 SAML 配置例子，尤其是跨平台的场景很难实现。

　　本教程描述了一个Microsoft Internet Information Services Server (IIS) 和BEA WebLogic Server 9 间的简单SAML SSO 场景，并附有一个功能齐全的示例，该示例包含了 ASP.NET 代码以及用来配置 WebLogic Server的脚本。本教程假设您具有 SAML 的基础知识。

　　简介

　　最近，我的一个客户提出了这样的要求，他想要将WebLogic Portal 9 添加到流行的ASP.NET Web 基础架构。新老站点必须能够无缝的共存，而且还必须能单点登录。

　　在过去，这可能需要很多工作，比如编写笨重的安全提供程序，才能实现。所幸，WebLogic Server 9 提供了开箱即用的 SAML 支持。

　　SAML 是一种基于XML 的标准，用于用户认证、授权和属性信息的通信。Harold Lockhart的文章 揭开SAML的神秘面纱（Dev2Dev中文版，2005年12月）和 Beth Linker的文章 SAML简介：安全地共享数字身份信息（Dev2Dev中文版，2006年9月） 都对这种技术做了很好的介绍。

　　与WebLogic Server 9 不同，IIS 并不提供开箱即用的 SAML 支持。对于简单的场景来说，手工给出SAML断言十分简单，在本例中我就采用了这种做法。对于更复杂的场景，可尝试使用Web Services Enhancements (WSE)。

　　解决方案

　　客户的IIS认证解决方案功能健全且十分稳定，因此我决定重用它。.NET 端负责认证和生成 SAML 断言以供 WebLogic Server 使用。网络设置力图使服务器间能尽可能地直接通信，只留下POST SAML配置文件作为惟一的选项。

　　

　　

　　图1.受 SAML保护的资源访问顺序

　　图1 描述了POST SAML 配置文件是如何应用到我的场景中的。在 SAML 术语中， WebLogic Server 是一种资源提供程序，IIS 是身份断言提供程序。

　　浏览器试图访问的这个WebLogic Server 应用程序是受保护的。只有用户 weblogic 允许查看资源 http://localhost:7001/protected/secret.jsp。访问后，我们希望IIS 能公开页面http://localhost/SAMLdotNet/Login.aspx，以便验证用户身份和创建SAML 断言。

　　带着上述想法，让我们来看看图1中描述的典型的安全流：

　　浏览器发送 GET /protected/secret.jsp 到 WebLogic Server。

　　WebLogic Server 用"HTTP/1.1 302 Moved Temporarily," 进行响应并将浏览器重定向到 http://localhost/SAMLdotNet/Login.aspx?RPID=rp_00001&APID=ap_00001&TARGET=http://localhost:7001/protected/secret.jsp.

　　资源提供程序 ID (RPID) 用来标识这个受保护的资源提供程序。断言提供程序可用它来辨别为之生成断言的多个资源提供程序。这个 ID 让 IIS 能将控制权返回给要求断言的这个 WebLogic Server 而不是另一个系统。

　　与RPID类似，断言方 ID (APID) 用来惟一标识断言方。WebLogic Server需要知道哪个断言方创建了特定的断言以便对它进行正确的验证。

　　浏览器发送 GET /SAMLdotNet/Login.aspx?RPID=rp_00001&APID=ap_00001&TARGET=http://localhost:7001/protected/secret.jsp to IIS。

　　Login.aspx 验证用户的身份并生成一个 SAML 断言。

　　包含新生成的断言的表单返回给浏览器。

　　从IIS 收到的表单发布到 WebLogic Server 的 http://localhost:7001/samlacs/acs处。服务器被配置成在这个URL执行 SAML 身份断言明。

　　WebLogic Server验证断言，如果验证成功，将请求转发到 /protected/secret.jsp。

　　结果返回给浏览器。

　　本教程的如下部分描述了结果是如何实现的。

　　对 Web 应用程序加以保护

　　使用SAML 断言的第一步是确保Web应用程序受保护。本例包含了示例 Web 应用程序。它没有什么新鲜内容： XML 标记及其与安全性相关的内容都在web.xml 内配置。.weblogic.xml 配置文件定义了角色如何映射到主体。

　　对应用程序进行保护在这里就是指应用标准的Java EE 安全限制。

　　密钥对

　　要建立 WebLogic Server 和 IIS间的信任关系，必须生成不对称的密钥对并将这些密钥加载进 WebLogic Server 和Windows 密钥库。为了方便起见，本教程已经随附了一对密钥： saml_dsa.pfx 包含专用密钥，saml_dsa.cer 包含其对应的证书。

　　为了让 ASP.NET 应用程序可以使用此专用密钥，需要完成如下两个操作：

　　专用密钥必须加载到 Windows 密钥库。

　　为此，执行如下步骤：

　　双击 LocalMachineKeyStore.msc。

　　在左边的树中，展开Certificates\Personal\Certificates。

　　右击 Certificates，然后在All tasks，选择 Import。

　　单击 Next。

　　将文件类型改为 "Personal Information Exchange," ，然后选择 saml_dsa.pfx。

　　单击 Next。

　　不输入密码，只单击 Next。

　　单击 Finish。

　　拥有ASP.NET过程的用户 "ASPNET" 应该被授予访问专用密钥的权限。可使用winhttpcertcfg -g -c LOCAL_MACHINE\My -s "saml_dsa" -a ASPNET 实现此目的。此实用工具可以在 这里下载。

　　客户证书必须要加载到 WebLogic Server。这由 WLST 脚本 setup_script.py 自动实现。请将此脚本的运行推迟到下一节。

　　密钥对用来验证断言的真实性。IIS 将使用密钥对来登录所生成的断言。WebLogic Server 将使用证书来验证 IIS 的签名。

　　配置 WebLogic Server

　　本例中所有配置WebLogic Server以使用 SAML 所需的步骤都可由随附的 WLST 脚本 setup_script.py 自动完成。在进一步处理之前，运行 wlst setup_script.py。这将创建启用了SAML的 WebLogic Server 域。启动这个管理服务器并转到控制台来观察它是如何配置的。无需任何手工配置步骤。

　　为启用 SAML，这个脚本配置了两个主要组件：SAML Identity Asserter 和 SAML Destination Site。

　　接下来，让我们来详细看看这两个组件。

　　SAML Identity Asserter

　　SAML Identity Asserter 可在管理控制台的Security Realms\myrealm\Providers 下找到。它是SAMLIdentityAsserterV2类型的身份认证提供程序。它的所有属性均位于 Management 选项卡中，该选项卡下还有两个子选项卡：Certificates 和Assertion Parties。

　　签名验证证书在 Certificates 选项卡下。

　　Assertion Parties 选项卡用来配置断言方。本例中只配置了一项。此项对应于IIS——此站点的惟一合作方。请注意如下的断言方属性：

　　POST Signing Certificate Alias 属性在 SAML Response 签名验证期间使用。它引用通过Certificates 选项卡加载的证书。如果没有它，就无从知道来自合作方的消息有没有被篡改过。.

　　Source Site Redirect URIs 属性定义一组URL，这些URL在有人试图访问它们的时候触发SAML断言序 列（图1，步骤 2）。

　　Source Site ITS URL 属性定义在合作方一端必须被调用的 URL。到这个 URL 的请求将包含TARGET 参数以及在 Source Site ITS Parameters 属性内定义的其他参数。TARGET 参数指定用户试图访问的URI （在本例中就是/protected/secret.jsp）。

　　Source Site ITS Parameters 属性指定在对Source Site ITS URL进行调用期间传递的额外参数。在本例中指定的是 RPID=rp_00001 和APID=ap_00001。

　　RPID 代表发起断言序列的那一方。IIS 使用这个参数来判断该使用哪个URL进行断言序列（图1）的步骤6中的回调。APID 包含断言方 ID，通过这个ID， WebLogic Server 才能识别IIS。参数必须传递给 WebLogic Server 以使断言成功。

　　Issuer URI 属性是用来验证断言的组件之一。它必须匹配在断言XML中的发布者 URI。

　　总的来说，所有试图访问受保护资源的用户不仅需要具有有效的断言，而且还必须是WebLogic Server已知的。至少应该有一个认证程序必须能够认证此用户。如果启用了 Allow Virtual Users 属性就允许 WebLogic Server对用户“未知”。该特性可与 SAML Authenticator 级联工作，只有这样才能使这种方式奏效。尚无配置参数可用。

　　SAML Destination Site

　　若要确保存在等待SAML响应的 servlet，就必须配置 SAML Destination Site。 这个配置项可在WebLogic Server 控制台中的 Environment/Servers//Federation Services/SAML 1.1 Destination Site下找到。

　　Assertion Consumer URIs属性用来告知 WebLogic Server为 SAML响应应该侦听哪些URI。在本例中，使用的是默认的 /samlacs/acs。浏览器会向此URI发布断言表单（参见图1，步骤 6）。

　　可启用ACS requires SSL 属性来避免 SAML 断言拦截的危险。在本例中，为了简便起见，禁用了此属性。如果想要启用它，需要配置WebLogic Server 在 SSL 端口侦听并确保 IIS 使用HTTPS（而非 HTTP）执行回调。

　　这一点也不困难，是不是？我根本无需修改应用程序来支持SAML。所有需要做的工作都由WebLogic Server 配置更改完成。即使您想要将SAML置于现有的系统之上，您也无需触及已部署的那些应用程序就可以实现此目的。

　　在 .NET中创建断言

　　在本例中，创建了两个 .NET 组件。

　　Login.aspx 接收断言请求并生成具有相应创建的断言的表单。AMLAssertionCreator.cs 封装断言创建逻辑。

　　示例 1 显示了一个由ASP.NET应用程序生成的真正的 SAML响应。它包含一个具有认证语句的断言。此断言表明了它是在2006年11月16日 8:57 AM 由 https://aspsite.com生成的，并在 8:57AM 和 8:58AM之间有效。它确认用户 weblogic 使用密码认证通过了身份认证。

　　

　　

xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"

MajorVersion="1" MinorVersion="1"

ResponseID="b8049e0c9e99f6a270ac05ad70f7384d"

IssueInstant="2006-11-16T18:57:59.59Z"

Recipient="http://localhost:7001/samlacs/acs">　　xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"

　　MajorVersion="1" MinorVersion="1"

　　ResponseID="b8049e0c9e99f6a270ac05ad70f7384d"

　　IssueInstant="2006-11-16T18:57:59.59Z"

　　Recipient="http://localhost:7001/samlacs/acs">

　　

　　

　　

　　

xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"

AssertionID="ccde3775286167a3bd1c9f5dec4f153a"

IssueInstant="2006-11-16T18:57:59.59Z"

Issuer="https://aspsite.com"

MajorVersion="1" MinorVersion="1">　　xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"

　　AssertionID="ccde3775286167a3bd1c9f5dec4f153a"

　　IssueInstant="2006-11-16T18:57:59.59Z"

　　Issuer="https://aspsite.com"

　　MajorVersion="1" MinorVersion="1">

　　

NotBefore="2006-11-16T18:57:59.59Z"

NotOnOrAfter="2006-11-16T18:58:59.59Z"/>　　NotBefore="2006-11-16T18:57:59.59Z"

　　NotOnOrAfter="2006-11-16T18:58:59.59Z"/>

　　

AuthenticationInstant="2006-11-16T18:57:59.59Z"

AuthenticationMethod=

"urn:oasis:names:tc:SAML:1.0:am:password">　　AuthenticationInstant="2006-11-16T18:57:59.59Z"

　　AuthenticationMethod=

　　"urn:oasis:names:tc:SAML:1.0:am:password">

　　

　　weblogic

　　

　　

　　urn:oasis:names:tc:SAML:1.0:cm:bearer

　　

　　

　　

　　

　　

　　

　　

　　示例 1. SAML响应

　　虽然我无意提供有关 SAML 消息结构的详细解释，但我还是想强调如下两点：

　　SAML 断言发布者与在 WebLogic Server 断言方配置中指定的发布者 URI 相匹配并不是偶然的。如果二者不匹配，断言验证就会出错。

　　NotBefore 和 NotOnOrAfter 断言条件（尤其是后者）非常重要。它们有效地指定了有效日期进而限制了对截获断言的使用。如果IIS 和 WebLogic Server 在不同的机器上运行，就必须确保二者的时间是同步的且时区的设置是准确的。.

　　断言创建后，必须将其放入表单然后返回给客户机。以下三个字段将会被填充，如示例2所示：

　　该表单中的TARGET 字段包含受保护资源的 URI 。它作为来自WebLogic Server 的重定向的一部分被 IIS接收。

　　SAMLResponse字段包含一个 按base64编码的 SAML 响应。

　　APID 字段包含与IIS相关的断言方标识符。

　　表单会自动提交给 WebLogic Server URL （本例中，存储于 redirectURL），在WebLogic Federation Service 选项卡内定义。在本例中，是 http://localhost:7001/samlacs/acs。

　　

　　<%

saml.SAMLAssertionCreator assertionCreator = new saml.SAMLAssertionCreator();

/*

* For purposes of this example, no authentication is performed at any level.

* In a real scenario this HAS TO BE FIXED.

*

*/

String assertionResponse =

assertionCreator.createAssertion("weblogic",

"https://oldsite.com",

redirectURL,

"saml_dsa");

String base64 =Convert.ToBase64String(

Encoding.UTF8.GetBytes(assertionResponse))

%>　　saml.SAMLAssertionCreator assertionCreator = new saml.SAMLAssertionCreator();

　　/*

　　* For purposes of this example, no authentication is performed at any level.

　　* In a real scenario this HAS TO BE FIXED.

　　*

　　*/

　　String assertionResponse =

　　assertionCreator.createAssertion("weblogic",

　　"https://oldsite.com",

　　redirectURL,

　　"saml_dsa");

　　String base64 =Convert.ToBase64String(

　　Encoding.UTF8.GetBytes(assertionResponse))

　　%>

　　

action="<　　action="<%=redirectURL%>"

　　method="post">

　　

value="<　　value="<%=target%>" />

　　

value="<　　value="<%=base64%>"/>

　　

value="<　　value="<%=apid%>" />

　　>

　　

　　

　　

　　示例 2.生成断言表单的 ASP.NET代码

　　配置 IIS

　　要配置IIS Server，可使用Windows 控制面板中的管理工具。假设 IIS 已经成功安装且 专有密钥也已导入完毕可以使用，您需要执行如下这些步骤：

　　确保 IIS 在端口 80 运行，如图2 所示：

　　

　　

　　图2. IIS Web站点配置

　　配置SAMLdotNet Virtual Directory 使其指向 SAMLdotNet 应用程序的位置，如图3所示。

　　

　　

　　

　　图3. Virtual Directory配置步骤（单击图像可放大）

　　尝试

　　假设 WebLogic Server 在端口 7001 本地运行，转到 http://localhost:7001/protected/secret.jsp。您将会看到主体名称，该名称应该是weblogic。出于本例的目的，凭证并不会得到验证，ASP 只为用户创建一个断言、登录它并将其传递回来。很显然，这种做法并不能满足安全环境的要求。

　　下载

　　本教程的示例代码和配置

　　结束语

　　WebLogic Server 9 让单点登录的实现变得异常简单。一旦您习惯了配置SAML 安全提供程序，在SAML 可用时，创建一种定制的安全解决方案可能永远不会出现在您的脑海。实际上，SAML可以一种可扩展的标准方式实现单点登录，非常适合于跨平台的解决方案。

　　参考资料

　　使用WebLogic Server9.2中的SAML配置单点登录作者：Vikrant Sawant (Dev2Dev中文版，2007年)

　　SAML简介：安全地共享数字身份信息作者：Beth Linker (Dev2Dev,中文版，2006年)

　　揭开SAML的神秘面纱作者：Harold Lockhart (Dev2Dev中文版，2005年)

　　Configuring Single Sign-On with Web Browsers and HTTP Clients——产品文档

　　作者简介

　　Alex Rykov先后在几家软件和顾问工具担任过软件架构师和工程师，具有十年以上的复杂的分布式系统的设计、构建和部署经验。