sso 服务端配置

编者注：本教程于2017年3月20日更新。所做的更新是为了更正2b步骤4中的代码。 将安全配置应用于IdentityServer配置文件。

您想要在混合云环境中将云服务公开为JavaEnterprise Edition（Java EE）应用程序。 但是，如何通过使用专用网络中的现有安全基础结构来确保这些应用程序的安全性？

本系列的第1部分着重于身份提供商（IdP）和服务提供商（SP）之间的标准身份验证机制。 它基于使用安全性声明标记语言（SAML）2.0对用户身份信息的声明 。 它还说明了Web服务调用之间的身份传播。 在继续本部分之前，您必须熟悉SAML概念和Eclipse上的Java EE开发。

使用SAML单一登录

安全声明标记语言（SAML）是必须根据OASIS标准规范（也称为SAML令牌）编写的XML文档。 根据标准的Java身份验证和授权服务（JAAS）规范，SAML令牌包含应用程序用来对用户进行身份验证和执行基于角色的授权的信息。 通过使用SAML令牌，应用程序不必提示用户提供其凭据。 在应用程序体系结构中， 身份提供者（IdP）充当生成SAML令牌的角色。

以下代码段是SAML令牌的示例。

<?xml version="1.0" encoding="UTF-8"?> 
 <saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" 
        InResponseTo="_UQ1kDQbfg5KPBBxlMJOEd8jkUOQ1hBLo" 
        IssueInstant="2017-02-17T08:52:44.650Z" 
        Version="2.0"> 
   <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> 
     samlsso.sample.net 
   </saml2:Issuer> 
   <saml2p:Status> 
     <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> 
   </saml2p:Status> 
   <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" 
       ID="Assertion1487321564650" IssueInstant="2017-02-17T08:52:44.650Z" 
       Version="2.0"> 
     <saml2:Issuer>samlsso.sample.net</saml2:Issuer> 
     <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
       <ds:SignedInfo> 
         <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 
         <ds:SignatureMethod 
           Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /> 
         <ds:Reference URI="#Assertion1487321564650"> 
           <ds:Transforms> 
             <ds:Transform 
               Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> 
             <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> 
            </ds:Transforms> 
           <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> 
           <ds:DigestValue>nKYxEAMG1LY4H+LqR22KJ/vqyb8=</ds:DigestValue> 
         </ds:Reference> 
       </ds:SignedInfo> 
       <ds:SignatureValue> 
 m5V44OFKU1PMdibileobvVVA8NVZMKRmKAauOin2f+Kr1WQ   [...]   Z/5JcU/qw== 
       </ds:SignatureValue> 
       <ds:KeyInfo> 
         <ds:X509Data> 
           <ds:X509Certificate> 
 MIIDRzCCAi+gAwIBAgIEKa/crTANBgkqhkiG9w0BAQsFADBUMRMwEQYKCZImiZPyLGQBGRYDbmV0 
 MRYwFAYKCZImiZPyLGQBGRYGc2FtcGxlMRcwFQYKCZImiZPyLGQBGRYHc2FtbHNzbzEMMAoGA1UE 
 AxMDaWRwMB4XDTE2MTExNzE0MjkwM1oXDTMwMDcyNzE0MjkwM1owVDETMBEGCgmSJomT8ixkARkW 
 A25ldDEWMBQGCgmSJomT8ixkARkWBnNhbXBsZTEXMBUGCgmSJomT8ixkARkWB3NhbWxzc28xDDAK 
 BgNVBAMTA2lkcDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ9Ai1Cs4c7CIwpJ/N0X 
 ub83SyYZz509A5/y65sj2iBFaIRCgzm0s+F6jCsyxpRd8fVgOtJ56CNdJkN+Zw7pOGvrD/EIvjn8 
 8SwCx0GDdxgtP4lfbQ7DhakSLw2hCui7yB9ijbIJjd+1f2IJbIv8TqYH4RG3kQue6i9e47W8Z4jY 
 URivaX/omXJvoBBBRO6a23n+jrQ7hk9KCACKfCEmlMaO9meg+mXRXyAXLnyaGw7W7qk27/7QB5uH 
 s2WhXIxy+wt3PrTZ9q2x413/chbQvRfrgxfhUA/GGFiWTa7x+sZ2g6bKLcGPqkjuJRuhNkeWkuOj 
 thnygoBz58A4f8MBqTUCAwEAAaMhMB8wHQYDVR0OBBYEFO8nqGs+aMkoBg/Ll4rbLZD9+V1mMA0G 
 CSqGSIb3DQEBCwUAA4IBAQAdL6/tA2faup5/BOmuBIA9CDCNk9uUf56ikFCMtP93ARsgKWPRLgba 
 i6tYC5qaVDOBn3Kcr0Wy3egObQsQE6lP4J7SCQUn/miBP/hogrc2uDhOuvCrBHvwGxRbhsMPUUCC 
 73pxGSKFf4tVKbsm8Y1k3840fJwvfc4NKn5JCj0ShEoRMmf/UkcEOTWbOEQrErrCtA3Czxo5JtKh 
 t8s1RPPg9p6lC5qk9Ob6tnLGh4mtHE9dc4FifMOaccCMTwc5O34jP7AM+avRcyvSw5b0jDhER8re 
 ubErEwK3ceaoAejlPJQbmMt9SOJfXDS7P1jc4yuWEAolJeA7CsX9xkTb3Rj3 
           </ds:X509Certificate> 
         </ds:X509Data> 
       </ds:KeyInfo> 
     </ds:Signature> 
     <saml2:Subject> 
       <saml2:NameID>alice</saml2:NameID> 
       <saml2:SubjectConfirmation 
           Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> 
         <saml2:SubjectConfirmationData 
           InResponseTo="_UQ1kDQbfg5KPBBxlMJOEd8jkUOQ1hBLo" 
           NotOnOrAfter="2017-02-17T09:52:44.650Z" 
           Recipient="https://localhost:9443/ibm/saml20/sp/acs" /> 
       </saml2:SubjectConfirmation> 
     </saml2:Subject> 
     <saml2:Conditions NotBefore="2017-02-17T08:22:44.650Z" 
         NotOnOrAfter="2017-02-17T09:22:44.650Z"> 
       <saml2:AudienceRestriction> 
         <saml2:Audience>https://localhost:9443/ibm/saml20/sp 
         </saml2:Audience> 
       </saml2:AudienceRestriction> 
     </saml2:Conditions> 
     <saml2:AttributeStatement> 
       <saml2:Attribute Name="Membership"> 
         <saml2:AttributeValue> 
           CN=CloudServiceUsers,dc=samlsso,dc=sample,dc=net 
         </saml2:AttributeValue> 
         <saml2:AttributeValue> 
           CN=LocalServiceUsers,dc=samlsso,dc=sample,dc=net 
         </saml2:AttributeValue> 
         <saml2:AttributeValue> 
           CN=IdentityRequestors,dc=samlsso,dc=sample,dc=net 
         </saml2:AttributeValue> 
         <saml2:AttributeValue> 
           CN=FrontendServiceUsers,dc=samlsso,dc=sample,dc=net 
         </saml2:AttributeValue> 
       </saml2:Attribute> 
     </saml2:AttributeStatement> 
     <saml2:AuthnStatement AuthnInstant="2017-02-17T08:52:44.650Z"> 
       <saml2:AuthnContext> 
         <saml2:AuthnContextClassRef> 
           urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 
         </saml2:AuthnContextClassRef> 
       </saml2:AuthnContext> 
     </saml2:AuthnStatement> 
   </saml2:Assertion> 
 </saml2p:Response>

