Single Sign On：需要问的问题

祖父总是说：“别去尝试任何新东西。先等等看，看看是不是先害死了谁。” 最近，我参与了多项 Single Sign On 项目的落地推进，他的话一直萦绕在我脑海深处。 一部分我在想：“把所有事情都只用一个用户名和密码来访问，这不是个好主意。” 如果发生黑客攻击，入侵者就会拿到他们的东西，从而获得对一切的访问权限。但另一部分又看着它说：“用户会喜欢这个的。” 这就是一种经典处境：做了是傻，不做也是傻。那你到底该怎么做呢？

什么是 Single Sign On？

当你第一次从“安全人员”的角度看待 Single Sign On（SSO），但又不理解其来龙去脉时，SSO 看起来就像是企业级的自杀行为。光是它的名字——Single Sign-On——就会让人联想到“用同一套凭据处理所有事情”。不过关键点在于：它的设计目标是让你的用户生活更轻松，同时不牺牲安全性。你所做的是利用一种叫做 SAML（Security Assertion Markup Language）的东西。它是一种基于 XML 的开源数据格式，允许我们在不同的应用程序或参与方之间交换认证和授权数据。通过利用用户的 AD 或 LDAP 信息，它实际上还能在“流程中再加一层”从而在一定程度上增强安全性。

因此，我们通过将其影响“已在 AD 中授予的权限”这一点联系起来，从而增强了安全性。大多数情况下，如果某个应用程序关联了独立的用户名/密码，那么只需要输入一次，SSO 应用就会为我们提供访问权限。听起来可能有点吓人，但请记住：典型的 AD 锁定（lockout）仍然会正常工作。而且还有一个额外好处：如果账号遭到入侵，大多数 SSO 软件都配备了一些非常强大的报表/报告功能。因此，我们可以识别被入侵的账号以及被访问的数据。

在确定采用 Single Sign On 之前需要问的问题

ここであえて“悪魔の代弁者”をやって、みんなが気になっている疑問を投げかけます。結局のところ、本当のところどれくらい安全なのでしょうか？

好吧，就像魔鬼一样，我先不把答案一下子告诉你，而是说：关于这个问题，我们会在接下来的几周里再展开讨论。现在，假设你想在自己的组织中推行某种 Single Sign On。如果你想在组织中部署 SSO，下面有几件事值得你思考。

清单上的第一项：我们是在谈论全新的内容，还是在进行升级？很多时候，这是一个新的 SSO 产品来替换旧的。就在这里，你需要开始考虑培训和沟通。沟通——让用户知道正在发生什么；培训（即使仅仅是一段在线视频）——教大家如何使用新的产品。

我们想用它做什么？是想将访问集中起来吗？还是通过改进授权来提升安全性？或者只是做最基本的审计（auditing）？也许我们是想同时实现这三者。归根结底：当你知道最终会变成什么样、能期待什么时，更容易把项目做成功。

在一开始就决定我们希望为哪些应用提供访问权限是非常重要的。大多数应用都能与 SSO 配合得很好，但也有一些不会。那些“不会”的应用可能会让你的生活变得很困难，甚至需要引入第三方，并付出不止一点点的创造力才能让它们正常工作。所以要做好这样的预期。

谁来负责处理这件事？必须有人对该系统承担责任，而且可能需要公司内不同层级的几个人共同来处理它。比如，在最近的一个 SSO 项目中，我负责在服务器上进行部署设置，协助管理项目，并完成最初的应用接入以及用户的导入（seeding）。但在一开始就已经确定，未来将由 Tier 1 的同事来添加新用户。因此，我们必须对他们进行准备，并至少在那个阶段前把培训安排到位。不过，应用程序的管理，以及对服务器的维护与日常运行（更不用说未来的升级和 DR）都将牢牢由我来承担。

或许我们需要重点关注的、也是最重要的一点，就是当公司随着成长与变化而发展时，我们所购买的 SSO 是否也能持续扩展并不断演进。

就像他们在很早以前的 60 年代常说的那样：别去碰旋钮。