基于saml2.0的平台（适用多种平台）单点登录配置，以okta为例

现状和问题

解决方案原理

基于saml2.0协议的Java实现

基于OKTA平台的实例演示

结论

题外话

现状和问题

事情的起因在于接到一个需求，要求在SAP的succesfactory中使用单点登录的方式来集成外部的Java自开发系统。

现有的情况是，在登录succesfactory（下称sf平台）后，点击已有的链接地址，会跳转到自开发登录界面，需要再输入用户名密码才能登录。这种方式肯定是比较繁琐，所以希望能够在sf平台一次登录，到处认证。所以就需要用到单点登录。

根据掌握的情况是，sf平台是已经配置且只能唯一配置第三方单点登录平台，所以只能沿用目前存在的单点登录认证平台，经过了解，目前使用的三方单点登录平台使用的也是SAP的系列产品—SCI（SAP Cloud Identity Services），或者叫IAS（这个英文解释没找到）。

图1 目前系统现状

通过上图可以看出，目前的自开发和sf平台是都支持独立的Web访问的，但是sf平台可以通过单点登录（SSO）的方式，纳入到SCI平台的生态系统中，如果公司还有别的项目也采用了SCI认证，那么只要登录了SCI平台，就可以实现真正意义上的一处登录，处处登录。

目前存在情况便是自开发平台和sf平台各自为战，即使是通过SCI的统一认证，自开发平台还是会需要再认证一次，这样就会给业务实现带来不必要的资源消耗。

我们真正想要实现的方式便是如下图所示：

图2 改造后系统情况

可以看到，通过把自开发平台纳入到SCI平台，经过单点登录（SSO），可以实现只需要登录一次SCI平台，便可以任意访问sf和自开发平台系统。

解决方案原理

目前市面上主流的单点登录解决方案有2种，一种基于auth2.0、一种是saml2.0，其各有优劣。关于二者的前置知识，读者需要自行查找，这里提供一个快速入口：

SAML和OAuth2这两种SSO协议的区别

一文搞懂saml2.0协议

由于SCI平台是基于saml2.0协议实现的单点登录，那么我们着重介绍一下saml2.0。

要了解saml2.0先要认识3个角色，分别是Idp（认证服务器）、Sp（服务提供者）、客户端。我们前面提到的SCI平台的角色就是Idp，而sf和自开发平台都属于Sp，客户端就是我们常用的桌面浏览器。

saml2.0协议的核心流程便是，如果要从客户端利用Idp通过SSO的形式访问Sp，需要提前在Idp和Sp保存对方的公钥文件，这样方便双方请求的时候能够进行认证，防止权限不够的401错误。

当在客户端输入Sp的url地址，Sp会通过后台重定向到Idp提供的sso地址去进行请求，由于Sp提前保存了Idp的公钥信息，可以顺利的访问到Idp提供的认证地址，在Idp接收到Sp的正常请求后，又会跳转到提前保存好的Sp指定url，同样也由于Idp保存了Sp的公钥信息，可以使得访问顺利进行。

从而完成客户端对Sp服务器的单点登录。

而这一切对于客户端来说是完全无感知的，如果细心观察，会发现浏览器地址栏的url会跳来跳去，之后会跳转到我们需要访问的页面。其简化步骤如下图所示：

图3 Idp通过sso登录Sp简化步骤

基于saml2.0协议的Java实现

本文以Java开发为例，实现方式有2种，一种是基于Spring框架的模式，另外一种是纯Java模式，利用Jar包引入的方式onelogin。

笔者两者都使用过，简单的说下结论，尽量用spring框架相关的saml验证方式，onelogin方式在理论上也是可行，但是由于时间紧迫，尝试了一下onelogin的demo和平台的调试，但是没有联调成功，其具体方式见链接onelogindemo。

而基于Spring框架的saml单点登录的实现方式的具体链接如下：springSaml。

纵观saml2.0的实现方式，其实都是表象，其实质是它们都需要遵循saml2.0协议，只是实现的方式不同，只有抓住这个中心点，我们才能不限于任何平台来做单点登录。

基于OKTA平台的实例演示

由于SCI平台的特殊性，以及Sap文档的错漏百出，关于SCI平台集成smal2.0协议的资料无法完整演示，所以我们使用OKTA作为我们的SSO登录演示平台。

这里提一下，经过笔者的验证，其实所谓的onelogin、SCI、OKTA，在基于saml2.0协议的单点登录配置，虽然说每个平台的配置不尽相同，但是其配置思路基本都是一脉相承。相信只要了解了其中任何一个，其余的平台也都是可以触类旁通。

这里选取的OKTA平台是笔者认为效率最高的。

这里基于OKTA的配置，在前文的springSaml中已经有超链接跳转，里面的项目有详细描述。

本文只是针对OKTA配置中的某些不完整的地方进行补充，可以帮助大家尽快的搭建demo。

OKTA可以免费申请开发者账号：申请链接。

通过OKTA帮助文档完成saml Idp搭建。

这里笔者说一下需要注意的点：

按步骤搭建中，需要设置应用不为内部应用，这样才可以与外部系统进行SSO。具体如下图：
在Idp服务器完成SSO验证以后，需要再跳转到Sp服务器，此时需要把Sp服务器中的公钥文件上传到OKTA平台上，不然Idp无法访问Sp服务器，具体上传地方如下：

在Upload按钮处上传Sp公钥证书。

完成了OKTA的saml单点登录验证，其实SCI平台的配置也基本大同小异。这里就不一一说明，有需要注意的点就是SCI下载的metadata.xml（Tenant Settings->SAML 2.0 Configuration）不能直接使用，只需要提取其关键信息，诸如Idp的SSO、SLO链接、entityId还有509证书密钥即可，可直接使用SpringSamlDemo中Idp的xml配置，修改关键信息即可。

结论

其实无论实现的方式如何，核心便是要了解saml2.0的SSO登录流程及其原理，每个平台实现的方式都不尽相同，那么我们就抓住它们的共性：saml2.0协议作为突破口。当完成一个平台的SSO验证之后，其余平台的问题也基本迎刃而解。

题外话

在做SCI平台集成外部自开发系统的单点登录的时候，搜索了SAP的大量资料，发现文档竟没有这方面的描述，更多的都是一些SAP平台环境或者Azure相关的一些集成资料，关于自开发如何配置与SAP的SCI集成的文档，反正我是压根没看到。

一度都打算回复这个需求无法实现了，因为站在与SAP做集成的角度，没有文档就意味着不可能实现。

但是我换了一种思路，直接从saml2.0协议出发：我先实现一套标准的saml2.0协议的SSO流程，再把这套流程套入到SAP，我想SAP既然作为一套标准产品它必然是会支持标准的saml2.0协议。

不出所料，我先实现了OKTA的SSO登录，接着实现SCI平台的便是水到渠成了。

希望这样的思路对大家有所帮助。

SAP关于SCI方面的链接放下，大家有需要可以自取，但是访问好像需要有账号才行：SCI链接。

链接可能会失效，大家可以直接进SAP HELP搜索，Configure SAML 2.0 Service Provider或者SAP Cloud Identity Services。