在这个XML示例中，最有趣的部分是Assertion部分。 它包含令牌发行者，文档签名，主题，条件和属性声明。

• 文档 Signature包含SignatureValue（应用于整个Assertion元素的哈希的加密）。 它还包含用于生成哈希值和颁发者的公共证书（ X509Certificate ）的算法。 SignatureValue和哈希算法足以检查断言是否受信任。 为什么发行人及其公共证书信息在那里？ 原因是接收SAML令牌的应用程序知道发行者和发行者的公共证书。 而且，它可以通过比较这些字符串来快速丢弃无效的令牌。 请记住，对签名的检查非常昂贵，因为它必须处理散列和加密。
• Subject元素将用户名保存在NameId元素中。
• 条件部分包含有关此声明适用于的受众的信息。 “主题”和“条件”元素还保存接收者用来对文档进行进一步安全检查的信息。
• AttributeStatement包含有关用户所属组的信息。

当SAML接收者信任令牌时，将对用户进行身份验证。 接收方应用程序使用从SAML令牌中提取的用户名和组以编程方式为用户创建安全上下文。 在安全上下文可用之后，接收方应用程序可以启动授权API（JAAS），以验证用户是否具有访问受保护资源（例如Servlet和EJB）所需的权限。

您可以看到可以通过使用SAML断言用户身份而无需知道用户的凭据。 这种方法使SAML成为在网络中不同域上实现SSO的可能解决方案。 那么，SAML接收者如何信任SAML令牌？

用于建立信任的模型称为非对称密码术 。 此模型基于同时生成并通过数学公式链接在一起的一对密钥（私钥和相应的公钥）。 私钥用于加密，而相应的公钥用于解密。 非对称密码模型背后的主要概念是，只有使用相应的公钥才能解密使用私钥加密的数据。

在我们的方案中，身份提供者是私钥的所有者，并且不得与任何人共享。

需要信任身份提供者的SAML接收器配置为在配置文件或信任库中保存身份提供者的公钥。 当身份提供者发出SAML令牌时，身份提供者将通过两步过程生成签名值。 首先，它将哈希算法应用于Assertion元素的内容。 其次，它使用私钥对哈希进行加密。 然后，身份提供者将签名值添加到SAML令牌的SignatureValue元素，并将该令牌发送给请求者。

SAML接收器应用程序读取SAML令牌并执行两个操作：

1. 它生成Assertion元素的哈希（接收者哈希）。
2. 它使用公钥（提供者哈希）解密签名值。

如果哈希值相等，则接收方可以信任SAML令牌。 而且，它确保签名的内容不被篡改。

有关SAML身份验证如何工作的更多信息，请参阅WebSphere Application Server安全域中的SAML断言 。

SP启动的SSO：重定向或POST绑定

当您为传统的Web应用程序实现SSO时，首先，请考虑根据OASIS规范共同努力使SSO成为可能的参与者：

• 用户代理（UA） ：Web浏览器。
• 身份提供者（IdP） ：创建SAML断言的应用程序。 此应用程序可以挑战UA获取用户凭据，针对用户注册表验证这些凭据，如果有效，则生成SAML声明。
• 服务提供商（SP） ：SAML声明的接收者。 SP信任IdP，因为它知道IdP元数据。 IdP元数据是IdP公共证书，IdP颁发者名称和IdP URL。 通常将它们配置在名为idp-metadata.xml文件的文件中 。 SP使用此元数据执行SAML令牌的声明，以对UA进行身份验证，并检查是否已授权它访问所需资源，例如页面和Servlet。

下图显示了我们的示例应用程序，其中SP发起的SSO actor位于左侧的较大框中。 SP是WebSphere Liberty中的功能。 IdP是一个Web应用程序，我们将其安装在名为IdentityServer的Liberty实例上。

尽管免费的IdP实施在网络上，但是它们缺少示例配置。 我们从头开始实现，并将其作为Liberty功能提供，以使配置尽可能简单。 我们还引用了可用于Liberty的Open SAML库，这样我们就不必下载更多的开源库来生成断言。 此方案不是完全兼容的IdP实施。 如果你需要移动到生产，你可能想采取一个产品 ，它提供了IDP实施和支持。

IdP元数据是一个描述IdP的XML文件，其中包含以下信息：

• 发行者名称（idp-metadata.xml文件的id元素）
• 用于签名和加密的公共密钥（两个KeyDescriptor元素）
• 信任此IdP的SP的URL应在SP发起的SSO中使用（带有HTTP-POST的SingleSignOnService元素）

以下示例显示了我们方案的IdP元数据。

