单位上了WiFi实名认证系统，往往不是从零开始。员工有统一身份认证，学生有学工号体系，会员有CRM账号，这些身份系统早就在跑。新来的实名认证系统如果另起一套账号，用户要记两套密码，管理员要维护两份数据，时间一长两边对不上，问题一大堆。怎么把WiFi实名认证系统的账号体系和现有身份系统打通，是项目里最容易被低估、也最容易出乱子的一块。

先分清哪些身份该走对接，哪些该走匿名

不是所有WiFi用户都要对接内部身份系统。员工、学生、会员这类"已知身份"的用户，适合对接统一身份；访客、临时来宾适合走独立的实名通道，不一定强绑内部账号。我们做方案时第一步就是给用户分层：第一层是内部已知身份，对接现有系统；第二层是合作方、常来客户，可以给预开账号或者临时凭证；第三层是纯访客，走手机号实名。分层之后，账号体系的对接范围就清楚了，不会一股脑把所有流量都往内部身份系统灌，也不会把该对接的漏掉。

对接方式别只听一面之词

身份系统对接常见的有LDAP、RADIUS、OAuth、SAML、数据库直连几种，各自适用场景不同。有些供应商为了省事，张口就说"我们支持对接"，但不说清楚用哪种方式、同步是单向还是双向、延迟多大。我们遇到过项目，实名认证系统用数据库直连读统一身份库，结果统一身份系统一做表结构升级，认证全挂。对接方式要定到协议层面，并且让两边系统的负责人当面确认接口细节。WiFi实名认证系统支持多种对接协议是好事，但选哪种要看现有身份系统的能力和运维习惯，不是哪个时髦用哪个。

账号状态同步是隐藏的大坑

员工离职、学生退学、会员注销，这些状态变化要能实时反映到WiFi实名认证系统，否则离职的人还能连公司WiFi，风险很大。对接如果只做"认证时查一次"，不做状态同步，就会出现这种滞后。正确的做法是建立状态推送或者定时拉取机制，身份系统里账号一禁用，WiFi侧跟着失效。我们建议关键场景用实时推送，普通场景至少做到每天增量同步，并且保留同步日志备查。这块很多项目上线时忘了做，等到出安全事件才补，代价高得多。

密码和凭证的处理要守边界

对接身份系统，最忌讳的是WiFi实名认证系统把用户密码再存一份。正确做法是走令牌或者委托认证，WiFi侧只拿到"认证通过"这个结果和必要的身份标识，不碰原始密码。我们见过一个项目，实名认证系统把统一身份的密码同步到自己库里，等于多了一个密码泄露点，被安全审计直接判不合规。对接设计要坚持"密码不出源系统"原则，能用RADIUS转发、OAuth这类不传密码的方式就用。凭证处理守不住，打通的成本远高于收益。

字段映射要逐一对齐，别想当然

统一身份系统里的字段名、格式、含义，和WiFi实名认证系统未必一致。工号可能是字符串带字母，学号可能是纯数字，手机号有的带区号有的不带。字段映射不做细，认证时能过，但后续按身份查日志、做统计就全乱。我们要求对接前拉两份字段字典，逐字段对齐，写映射规则文档，并且用真实样本数据跑一遍。曾经有个学校项目，学号在身份系统里是带前导零的字符串，到了WiFi系统被当成数字把零丢了，几千条记录对不上，排查花了两天。这种坑，文档对齐能挡掉大部分。

多身份源并存时的优先级

一个单位可能同时有员工身份、会员身份、访客身份，一个人可能多重身份叠加。WiFi实名认证系统要能处理"同一人多种来源"，并且定义清楚优先级和合并规则。比如一个既是员工又是会员的人连WiFi，优先走员工身份还是会员身份，两套账号的权限怎么合并，要不要去重。我们建议给每种身份源排优先级，认证时按优先级命中，并且把合并逻辑写清楚，避免一个人出现两个上网账号、日志对不上。多源并存不可怕，怕的是没规则。

对接失败时的降级路径要留好

身份系统也可能宕机、升级、网络断。那时WiFi实名认证系统如果完全依赖它做认证，整个网络就瘫了。我们要设计降级：身份系统不可用时，内部用户能临时走备用认证（比如本地缓存的最近一次有效凭证），或者切到访客实名通道，至少保证能上网。降级不是绕过合规，是在源系统故障时维持基本可用。我们建议对关键身份源做健康检查，异常时自动切降级并记录，恢复后补同步。这条路径上线前必须演练，否则真出事时没人知道怎么切。

打通之后要能说得清账号从哪来

身份打通做得好，运维和审计都要轻松。一个WiFi账号，能反查到它来自哪个身份源、对应哪个真实身份、什么时候同步的、状态现在怎样，这条链路要完整可追溯。监管来查、内部做安全复盘，看的都是这个。我们做项目收尾时会陪客户走一遍"账号溯源"演练，确认从上网日志能一路追到源头身份系统。打通的意义不只是省得用户记密码，更是让整个身份体系可管、可控、可查。这件事做好了，账号体系才真正算打通，而不是连上了事。