基于CMS数字签名的基于机票的SSO

，IBM中国软件工程师

Chen Shunzi从事IBM CSTL云计算团队的研发工作.

，IBM中国高级软件工程师

Zhang Jian在IBM中国开发中心工作，目前专注于虚拟化和与云计算相关的技术和产品.

，IBM中国软件工程师

Cao Mudan是IBM中国软件开发中心的一名工程师，主要从事云服务解决方案的研究和开发. 兴趣包括: 虚拟化，云服务和数据分析.

2014年8月25日

在IBM Bluemix云平台上开发和部署您的下一个应用程序.

立即开始免费试用

在日常生活中，签名通常用作个人身份的证明. 当文件上有个人签名时，我相信此人确实已经过该人的审阅. 同样，在数字安全领域，数字签名也扮演着类似的角色.

首先，数字签名确认一条数字信息确实来自实体. 由于不对称加密的原理，使用私钥加密的消息只能使用相应的公钥解密，反之亦然. 如图1所示，签名是由实体的私钥生成的，而私钥仅由签名方持有. 因此，在图2中，只能使用签名者的公钥来解密签名. 解密成功后，可以认为签名者已生成此消息.

第二，数字签名可以确保邮件在传递过程中未被篡改. 如图1所示，数字签名由特定算法的哈希值加密. 使用MD5和SHA之类的哈希算法可以确保消息的哈希值的唯一性. 因此，在图2中，可以使用相同的算法重新计算消息的哈希值，并将其与签名中的哈希值进行比较. 如果结果一致，则可以相信邮件在发送后没有被篡改.

CMS（加密消息语法）是由Internet工程任务组（IETF）开发的安全消息规范（RFC 5652）. 该规范定义了多种消息格式，用于对任何消息进行数字签名，散列，验证和加密.

本规范中指定的数字签名格式可以包括以下各项: 哈希值生成算法，签名者的数字证书（包括签名者的公钥），签名者的基本信息，原始消息，签名等. 在上一节的生成和验证数字签名的过程中，我们可以发现CMS规范中指定的格式已经包含了数字签名的所有必要信息.

同时，对于开发人员来说，您可以使用开源工具轻松地以CMS格式生成数字签名. 例如，Linux下的openssl命令和Java的开源类库BouncyCastle都提供了用于生成和验证CMS格式的数字签名的功能.

单点登录，也称为SSO（单点登录），是指彼此信任的多个系统. 用户可以访问所有系统，只要它们执行登录操作，直到登录失败. 在单点登录环境中，每个应用程序将身份验证功能移交给单点登录系统，而不是使用自己的身份验证系统. 使用单点登录之前和之后的用户身份验证过程如图3和图4所示.

尽管当前单点登录的实现方式有所不同，但大多数都是基于票证的SSO. 这种实现方式的特点是，在用户首次登录后，系统将生成一个字符串，称为票证（也称为令牌），作为后续用户身份验证的凭据. 当用户访问受保护的应用程序时，请求中会包含票证. 如果验证的票证有效，则允许用户访问.

通常会将票证设置为到期时间，在此之后，该票证将不再被视为有效. 在极端情况下，票只能使用一次. 在一定程度上，这种方法可以避免由于票证被第三方拦截而威胁到系统安全的情况. 但是要完全消除这种可能性，通常需要HTTPS以确保信息传输的安全性.

以下将通过举例说明单点登录系统的几个重要功能，说明CAS，Kerberos，OAuth和Openstack Keystone的几种常见的单点登录实现（协议）:

第二种情况称为第三方应用程序授权. 用户首先访问第三方应用程序. 第三方应用程序本身不是受保护的应用程序，但是提供的服务取决于受保护的应用程序. 第三方应用程序向受保护的应用程序发起请求，以访问受保护的应用程序上的用户资源. 用户通过单点登录服务器授权第三方应用程序ibm 单点登录，并允许第三方应用程序访问请求. 身份验证过程涉及四个实体，即用户，第三方应用程序，受保护的应用程序和单点登录系统. 其中，第三方应用程序是授权对象. OAuth和OpenID属于此类.

在WEB应用程序环境下，浏览器客户端是广泛存在的客户端. 浏览器提供的cookie机制可以为用户身份验证提供极大的便利. 例如，CAS默认使用cookie来记住用户是否已在单个登录服务器上进行了身份验证. 但是，由于浏览器本身的限制，它通常无法提供复杂的加密和解密处理功能，而该功能对于Kerberos是必需的. 因此，Kerberos无法应用于浏览器客户端.

产品/协议应用场景的主要客户端类型支持脱机身份验证并不受第三方

用户身份验证

浏览器

Kerberos

用户身份验证

非浏览器

OAuth

应用授权

全部

Openstack Keystone

用户身份验证/应用授权

非浏览器

BouncyCastle是一个开源Java安全类库（还提供C#版本），支持多种安全协议. 使用BouncyCastle可以轻松完成CMS数字签名的生成和验证任务.