<?xml version="1.0"?> 
 <md:EntityDescriptor id="samlsso.sample.net" 
     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" 
     validUntil="2022-10-29T22:57:55Z" 
     cacheDuration="PT1478213875S" entityID="samlsso.sample.net"> 
   <md:IDPSSODescriptor WantAuthnRequestsSigned="false" 
     protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> 
     <md:KeyDescriptor use="signing"> 
       <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
         <ds:X509Data> 
           <ds:X509Certificate> 
 MIIDRzCCAi+gAwIBAgIEKa/crTANBgkqhkiG9w0BAQsFADBUMRMwEQYKCZImiZPyLGQBGRYDbmV0 
 MRYwFAYKCZImiZPyLGQBGRYGc2FtcGxlMRcwFQYKCZImiZPyLGQBGRYHc2FtbHNzbzEMMAoGA1UE 
 AxMDaWRwMB4XDTE2MTExNzE0MjkwM1oXDTMwMDcyNzE0MjkwM1owVDETMBEGCgmSJomT8ixkARkW 
 A25ldDEWMBQGCgmSJomT8ixkARkWBnNhbXBsZTEXMBUGCgmSJomT8ixkARkWB3NhbWxzc28xDDAK 
 BgNVBAMTA2lkcDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ9Ai1Cs4c7CIwpJ/N0X 
 ub83SyYZz509A5/y65sj2iBFaIRCgzm0s+F6jCsyxpRd8fVgOtJ56CNdJkN+Zw7pOGvrD/EIvjn8 
 8SwCx0GDdxgtP4lfbQ7DhakSLw2hCui7yB9ijbIJjd+1f2IJbIv8TqYH4RG3kQue6i9e47W8Z4jY 
 URivaX/omXJvoBBBRO6a23n+jrQ7hk9KCACKfCEmlMaO9meg+mXRXyAXLnyaGw7W7qk27/7QB5uH 
 s2WhXIxy+wt3PrTZ9q2x413/chbQvRfrgxfhUA/GGFiWTa7x+sZ2g6bKLcGPqkjuJRuhNkeWkuOj 
 thnygoBz58A4f8MBqTUCAwEAAaMhMB8wHQYDVR0OBBYEFO8nqGs+aMkoBg/Ll4rbLZD9+V1mMA0G 
 CSqGSIb3DQEBCwUAA4IBAQAdL6/tA2faup5/BOmuBIA9CDCNk9uUf56ikFCMtP93ARsgKWPRLgba 
 i6tYC5qaVDOBn3Kcr0Wy3egObQsQE6lP4J7SCQUn/miBP/hogrc2uDhOuvCrBHvwGxRbhsMPUUCC 
 73pxGSKFf4tVKbsm8Y1k3840fJwvfc4NKn5JCj0ShEoRMmf/UkcEOTWbOEQrErrCtA3Czxo5JtKh 
 t8s1RPPg9p6lC5qk9Ob6tnLGh4mtHE9dc4FifMOaccCMTwc5O34jP7AM+avRcyvSw5b0jDhER8re 
 ubErEwK3ceaoAejlPJQbmMt9SOJfXDS7P1jc4yuWEAolJeA7CsX9xkTb3Rj3 
           </ds:X509Certificate> 
         </ds:X509Data> 
       </ds:KeyInfo> 
     </md:KeyDescriptor> 
     <md:KeyDescriptor use="encryption"> 
       <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
         <ds:X509Data> 
           <ds:X509Certificate> 
 MIIDRzCCAi+gAwIBAgIEKa/crTANBgkqhkiG9w0BAQsFADBUMRMwEQYKCZImiZPyLGQBGRYDbmV0 
 MRYwFAYKCZImiZPyLGQBGRYGc2FtcGxlMRcwFQYKCZImiZPyLGQBGRYHc2FtbHNzbzEMMAoGA1UE 
 AxMDaWRwMB4XDTE2MTExNzE0MjkwM1oXDTMwMDcyNzE0MjkwM1owVDETMBEGCgmSJomT8ixkARkW 
 A25ldDEWMBQGCgmSJomT8ixkARkWBnNhbXBsZTEXMBUGCgmSJomT8ixkARkWB3NhbWxzc28xDDAK 
 BgNVBAMTA2lkcDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ9Ai1Cs4c7CIwpJ/N0X 
 ub83SyYZz509A5/y65sj2iBFaIRCgzm0s+F6jCsyxpRd8fVgOtJ56CNdJkN+Zw7pOGvrD/EIvjn8 
 8SwCx0GDdxgtP4lfbQ7DhakSLw2hCui7yB9ijbIJjd+1f2IJbIv8TqYH4RG3kQue6i9e47W8Z4jY 
 URivaX/omXJvoBBBRO6a23n+jrQ7hk9KCACKfCEmlMaO9meg+mXRXyAXLnyaGw7W7qk27/7QB5uH 
 s2WhXIxy+wt3PrTZ9q2x413/chbQvRfrgxfhUA/GGFiWTa7x+sZ2g6bKLcGPqkjuJRuhNkeWkuOj 
 thnygoBz58A4f8MBqTUCAwEAAaMhMB8wHQYDVR0OBBYEFO8nqGs+aMkoBg/Ll4rbLZD9+V1mMA0G 
 CSqGSIb3DQEBCwUAA4IBAQAdL6/tA2faup5/BOmuBIA9CDCNk9uUf56ikFCMtP93ARsgKWPRLgba 
 i6tYC5qaVDOBn3Kcr0Wy3egObQsQE6lP4J7SCQUn/miBP/hogrc2uDhOuvCrBHvwGxRbhsMPUUCC 
 73pxGSKFf4tVKbsm8Y1k3840fJwvfc4NKn5JCj0ShEoRMmf/UkcEOTWbOEQrErrCtA3Czxo5JtKh 
 t8s1RPPg9p6lC5qk9Ob6tnLGh4mtHE9dc4FifMOaccCMTwc5O34jP7AM+avRcyvSw5b0jDhER8re 
 ubErEwK3ceaoAejlPJQbmMt9SOJfXDS7P1jc4yuWEAolJeA7CsX9xkTb3Rj3 
           </ds:X509Certificate> 
         </ds:X509Data> 
       </ds:KeyInfo> 
     </md:KeyDescriptor> 
     <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified 
     </md:NameIDFormat> 
     <md:SingleSignOnService 
       Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
       Location="https://localhost/idp/SAMLResponse" /> 
     <md:SingleSignOnService 
       Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" 
       Location="https://localhost/idp/SAMLResponse" /> 
     <md:SingleSignOnService 
       Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 
       Location="https://localhost/idp/SAMLResponse" /> 
   </md:IDPSSODescriptor> 
  </md:EntityDescriptor>

IdP使用BASIC身份验证对用户进行身份验证。 在本系列的第3部分中，您将了解如何配置SPNEGO身份验证。

SP发起的SSO如何工作？

1. 用户导航到浏览器（UA）中的URL，浏览器依次调用公开该URL的应用程序（SP）。 如果资源受到保护，则必须对用户进行身份验证，以便SP可以对所需资源执行授权检查。
2. 如果用户未通过身份验证，则SP会通过页面答复UA，该页面会使用idp-metadata.xml文件中配置的URL自动将身份验证请求发布到IdP。

   以下XML文件是SP发送到IdP的身份验证请求的示例。

   <?xml version="1.0" encoding="UTF-8"?>  
     <saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"  
     	     AssertionConsumerServiceURL="https://localhost:9443/ibm/saml20/sp/acs"  
     	     Destination="https://localhost/idp/SAMLResponse" ForceAuthn="false"  
     	     ID="_10lsWdAH1e4faN5kuKF3tY0VTVbyqXkf" IsPassive="false"
     	     IssueInstant="2017-02-25T23:49:22.413Z"
     	     ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
     	     Version="2.0">  
     	     <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">  
     		          https://localhost:9443/ibm/saml20/sp  
     	     </saml2:Issuer>  
     	     <saml2p:NameIDPolicy  
     	       	      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />  
     </saml2p:AuthnRequest>

