认证插件介绍

本文档是针对 UOS 登录器插件给出开发指南，目的是为了让开发人员了解如何在 UOS 登录器上增加一种自定义认证方式，对插件接口做了详细说明以及实战练习。

---

一、认证插件可以做什么？

UOS 提供了丰富了登录方式：密码、UKey 、指纹、人脸、虹膜等，这些登录方式是在登录器内部处理的，想要实现其它的登录方式（比如二维码）又不想与 UOS 的登录器有过多的耦合，那么就可以使用认证插件的方式来实现。只需根据认证插件的接口来开发一个动态库，即可在登录器上增加一种自定义登录方式。

二、认证流程

登录器在开机/注销/锁屏后会加载认证插件，并发起认证，然后等待插件返回认证结果。用户鉴权通过后，插件发送认证成功给登录器，后面的如何进入系统由登录器来处理。在整个过程中，插件只需要关注自身的认证逻辑，把认证结果发送到登录器后插件的工作就完成了。

三、术语说明

登录器：即统信UOS系统中的登录/锁屏软件。

登录是指用户开机、重启、注销后看到的 UI 界面，进程名称为 lightdm-deepin-greeter。

锁屏是用户按下 Meta+L 快捷键（没有修改快捷键的情况下），或者在电源界面选择“锁定”后看到的 UI 界面，进程名为 dde-lock 。

四、安全性

在整个流程中，登录器不参与用户身份的校验，用户身份的真实性和访问权限完全由认证插件来保证，所以在开发认证插件的时候对于安全性的考虑要全面且慎重。这是除了功能需求之外最重要的特性，下面列出一些常见的需要考量的问题：

• 输入密码等认证信息应该使用加密手段保护数据的不被窃取以及中间人攻击。
• 存储的用户数据（如密码与隐私数据）应该加密保护且加密强度足够高。
• 不应该未经用户允许保存或者传输用户数据。

五、可靠性

登录器会把插件加载到内存中，如果认证插件的质量不过关，出现指针错误、内存溢出、在 UI 线程做耗时操作等，会导致登录器崩溃、卡死，进而导致用户无法正常进入系统。登录器是系统的门户，如果用户无法正常使用登录器，将无法进入系统，这是致命性问题，故而在开发时要将可靠性做为重点去考量。

六、兼容性

认证插件的工程需要增加一个 json 文件（元数据文件），用来描述当前插件适配的 api 版本，在代码中使用 Q_PLUGIN_METADATA 将 json 文件设置为 metadata 文件,例如：Q_PLUGIN_METADATA(IID “com.deepin.dde.shell.Login” FILE “login.json”)。登录器在加载插件的时候会解析 json 文件中的内容，获取 api 版本号。
登录器会做到小版本向下兼容（1.x.x版本都互相兼容），如果出现无法兼容的情况（比如增加了接口头文件的虚函数，导致二进制不兼容），此时会修改大版本号（比如从 1.x.x 变更到 2.x.x ），登录器会比对 api 版本号，如果低于可兼容的版本号，则不会加载插件，以保证登录器本身能够正常运行。json 文件示例：

{"api": "2.0.0"，"pluginType": "Login"
}

login_module_interface.h 中 API_VERSION 宏定义的字符串即为当前 api 的版本号，json 文件中 api 字段记录的版本号务必与 API_VERSION 保持一致。

七、插件安装

登录器和锁屏启动会检测以下目录来加载插件，将插件动态库安装到这里，并重启系统就可以看到插件的加载效果

/usr/lib/dde-session-shell/modules

---