RADIUS 全称为远程身份验证拨入用户服务（Remote Authentication Dial-In User Service），是一种用于验证和授权用户访问的网络协议，访问范围囊括了远程和本地。此外，RADIUS 也用于网络基础设施的访问。
自推出以来，RADIUS 一直作为网络访问管理的重要工具而广泛应用。本文从 RADIUS 的诞生开始探究其的应用演变，以及在现代 IT 环境中存在的问题。
1. RADIUS的起源
关于 RADIUS 协议的故事始于1987年，当时美国国家科学基金会（NSF）与 Merit Network Inc. 签订了合同，以扩展 NSFnet（现代互联网的前身）。 Merit Network Inc. 是一家位于密歇根大学的非营利性公司，一直致力于开发专有的网络认证协议，对接密歇根州的所有高校网络。当时，大多数网络专有协议都具有排他性。在此背景下，NSF 为了将互联网向公共开放而签署了扩展 NSFnet 的合同。 然而，要开放互联网，Merit 公司的专有网络必须转换为基于 IP 的 NSFnet 网络。于是，Merit 决定开发一种基于 IP 网络，而且支持公司拨号身份验证的网络协议，并且征求了供应商的建议。其中一家名为 Livingston Enterprises 的公司给出的提案基本上包含了现在所用的 RADIUS 协议的描述。最终，Merit 在1991年接受了该公司的提议，RADIUS 协议由此诞生。
2. RADIUS 如何运行？
RADIUS 利用客户端/服务器模型来验证用户的网络访问。用户的网络访问请求从用户系统或 WiFi 接入点等客户端发送到 RADIUS 服务器进行身份验证。RADIUS 服务器通常与一个单独的核心身份提供程序（IdP）数据库（即目录服务）耦合，并把该数据库作为用户身份源。虽然 RADIUS 服务器自身也可以存储用户身份，但是服务器内的身份其实是被锁定的，不能提供给所有类型的 IT 资源使用，所以大多数企业不会选择这种方法。
当用户尝试从远程访问受 RADIUS 协议保护的网络时，往往需要提供唯一的用户凭证，该凭证与存储在云端或本地目录数据库中的用户身份相关联。用户提供的凭证会通过请求者（向无线网络发出登录请求的程序）从客户端传输到 RADIUS 服务器。 简单来说，身份验证请求和用户凭证都会通过请求者从用户设备发送到支持 RADIUS 的网络设备，如 WiFi 接入点或 VPN。然后，这些网络设备再将身份验证请求转发到 RADIUS 服务器进行认证。RADIUS 服务器在接收到验证请求和凭证后，会根据关联的目录服务数据库验证用户凭证。
如果用户凭证与目录数据库中的信息匹配，服务器会将有效授权发送回 RADIUS 客户端以连接网络。如果不匹配，服务器就会发出拒绝访问的通知。认证成功的情况下，RADIUS 服务器还可以将用户置于特定的 VLAN 中或启动多因素认证。
3. 现代 RADIUS 的限制
经证明，RADIUS 协议的确可以加强网络安全和管控，但依然存在问题，特别是对于面向云的新型 IT 企业。具体来说，RADIUS 需要先有本地身份和访问管理（IAM）基础设施才能在本地实施，IAM 基础设施包括目录服务器、RADIUS 服务器、路由器、交换机、负载平衡器等。
落实这些基础设施可以说成本高昂，而且难以实现。此外，本地的 IAM 基础架构主要集中在 Windows 系统，由微软 Active Directory（AD）充当核心的身份提供程序（IdP）。AD 也提供了基于 RADIUS 的辅助功能——名为 Windows Server Network Policy Server （网络策略服务器，Windows NPS）的服务器。
然而，很多 IT 企业都打算放弃本地 AD 方案，因为 AD 在跨平台和混合云环境中存在诸多限制，而这两点又是多样化的现代 IT 环境和远程办公不可或缺的因素。
现在有很多 IT 企业都在采用 AD 替代方案将本地身份管理基础架构迁移上云，既提高了敏捷性，也降低了成本。但这又带来了新的问题：在没有任何本地部署的情况下，IT 企业如何继续提供 RADIUS 认证并保持无线网络和远程网络安全？
4. 基于云的 RADIUS 认证
针对这一新的问题，新一代基于云的身份管理方案为企业提供基于云的 RADIUS 认证微服务。IT 团队可以安全管理用户并对接到相应的业务系统、应用程序和文件，用户无需考虑平台、协议、厂商和位置，都能通过 RADIUS 协议访问网络，在充分利用 IT 资源的同时，也有效地保障了企业网络安全。
（本文来源于宁盾，仅供大家学习和参考，未经授权禁止转载和复制。如欲了解身份认证更多内容，可前往宁盾官网博客解锁更多干货）