3. 当未经身份验证的用户登陆IdP应用程序时，IdP会挑战用户以提供其凭据。 在我们的示例中，基本身份验证表单显示在用户的浏览器上。
4. 用户输入其凭据，如果有效，则IdP生成SAML令牌。
5. IdP用一个页面答复UA，该页面自动将SAML令牌发布到SP的AssertionConsumerServiceURL。 （请参阅前面的身份验证请求的XML示例。）
6. SP接收UA发布的SAML令牌，对用户进行身份验证，并通过重定向到用户调用的初始URL来响应UA。

下图显示了在SP发起的SSO中发生的通信顺序。 请注意以下几点：

• IdP和SP的交互作用是由浏览器实现的。 因此，这些提供程序不需要相互连接。
• SP不依赖任何用户注册表，因此可以将用户注册表保留在专用客户网络中。

SAML身份传播

对于此解决方案，您必须在WebSphere Liberty上绑定Web服务安全策略，以从客户端Web应用程序自动传播SAML令牌。 您可以在传输层或消息级别设置Web服务安全性。 在传输层，您可以基于安全套接字层（SSL）或传输层安全性（TLS）设置安全性，以保护点对点的HTTP消息内容。

如果在消息级别保护Web服务的安全，则可以保护Web服务的HTTP消息中的SOAP内容。 您可以通过在Web服务Web服务描述语言（WSDL）文档中添加策略定义来设置Web服务安全性 ，并在客户端的出站通道和服务器的入站通道上配置策略。

在我们的示例中，我们在传输层和消息级别都保护Web服务。 我们通过使用基于HTTPS的SOAP在传输层设置安全性。 为了在消息级别设置安全性，我们配置了Web服务安全性SAML令牌配置文件1.1，以便客户端可以在SOAP标头中添加SAML声明，服务器可以执行该声明。

本地SSO端到端解决方案概述

在本部分的其余部分中，我们将配置三个简单的Java EE应用程序，如下图所示，以显示该解决方案的工作方式：

• Frontend.ear ：此样本Web应用程序部署在Liberty Application Server实例（FrontendServer）上，并配置为SP。
• CloudServices.ear和LocalServices.ear ：这两个应用程序都是示例Web服务应用程序。 它们部署在两个不同的Liberty实例（CloudServer和LocalServicesSvr）上，并配置为使用SAML演示身份传播。

下图说明了我们本地计算机上的解决方案配置。

该解决方案基于WebSphere Application Server Liberty概要文件和SAML 2.0。 要开发和部署该解决方案，您需要一个用于Java Enterprise Edition的Eclipse IDE。 在开始之前，请安装Java SDK，然后在开发计算机上安装Eclipse和WebSphere Liberty。

1. 下载并安装1.7版或更高版本的Java SDK。
2. 下载面向Java开发人员的Eclipse IDE发行包。 （我们使用了火星程序包。）
   1. 将软件包解压缩到本地文件系统。
   2. 启动它以创建一个新的工作区，我们稍后将使用该工作区导入项目并配置服务器。
3. 从IBM WebSphere Liberty存储库中 ，下载带有Java EE 7的Liberty（撰写本文时，最新的稳定版本是16.0.0.4。）然后，将其解压缩到本地文件系统。
4. 打开浏览器，转到WASDev开发人员中心 ，然后将“ 安装”图标拖到您在步骤3中打开的工作区的编辑器区域，以在您的Eclipse版本中安装Liberty工具。

安装Liberty工具时，在“确认选定的功能”窗口中，选中所有工具的复选框，包括WebSphere Application Server Migration Toolkit 。

在本教程中，我们使用以下路径：

• WebSphere Liberty主目录路径： <WLP_HOME> C:\programs\wlp-16.0.0.3
• WebSphere Liberty bin路径： <WLP_BIN> C:\programs\wlp-16.0.0.3\bin
• WebSphere Liberty服务器安装路径： <WLP_SERVERS> C:\programs\wlp-16.0.0.3\usr\servers

安装Liberty工具后，配置Liberty服务器运行时：

1. 选择窗口->首选项 。
2. 在“首选项”窗口中，选择“ 服务器”->“运行时环境” 。 然后，在“服务器运行时环境”窗格中，单击“ 添加” 。
   
3. 在“新建服务器运行时环境”窗口中，选择WebSphere Application Server Liberty ，然后单击下一步 。
   
4. 在Liberty Runtime Environment窗口中，将名称保留为WebSphere Application Server Liberty 。 对于路径，单击浏览 ，然后在文件系统上选择将Liberty Server解压缩到的路径。 单击“ 确定” ，然后单击“ 完成” 。
   

您的工作区应类似于以下示例。

示例项目可在GitHub上获得 。 您可以从此压缩文件下载完整的集合，然后将其解压缩到本地文件系统。

1. 在工作空间中，选择文件->导入 。
2. 在导入向导中，选择常规->现有项目到工作区中 ，然后单击下一步 。
3. 在“导入项目”窗口中，单击“ 浏览” ，然后在本地文件系统中选择提取项目的路径。 单击确定 。 选中将项目复制到工作区复选框，然后单击完成 。
   

现在，您的工作区应类似于以下示例。

提示 ：如果您选择的名称不是WebSphere Application Server Liberty ，则工作空间迁移向导会提示您选择正确的运行时，如以下窗口所示。 保留所有项目处于选中状态。 然后，在下一页上，选择您的Liberty运行时。 如果使用了正确的WebSphere Application Server Liberty名称，则不会显示该向导。

创建运行导入到工作空间中的应用程序所需的四个Liberty配置文件：

• IdentityServer ：配置为IdP的Liberty实例。
• FrontendServer ：配置为SP的Liberty实例。 在此实例上，我们部署了Frontend.ear应用程序，其中包含用于SP发起的SSO的测试用例的Web应用程序。 在第2部分中 ，我们在IBM Cloud上部署此服务器配置和应用程序。
• CloudServer ：使用Web服务安全SAML令牌配置文件1.1配置的Liberty实例。 在此实例上，我们部署了CloudServices.ear应用程序。 该应用程序包含几个Web服务操作，这些操作利用SSL上的SAML身份传播来对请求进行身份验证。 在第2部分中 ，我们在IBM Cloud上部署此服务器配置和应用程序。
• LocalServer ：使用Web服务安全SAML令牌配置文件1.1配置的Liberty实例。 在此实例上，我们部署了LocalServices.ear应用程序。 该服务器实例在本地计算机上运行，​​以演示如何通过Secure Gateway服务从IBM Cloud访问专用网络中公开的Web 服务 。 该配置类似于CloudServer配置。