public String sign(X509CertificateHolder signCert, KeyPair signKP) {
List certList = new ArrayList();
certList.add(signCert);
Store certs = new JcaCertStore(certList);
CMSTypedData msg = new CMSProcessableByteArray("Hello world!".getBytes());
CMSSignedDataGenerator gen = new CMSSignedDataGenerator();
ContentSigner sha1Signer = new JcaContentSignerBuilder("SHA1withRSA").setProvider("BC").build(signKP.getPrivate());
gen.addSignerInfoGenerator(new JcaSignerInfoGeneratorBuilder(
new JcaDigestCalculatorProviderBuilder().setProvider("BC").build()).build(sha1Signer, signCert));
gen.addCertificates(certs);
CMSSignedData sigData = gen.generate(msg, true);
String signature = new String(sigData.getEncoded());
Return signature;
}

清单1显示了为字符串“ Hello World”生成CMS数字签名的过程. Certs表示签名者的证书，signKP.getPrivate（）表示签名者的私钥，SHA1withRSA表示消息哈希算法为SHA1，公钥和私钥生成算法为RSA. 这些元素与上述数字签名生成过程一致. 生成的签名是CMS格式的数字签名字符串.

最后值得一提的是gen.generate（msg，true）. 这里的第二个参数表示是否将原始消息封装到签名中. 如果此参数为false，通常会说生成的分离签名表示签名和消息是分开存储的.

public String verify(String signature)｛
   CMSSignedData s = new CMSSignedData(signature.getBytes());
   CertStore certs = s.getCertificatesAndCRLs("Collection", "BC");
   SignerInformationStore signers = s.getSignerInfos();
   boolean verified = false;
    for (Iterator i = signers.getSigners().iterator(); i.hasNext(); ) {
        SignerInformation signer = (SignerInformation) i.next();
        Collection<? extends Certificate> certCollection = 
        certs.getCertificates(signer.getSID());
        if (!certCollection.isEmpty()) {
             X509Certificate cert = 
             (X509Certificate) certCollection.iterator().next();
             if (signer.verify(cert.getPublicKey(), "BC")) {
                  verified = true;
              }
     }
}
  CMSProcessable signedContent = s.getSignedContent() ;
  byte[] originalContent = (byte[]) signedContent.getContent();
  return new String(originalContent);
}

清单2显示了如何验证清单1中生成的数字签名. 由于CMS数字签名支持多个实体来对消息进行签名，因此您可以在此处逐个验证每个签名者. 如前一节所述，签名者的证书已经包含在签名中，并且该证书包含验证签名所需的签名者的公共密钥.

此处未显示的一个步骤是如何验证签名者的证书. 一般而言，您需要确是由可信的组织颁发的，以便信任证书中包含的公钥确实由其声明的实体拥有. 但是，数字证书的作用和验证不在本文的讨论范围之内，在此不再详细描述.

SSO的服务器端，通常也称为身份验证服务器（Authentication Server），负责为受保护的应用程序收到的所有请求提供统一的身份验证.

定义服务器端外部接口时，需要考虑不同类型的客户端的需求. 对于浏览器客户端，服务器需要返回的内容通常是HTML格式的网页，Javascript脚本和CSS文件. 您可以使用重定向技术（URL重定向）将未经身份验证的用户定向到登录页面. 登录完成后，然后将用户定向到最初访问的页面. 同时，浏览器提供的cookie也可以用于存储用户的票证，以便在随后的请求中，可以直接从cookie获得用户的票证. 对于这种类型的接口，可以使用传统的JSP / Servlet来实现.

但是对于非浏览器客户端（应用程序），以上情况不再适用. 应用程序通常以Web服务的形式相互交互. 交互式内容不再是网页，而是XML或JSON格式的文件. 与网页相比，这种类型的文件不需要关心如何向用户显示内容以及如何与用户交互，因此其内容通常更加简化. 对于这种类型的接口，当前更流行使用RESTful（表示状态传输）Web服务来实现.

因此，要满足以上两种客户端类型的需求，至少应提供以下外部接口

同时，在服务器内部，提供三个接口来满足上述功能要求，如图5所示.

如前所述，票证实质上是CMS格式的数字签名. 上一篇文章描述了签名生成过程. 剩下的问题是，什么用作生成签名的原始消息. 对于服务器，无论使用什么消息，都可以完成数字签名的生成和验证，以达到用户认证的目的. 因此，这里主要考虑的是客户的需求.

大多数应用程序必须获取用户的身份信息，这也是用户身份验证的主要目的之一. 在单点登录环境中，用户身份信息由单点登录服务器管理. 一种方法是，在完成用户身份验证之后ibm 单点登录，受保护的应用程序会向单点登录服务器发起请求以获取信息. 但是，如果将用户的身份信息用作生成的签名的原始消息，则可以避免此附加请求. 如前所述，CMS数字签名可以将原始消息封装到签名中. 因此，当获得票证时，已经获得了与票证相对应的用户身份信息.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-229905-1.html