它被广泛接受，你可以做，以确保您的SSLVPN的基础设施正在实施双因素认证方案的最好的事情之一。通常情况下，这已经使用一次性密码令牌技术来实现的。但是，有关使用到绑定的用户名，而不是一个OTP令牌的方法数字证书是什么？这个想法是，该证书是你的东西，用户名/密码是你知道的东西。这是在Cisco ASA新的支持功能，但不是新的行业，所以我想这可能是有趣的检查它。对于选择证书方法给出的常见原因是节约成本，易于使用，基于标准，并降低总拥有成本。我不能完全接受这个观点，但是却认为这是值得探讨和分析。这种方法是相对较新，但越来越深入人心。因此，这里的用户体验和幕后流的解决方案：
- 用户获得授权在他们的公司使用SSLVPN服务。该SSLVPN管理员创建的认证服务器上，并在证书数据库中的新用户帐户。管理员可以确保在用户证书的主题字段包括用户名属性，其值等于他在认证服务器上创建的帐户。
- 用户收到一封电子邮件，要求注册PKI并安装其唯一的数字证书。用户完成这些步骤后，他们的PC上就有了唯一的证书。
- 用户浏览到sslvpn设备的url。在后台，sslvpn设备将查询用户的PC以获取其唯一的数字证书。它将检查它的有效性并提取它正在查找的username属性的值。
- 如果证书如果有效的SSLVPN头端会提示用户进行身份验证。然而，用户名字段会预先填写了使用证书的价值。最终用户然后进入他们的密码和登录完成。
让我们深入了解这种证书方法如何工作的细节。通常，要使用经过验证的数字证书，您必须有一个可供SSLVPN用户使用的公钥基础设施(PKI)。与任何PKI一样，你可以建立自己的PKI或者外包给像VeriSign这样的人。根据经验，最容易将其外包给受信任的证书颁发机构(CA)。这样就不需要在每个sslvpn用户的浏览器中安装受信任的根证书。众所周知的可信赖的根CA公司已经在那里。外包PKI的缺点是成本，它可能变得昂贵。但是，即使这样的开销也比实现双因素身份验证的硬件令牌解决方案要便宜得多。好了，你已经有了PKI。现在需要向所有sslvpn用户颁发证书。 This process varies, but can be as simple as sending users an email that contains their username, a one-time password, and a digital certificate enrollment url. The user must then go through the certificate enrollment process which will install a unique, per user, digital certificate onto their PC. Other methods of installing a certificate on each user’s PC exist so do your homework. Now, you need to establish a typical username/password authentication mechanism for the sslvpn headend device to use to authenticate users. Popular choices are RADIUS and Active Directory LDAP. Tying the user’s digital certificate together with their username/password is the next step to creating our two-factor authentication solution. The two must be paired together for this to work properly. This is accomplished by using the value of an attribute, found in the certificate, as the enforced username of the sslvpn user. Typically, it is a value in the subject field of the digital cert. For example, OU=jamey. The cert field chosen is determined by the headend sslvpn device administrator and can vary from tunnel group to tunnel group. The headend sslvpn device will query the certificate for this value. It will also take the value and pre-fill the username field of the typical authentication window the user sees at the client side. The user must then input the correct password for that username into the login box. Trying to hack, change, or modify the pre-filled username field on the client side is largely irrelevant because the ASA sslvpn device effectively ignores it anyway. It only trusted the value that it received directly from its query of the certificate itself. So the hacker would have to be able to modify the certificate while maintaining its validity. A non-trivial task to say the least. So there you have it, a two factor solution using digital certificates and username/passwords. The Cisco ASA devices support this feature starting in 8.0.3.1 code. I think this approach is very interesting but I am still biased towards the traditional OTP token solutions. Would you consider this solution truly two-factor? What pros and cons do you see? Could this approach kill the costly OTP hardware tokens, I think not, but what say you?