要创建配置文件：

1. 创建一个自由配置文件：
   1. 选择文件->新建->其他 。
   2. 在“选择向导”窗口的搜索字段中，键入Server ，然后单击Next 。
      
   3. 在“定义新服务器”窗口中的“选择服务器类型”下，选择“ WebSphere Application Server Liberty” 。 对于服务器名称，输入IdentityServer 。 然后，单击下一步 。
      
   4. 在“新建Liberty服务器”窗口中，输入IdentityServer作为“服务器名称”，然后单击“ 完成” 。 如果Liberty安装中已有服务器实例，请单击“ 新建”以创建一个新的服务器实例。
      
2. 对于其余三个Liberty配置文件中的每一个，使用名称FrontendServer ， CloudServer和LocalServer重复步骤a-d。 完成配置后，工作空间应类似于下图左窗格中的示例。
   
3. 在该图的右窗格中，请注意左边缘圆圈中x所指示的错误。 发生这些错误是因为启用了javaee-7.0功能，并且您必须提供一个keystore元素来解决它。 对于每个服务器配置，添加以下对应的密钥库元素（或取消注释现有密钥库元素）：
   • IdentityServer：

     <keyStore password="passw0rd" 
                location="${server.output.dir}/resources/security/identitykey.jks"/>

   • 前端服务器：

     <keyStore password="passw0rd" 
                location="${server.output.dir}/resources/security/frontendkey.jks"/>

   • CloudServer：

     <keyStore password="passw0rd" 
                location="${server.output.dir}/resources/security/cloudkey.jks"/>

   • 本地服务器：

     <keyStore password="passw0rd" 
                location="${server.output.dir}/resources/security/localkey.jks"/>

4. 可选：使用不同的算法对密码进行加密，可以在server.xml编辑器的“ 设计”选项卡上进行此操作。 在此示例中，为简单起见，我们将passw0rd用作每个服务器的默认密钥库。

   首次启动每个服务器时，将使用<WLP_SERVERS>服务器目录中的日志和其他文件夹生成以下密钥库：

   • <WLP_SERVERS>\IdentityServer\resources\security\ identitykey.jks
   • <WLP_SERVERS>\FrontendServer\resources\security\ frontendkey.jks
   • <WLP_SERVERS>\CloudServer\resources\security\
   • <WLP_SERVERS>\LocalServer\resources\security\
5. 将其他配置元素添加到server.xml文件。 因为我们将在同一台计算机上启动并运行四个服务器实例，所以我们不能使用相同的端口号。
   1. 更改IdentityServer的httpEndpoint元素，如下所示：

      <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" --> 
       <httpEndpoint host="*" httpPort="80" httpsPort="443" id="defaultHttpEndpoint"/>

   2. 如下更改FrontendServer的httpEndpoint元素：

      <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" --> 
       <httpEndpoint host="*" httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint"/> 
                        
       <!-- Automatically expand WAR files and EAR files --> 
       <applicationManager autoExpand="true"/> 
        
       <wasJmsEndpoint enabled="false" wasJmsPort="7277" wasJmsSSLPort="7287"/> 
       <iiopEndpoint id="defaultIiopEndpoint" iiopPort="2810"> 
          <iiopsOptions iiopsPort="9403" sslRef="defaultSSLConfig"/> 
       </iiopEndpoint>

   3. 更改httpEndpoint元素为CloudServer如下：

      <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" --> 
       <httpEndpoint host="*" httpPort="9081" httpsPort="9444" id="defaultHttpEndpoint"/> 
                        
       <!-- Automatically expand WAR files and EAR files --> 
       <applicationManager autoExpand="true"/> 
        
       <wasJmsEndpoint enabled="false" wasJmsPort="7278" wasJmsSSLPort="7288"/> 
       <iiopEndpoint id="defaultIiopEndpoint" iiopPort="2812"> 
          <iiopsOptions iiopsPort="9404" sslRef="defaultSSLConfig"/> 
       </iiopEndpoint

   4. 更改本地 服务器的httpEndpoint元素，如下所示：

      <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" --> 
       <httpEndpoint host="*" httpPort="9082" httpsPort="9445" id="defaultHttpEndpoint"/> 
                        
       <!-- Automatically expand WAR files and EAR files --> 
        <applicationManager autoExpand="true"/> 
        
       <wasJmsEndpoint enabled="false" wasJmsPort="7279" wasJmsSSLPort="7289"/> 
       <iiopEndpoint id="defaultIiopEndpoint" iiopPort="2813"> 
          <iiopsOptions iiopsPort="9405" sslRef="defaultSSLConfig"/> 
       </iiopEndpoint>

6. 安装以下功能：
   • SAML Web单点登录版本2.0
   • WSSecurity SAML
   1. 打开命令提示符，然后输入cd <WLP_BIN> 。
   2. 对wsSecuritySaml-1.1运行以下命令以下载并安装所有必需的功能，以启用SP启动的SSO和标识传播：
      installUtility install wsSecuritySaml-1.1

成功完成下载和安装后，您应该看到以下消息：
All assets were successfully installed.

Start product validation...
Product validation completed successfully.

将之前导入的项目部署到服务器上：

1. 选择“ 服务器”视图，右键单击FrontendServer ，然后选择“ 添加和删​​除” 。
2. 在“添加和删除”窗口中，单击左侧“可用”框中的“ 前端” ，然后单击“ 添加”以将其移动到右侧的“已配置”框中。 然后，单击完成 。
   
3. 重复前两个步骤CloudServer安装CloudServices应用，以及的LocalServer安装本地服务应用程序。

完成后，您的服务器视图应类似于以下示例。

IdP是可以为经过身份验证的用户生成SAML断言的应用程序。 在以下步骤中，您将配置并测试IdP。

样本身份提供程序应用程序it.ibm.liberty.sample.identityProvider-1.0_1.0.0.esa作为Liberty功能提供，您可以在本教程的可下载文件中找到该功能。

要安装该功能，请打开命令提示符，然后输入： cd <WLP_BIN> 。 然后，输入以下命令，其中<absolute-or-relative-path>是功能文件所在的本地文件系统中的路径：

installUtility install <absolute-or-relative-path>\it.ibm.liberty.sample.identityProvider-1.0_1.0.0.esa

安装成功完成后，请重新启动Eclipse工作区以重新加载可用服务器功能的列表。

配置IdP功能，以便您可以运行它：

