基于证书和IP的认证

发布于 2024-08-16 07:51:12 字数 205 浏览 2 评论 0原文

有没有一种方法可以让 java web 应用程序通过 http 请求获取有关计算机上安装的安全证书的信息，并在计算机上安装了特定证书时有选择地授予访问权限。

基本上要求是，Web 应用程序应仅接受来自公司笔记本电脑的请求，否则必须使用适当的错误文本拒绝访问。

（这些可能是在其计算机上安装了某些证书的 win 笔记本电脑，或者它们可能来自一组特定的静态 ip。）

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

司马昭之心 2024-08-23 07:51:12

是的，可以使用 HTTPS 客户端证书实现这一点。确切的设置和配置取决于您的应用程序服务器和特定要求，但常见的情况是您创建公司内部 CA（证书颁发机构）来颁发可能仅限于特定客户端 IP 地址的客户端证书，并配置应用程序服务器的HTTPS 连接器需要客户端证书并信任您自己的 CA 颁发的证书。

完成正确的配置后，客户端证书将通过 servlet 请求属性提供给 Web 应用程序：

X509Certificate[] certificates = (X509Certificate[])
    request.getAttribute("javax.servlet.request.X509Certificate");

Yes, this is possible using HTTPS client certificates. The exact setup and configuration depends on your application server and specific requirements, but a common scenario woul be that you create a company internal CA (certification authority) to issue the client certificates which may be restricted to specific client IP addresses and configure your application server's HTTPS connector to require a client certificate and to trust certificates issued by your own CA.

After the proper configuration has been done, the client certificate(s) is/are made available to the web application through a servlet request attribute:

X509Certificate[] certificates = (X509Certificate[])
    request.getAttribute("javax.servlet.request.X509Certificate");

回复收藏 0 原文

小傻瓜 2024-08-23 07:51:12

正如 jambjo 所说 - 正如他所描述的那样，您绝对可以通过 HTTPS 和客户端身份验证来获取客户端证书。我建议通过静态 IP，证书更难被欺骗，并且如果您将来需要以不同的方式重新配置网络，则可以提供更大的灵活性。

其他一些想法：

几乎所有应用程序服务器都会让您设置受信任的证书存储 - 您的应用程序将接受 HTTPS 客户端身份验证的 CA 证书列表。将此限制为提供客户端证书的 CA - 内部公司 CA 或证书提供商。
内部 CA 或 CA 提供商的选择是企业的选择。内部 CA 需要人力来设置和维护，CA 提供商将为每个证书付费。到达一个权衡点时，自己制作证书会更便宜，但在达到该点之前，CA 提供商可能会更便宜。
如果您有一个内部 CA 并且您的规则是“任何公司计算机（带有证书）都可以访问此应用程序”，那么您的工作将在应用程序服务器中的受信任 CA 列表中完成，因为您知道公司 CA 不会被访问。用于公司内部人员以外的任何人。
如果您有 CA 提供商，您可能需要进一步限制访问控制，并使用 jambjo 提供的代码来获取证书并查看其中的信息。通常，主题 DN（专有名称）内有一个组织 (O) 和组织单位 (OU) 组件，可以告诉您哪个组织生成了此证书。您应该能够检查以确保您拥有公司计算机。
如果您知道您的 CA 提供商绝不会向除您公司成员以外的任何人提供您公司的 O 和 OU 名称，那么进行 O 和 OU 检查是可行的。如果情况并非如此，您可能需要检查后端数据存储（例如 LDAP 目录），以确保您了解该用户或用户的计算机。
还可以将计算机的 IP 地址链接到证书 - 通常在构建证书时使用SubjectAltName（主题备用名称）来实现此目的。我不推荐它，因为如果您更改机器的 IP 地址，您将需要一个新的证书。对于您的目的来说，这似乎不必要地复杂。

As jambjo said - you can absolutely get client certificates through HTTPS with client authentication as he described. I'd recommend that over static IPs, a certificate is harder to spoof and allows more flexibilty if you need to reconfigure the network differently in the future.

A couple other thoughts:

Almost any application server will let you set a trusted certificate store - the list of CA certificates your application will accept for HTTPS client auth. Limit this to the CA that is providing client certificates - either an internal company CA or a certificate provider.
The choice of internal CA or CA provider is a corporate one. An internal CA will take manpower to set up and maintain, a CA provider will cost you money per certificate. There reaches a tradeoff point where it's cheaper to make the certificates yourself, but until you hit that point, the CA provider may be cheaper.
If you have an internal CA and your rule is that "any company machine (with a certificate) can access this application", then your work is done at the Trusted CA list in the applicaiton server, since you know the company CA will not be used for anyone but people in the company.
If you have a CA provider, you may need to limit your access control further and use the code jambjo provided to get the certificate and look at information within it. Typically, there is a organization (O) and organizational unit (OU) component within the subject DN (distinguished name) that will tell you what organization produced this certificate. You should be able to check that to be sure you have a company computer.
It's viable to do the O and OU checking if you know that your CA provider will never give out your company's O and OU names to anyone but a member of your company. If that is not the case, you may need to check against a back end data store (like an LDAP directory) to be sure the user or user's machine is known to you.
It's also possible to link the IP address of the machine to the certificate - often SubjectAltName (Subject Alternative Name) is used for this when the certificate is being constructed. I would not recommend it, because you will need a need a new certificate if you ever change the IP address of the machine. It seems unnecessarily complex for your purposes.

回复收藏 0 原文

~没有更多了~