1. 在新的密钥库中创建密钥。 首先，打开命令提示符，然后运行以下命令：

   cd <WLP_SERVERS>\IdentityServer\resources\security\ 
     
   keytool -genkey -alias idpkey -keystore samlkey.jks -dname "CN=idp,dc=samlsso,dc=sample,dc=net" -storepass idpstorepass -keypass idpkeypass -storetype jks -validity 5000 -keyalg RSA

   请注意以下有关某些参数的说明 ：

   • keytool是JDK安装中可用的命令。 与-genkey选项一起使用时，此命令将在新的samlkey.jks密钥库中生成一个以idpkey别名引用的私钥。
   • -storepass是访问samlkey.jks密钥库的密码。
   • -keypass是访问idpkey条目所需的密码。 IdP需要此信息来签名将生成的SAML断言。
   • -dname避免提示输入名称和组织。
2. 现在您有了新的密钥库，请配置IdentityServer server.xml文件。
   1. 打开文件。
   2. 在“ 源”选项卡上，添加以下元素：

      <keyStore id="saml" password="idpstorepass" 
               location="${server.config.dir}/resources/security/samlkey.jks"> 
               <keyEntry name="idpkey" keyPassword="idpkeypass"></keyEntry> 
       </keyStore>

3. 启用先前安装的identityProvider-1.0 。
   1. 将identityProvider-1.0添加到已打开的server.xml中，并放入现有的<featureManager>元素中：

      <featureManager> 
               [...] 
               <feature>identityProvider-1.0</feature>  
       </featureManager>

   2. 添加<identityProvider>配置元素：

      <identityProvider issuer="samlsso.sample.net" keyAlias="idpkey" keyStoreRef="saml" hostname="localhost" port="443"/>

   请注意以下说明：

   • 我们的自定义identityProvider功能仅预见了几套配置参数，以允许IdP应用程序生成一个断言，并让将在下一段中配置的SP下载idp-metadata.xml配置来设置SP。 -启动的SSO。 真正的IdP软件配置起来要复杂得多，但是运行我们的示例就足够了。
   • idpkey是我们先前生成的密钥库中的密钥条目。 saml密钥库引用是samlkey.jks keyStore元素的id属性。
   • SP检查SAML断言的颁发者，以验证它是公认的颁发者。 它还会检查SP所使用的hostname：port，以浏览器为中介的POST形式转发将生成SAML的请求发送给IdP的请求。
   • 主机名必须是用于运行IdentityServer的计算机的名称，该计算机是此配置中的本地计算机。
   • 该端口必须是HTTPS端口。 在此配置的IdentityServer中，我们将端口设置为443 。
   • 尽管主机名在这里似乎是多余的，但必须将其提供给SP，以便它知道IdP在哪里。 它也可能位于其他无法访问的网络中。 因为一台计算机可以具有不同的名称和IdP，所以在我们的方案中，我们有一种方法可以确定将哪一个用于idp-metadata.xml生成器。 对于IdP，您必须使用用于运行测试的浏览器可以访问的URL。 在这种情况下，我们使用本地计算机浏览器。
4. 设置用户注册表。 我们现在使用基本注册表。 将具有以下配置的basicRegistry替换为仍打开的server.xml编辑器：

   <basicRegistry realm="samlsso.sample.net" ignoreCaseForAuthentication="false"> 
           <group name="CN=IdentityRequestors,DC=samlsso,DC=sample,DC=net"> 
                   <member name="rob"/> 
                   <member name="max"/> 
                   <member name="bobby"/> 
                   <member name="alice"/> 
           </group> 
            <group name="CN=FrontendServiceUsers,DC=samlsso,DC=sample,DC=net"> 
                   <member name="max"/> 
                   <member name="bobby"/> 
                   <member name="alice"/> 
           </group> 
           <group name="CN=CloudServiceUsers,DC=samlsso,DC=sample,DC=net"> 
                   <member name="bobby"/> 
                   <member name="alice"/> 
           </group> 
           <group name="CN=LocalServiceUsers,DC=samlsso,DC=sample,DC=net"> 
                   <member name="alice"/> 
           </group> 
           <user name="rob" password="passw0rd"/> 
           <user name="max" password="passw0rd"/> 
           <user name="bobby" password="passw0rd"/> 
           <user name="alice" password="passw0rd"/> 
   </basicRegistry>

5. 为IdP Web应用程序配置基于角色的授权。 在server.xml编辑器中，添加：

   <authorization-roles id="idp.roles"> 
            <security-role name="IdentityRequestor"> 
                    <special-subject type="ALL_AUTHENTICATED_USERS"/> 
            </security-role> 
            <security-role name="Snooper"> 
                    <special-subject type="ALL_AUTHENTICATED_USERS"/> 
            </security-role> 
    </authorization-roles>

使用此配置，所有basicRegistry用户都被授权执行IdentityRequestor（保护SAMLRequest servlet）和Snooper（保护监听servlet）的角色。

IdP准备为经过身份验证的用户生成SAML断言：

1. 通过运行以下测试，确保IdentityServer已启动：
   • 生成SAML断言： http://localhost/idp/SAMLResponse
   • 访问此实用程序页面以下载公共证书和idp-metadata.xml：
     http://localhost/idp/SAMLResource
   • 打印一些请求信息： http://localhost/idp/snoop
2. 在“ BASIC身份验证”窗口中，输入您先前配置的basicRegistry中的用户名和密码组合之一。

根据标准的基于JAAS角色的授权，用户属于不同的组，以允许对资源访问进行限制。

您可以在GitHub上可下载资料的servers文件夹中找到整个server.xml配置以及密钥库。

既然已经安装了samlWeb-2.0功能，就可以对其进行配置以启用SP发起的SSO。

1. 打开http://localhost/idp/SAMLResource URL，然后单击IdpMetadata.xml以下载idp-metadata.xml文件。 将文件保存在<WLP_SERVERS>\FrontendServer\resources\security\目录中。
2. 打开FrontendServer server.xml文件，然后将samlWeb-2.0功能和wsSecuritySaml-1.1功能添加到现有的<featureManager>元素中：

   <featureManager> 
            [...] 
             <feature>samlWeb-2.0</feature>
             <feature>wsSecuritySaml-1.1</feature>
    </featureManager>

3. 将samlWebSso20添加到server.xml实体中：

   <samlWebSso20 id="sp" allowCustomCacheKey="true" authnRequestsSigned="false" createSession="true"  
            disableLtpaCookie="true" enabled="true" groupIdentifier="Membership" httpsRequired="true"  
            idpMetadata="${server.config.dir}/resources/security/idp-metadata.xml" inboundPropagation="none"  
            includeX509InSPMetadata="true" realmName="samlsso.sample.net" signatureMethodAlgorithm="SHA256"  
            wantAssertionsSigned="true" />

有关配置参数的完整说明，请参阅IBM Knowledge Center 中Liberty中的“ 配置SAML Web浏览器SSO” 。

请注意以下几点：

• allowCustomCacheKey和disableLtpaCookie配置指示本地服务器应缓存SAML断言，并且我们不想使用LTPA cookie。 使用此配置，如果将FrontendServer集群并且用户登陆到其他服务器上，则该服务器应将其转发到IdP以为用户生成SAML断言。 如果不是，则没有SAML断言可用于将身份传播到后端Web服务。
• idpMetadata指向您刚从IdP下载的文件。

要测试由SP启动的SSO，请启动FrontendServer，然后在http://localhost:9080/FrontendWeb/ URL上测试由SP启动的SSO 。

要查看由SP启动的SSO序列，您可以使用浏览器的开发人员工具来跟踪网络请求。 例如，如果您使用的是Mozilla Firefox，请按F12，或选择“ 选项”菜单，然后选择“ 开发人员”以启用工具栏。 以下示例显示了我们方案中由SP启动的SSO序列。

将公共SSL证书导入到frontendkey.jks密钥库中，以允许Frontend应用程序使用HTTPS调用CloudServices。 我们从CloudServer导出公共证书，然后将其导入到FrontendServer密钥库中。

1. 打开命令提示符，然后输入：
   cd <WLP_SERVERS>\CloudServer\resources\security\
2. 运行以下命令以查看首次启动服务器时自动创建的CloudServer SSL证书：
   keytool -list -keystore cloudkey.jks -storepass passw0rd

   输出类似于以下示例，其中default是包含密钥对的KeyEntry的名称：

   Keystore type: jks 
    Keystore provider: IBMJCE 
     
    Your keystore contains 1 entry 
     
    default, Nov 17, 2016, keyEntry, 
    Certificate fingerprint (SHA1): 2D:16:E2:E9:FC:C1:34:26:94:35:50:7C:0C:A4:42:15:A8:4D:BE:68

3. 导出与默认密钥关联的公共密钥。 在已经打开的命令提示符下的同一目录中，运行：

   keytool -export -alias default -file CloudServer.cer -keystore cloudkey.jks -storepass passw0rd 
     
   cd ..\..\..\FrontendServer\resources\security\ 
     
   keytool -import -alias cloudssl -file ..\..\..\CloudServer\resources\security\CloudServer.cer -keystore frontendkey.jks -storepass passw0rd -storetype jks -keypass cloudkeypass -noprompt 
   
   keytool -list -keystore frontendkey.jks -storepass passw0rd

   最后一个命令的输出类似于以下示例：

   Keystore type: jks 
    Keystore provider: IBMJCE 
     
    Your keystore contains 2 entries 
     
    cloudssl, Nov 17, 2016, trustedCertEntry, 
    Certificate fingerprint (SHA1): 2D:16:E2:E9:FC:C1:34:26:94:35:50:7C:0C:A4:42:15:A8:4D:BE:68 
    default, Nov 17, 2016, keyEntry, 
    Certificate fingerprint (SHA1): 73:4C:A6:F8:32:3F:3D:0D:87:54:2C:F0:69:74:58:64:72:C6:10:CB

   密钥库现在具有两个密钥： default和cloudssl 。 您刚刚添加了cloudssl键。 首次启动FrontendServer实例时，在创建密钥库时添加了默认密钥条目。 该密钥的密码为passw0rd ，因为配置server.xml实体时，您仅提供了整个密钥库的密码。

   默认密钥项是应用程序服务器用于提供TLS （例如HTTPS）的证书。 因为我们添加了新密钥，所以我们必须配置FrontendServer server.xml实体以添加具有导入CloudServer.cer文件时提供的别名和密码的新密钥库引用。

   错误消息：尽管您可以将两个条目及其密码添加到默认的keyStore中，但是Liberty配置文件会发出以下错误消息：

   [ERROR ] CWPKI0813E: Error while trying to initialize the keymanager for the keystore [C:/programs/wlp-16.0.0.3/usr/servers/FrontendServer/resources/security/frontendkey.jks].The private key password is not correct or the keystore has multiple private keys with different passwords.This keystore can not be used for SSL. Exception message is: [Cannot recover key].
4. 打开FrontendServer server.xml文件 ，切换到“ 源”选项卡，并添加新的密钥库以配置新密钥的别名：

   <keyStore id="trust" password="passw0rd" 
            location="${server.output.dir}/resources/security/frontendkey.jks"> 
            <keyEntry name="cloudssl" keyPassword="cloudkeypass"></keyEntry> 
    </keyStore>

   配置完成。

5. 启动IdentityServer，FrontendServer和CloudServer。 如果打开应用程序，然后单击左侧菜单中的“ Cloud Service”链接或“ 受限制的服务 ”，则会收到以下错误消息：
   None of the policy alternatives can be satisfied.

   此消息来自CloudServer。 （您可以检查其日志。）此消息表示SSL握手已成功执行，并且证书配置良好。 但是，由于尚未为CloudServer配置适当的策略来管理传入的SAML断言，因此CloudServer不知道如何管理它。 启用安全性是因为EJB方法受角色保护，它声称它不能满足收到的安全性策略。

对于IdentityServer，您下载的资源材料中提供了FrontendServer的完整配置。

为CloudServer和LocalServer设置安全策略。 让我们从证书开始。 两台服务器都需要声明一个SAML文档。

1. 下载IdP公钥。 首先，打开http://localhost/idp/SAMLResource URL，然后单击X509证书以下载samlsso.sample.net.cer证书。 将文件保存在<WLP_SERVERS>\IdentityServer\resources\security\samlsso.sample.net.cer目录中。
2. 导入所有剩余的证书。 两台服务器都需要samlsso.sample.net.cer证书。 CloudServer还需要LocalServer的公钥来调用LocalServices应用程序公开的Web服务。

   打开命令提示符，然后将目录更改为<WLP_SERVERS>\LocalServer\resources\security\路径。 运行以下命令：

   keytool -import -alias saml -file ..\..\..\IdentityServer\resources\security\samlsso.sample.net.cer -keystore localkey.jks -storepass passw0rd -storetype jks -keypass samlpassw0rd -noprompt 
     
   keytool -export -alias default -file LocalServer.cer -keystore localkey.jks -storepass passw0rd 
     
   cd ..\..\..\CloudServer\resources\security 
     
   keytool -import -alias saml -file ..\..\..\IdentityServer\resources\security\samlsso.sample.net.cer -keystore cloudkey.jks -storepass passw0rd -storetype jks -keypass samlpassw0rd -noprompt 
     
   keytool -import -alias localssl -file ..\..\..\LocalServer\resources\security\LocalServer.cer -keystore cloudkey.jks -storepass passw0rd -storetype jks -keypass localkeypass -noprompt 
     
   keytool -list -keystore cloudkey.jks -storepass passw0rd

   最后一个命令显示CloudServer的三个证书。 您可以对LocalServer运行相同的命令，但仅显示前两个键。

   Keystore type: jks 
    Keystore provider: IBMJCE 
     
    Your keystore contains 3 entries 
     
    saml, Nov 17, 2016, trustedCertEntry, 
    Certificate fingerprint (SHA1): 8B:EC:92:91:2E:12:57:7B:B4:DC:4A:A6:7C:3A:E7:AE:D9:11:CC:5A 
    default, Nov 17, 2016, keyEntry, 
    Certificate fingerprint (SHA1): 2D:16:E2:E9:FC:C1:34:26:94:35:50:7C:0C:A4:42:15:A8:4D:BE:68 
    localssl, Nov 18, 2016, trustedCertEntry, 
    Certificate fingerprint (SHA1): A4:3E:2E:94:9A:E0:E8:04:65:46:43:89:AA:EF:99:6B:9D:A7:06:AF

   现在，您已经完成了两个服务器的导入。

3. 配置两个服务器的功能，密钥库和策略：
   1. 打开LocalServer和CloudServer server.xml文件，并将wsSecuritySaml-1.1添加到现有的<featureManager>元素中：

      <featureManager> 
               [...] 
                <feature>wsSecuritySaml-1.1</feature>
       </featureManager>

   2. 将引用新创建的密钥的新密钥库添加到CloudServer：

      <keyStore id="trust" password="passw0rd" location="${server.output.dir}/resources/security/cloudkey.jks"> 
               <keyEntry name="localssl" keyPassword="localkeypass"></keyEntry> 
               <keyEntry name="saml" keyPassword="samlpassw0rd"></keyEntry> 
       </keyStore>

   3. 将wsSecurityProvider策略配置添加到CloudServer：

      <wsSecurityProvider id="SAMLBearerSSL"> 
               <samlToken clockSkew="5m" requiredSubjectConfirmationMethod="bearer" timeToLive="30m" 
                       wantAssertionsSigned="true"/> 
               <callerToken groupIdentifier="Membership" mapToUserRegistry="No" name="SAMLtoken"/> 
               <signatureProperties org.apache.ws.security.crypto.merlin.keystore.alias="samlsso.sample.net" 
                       org.apache.ws.security.crypto.merlin.keystore.type="jks" 
                       org.apache.ws.security.crypto.merlin.file="${server.output.dir}/resources/security/cloudkey.jks" 
                       org.apache.ws.security.crypto.merlin.keystore.password="passw0rd" 
                       org.apache.ws.security.crypto.merlin.keystore.private.password="samlpassw0rd"/> 
       </wsSecurityProvider>

      现在，您已经完成了CloudServer的操作 。

   4. 重新启动CloudServer，打开应用程序，然后单击Cloud Service链接。 您现在应该从该方法中看到正确的答复。

      提示 ：根据用户的组，您是否可以访问该服务。 如果您以bobby或alice身份登录到IdP，您将被授权并看到如下示例所示的答复：

      service response: Response from CloudMessageService.getMessage at 1479426017208
      otherwise following message should appear:
      java.rmi.AccessException: ; nested exception is: com.ibm.websphere.csi.CSIAccessException:
      CWWKS9400A: Authorization failed for user max while invoking getMessage on CloudServices.
      The user is not granted access to any of the required roles:  [CloudServiceAccessRole].

   5. 完成LocalServer的配置：
      1. 添加新的keyStore ：

         <keyStore id="trust" password="passw0rd" location="${server.output.dir}/resources/security/localkey.jks"> 
                  <keyEntry name="saml" keyPassword="samlpassw0rd"></keyEntry> 
          </keyStore>

      2. 添加wsSecurityProvider策略配置：

         <wsSecurityProvider id="SAMLBearerSSL"> 
                  <samlToken clockSkew="5m" requiredSubjectConfirmationMethod="bearer" timeToLive="30m" 
                          wantAssertionsSigned="true"/> 
                  <callerToken groupIdentifier="Membership" mapToUserRegistry="No" name="SAMLtoken"/> 
                  <signatureProperties org.apache.ws.security.crypto.merlin.keystore.alias="samlsso.sample.net" 
                          org.apache.ws.security.crypto.merlin.keystore.type="jks" 
                          org.apache.ws.security.crypto.merlin.file="${server.output.dir}/resources/security/localkey.jks" 
                          org.apache.ws.security.crypto.merlin.keystore.password="passw0rd" 
                          org.apache.ws.security.crypto.merlin.keystore.private.password="samlpassw0rd"/> 
          </wsSecurityProvider>

         现在，您已经完成了LocalServer。

      3. 重新启动本地 服务器 ，打开应用程序，然后单击“ 受限服务”链接。 您现在应该从该方法中看到正确的答复。

         提示 ：根据用户的组，您是否可以访问该服务。 如果您以alice身份登录到IdP，那么您将获得授权，并且可以看到LocalServer上的Web服务发出的消息，该消息由CloudServer调用（由前端servlet调用），如以下示例所示：
         service response: Response from LocalMessageService.getLocalMessage at 1479426200968

         否则，您会看到以下消息：
         java.rmi.AccessException: ; nested exception is: com.ibm.websphere.csi.CSIAccessException:
CWWKS9400A: Authorization failed for user bobby while invoking getLocalMessage on LocalServices.
The user is not granted access to any of the required roles: [LocalServiceAccessRole].

就像FrontendServer配置一样，可在server文件夹中的资源资料中找到CloudServer和LocalServer配置。

结论

现在，您在本地计算机上具有基于WebSphere Application Server Liberty概要文件和SAML 2.0的功能齐全的，端到端SP启动的SSO。 您还在WebService应用程序之间传播了SAML身份。 您可以在GitHub上的代码示例中查看本教程，以了解其工作原理。

在第2部分中 ，您将在IBM Cloud中部署FrontendServer和CloudServer。 您还配置安全网关，以允许CloudServices应用程序访问由LocalServices应用程序公开的Web服务，该服务仍在私有网络上运行，而该私有网络无法从作为本地计算机的公共Internet访问。 Then, in Part 3 , you extend the SSO scenario to integrate the Microsoft Windows authentication, by using the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) and the Active Directory Domain Services.

致谢

The authors thank Massimo Leoni , Carlo Randone , and Richard Kozel for reviewing this article and providing helpful comments, and Pavel Travnik for testing the code.

翻译自: https://www.ibm.com/developerworks/library/mw-1703-maurip1-bluemix/index.html

sso 服务端配置