在Salesforce中基于SAML 2.0搭建SSO并启用JIT User Provisioning(SF Orgs间 / SF Org与Experience Cloud间 / 其他IdP)

前言】:早前成功搭建的SSO Demo都是SF Org作为SP,Azure AD / LinkedIn等第三方服务作为IdP,直到现在碰巧遇到新客户想要实施SSO,想着可以积累实战经验正乐呵着,在进行完一轮洽谈才了解到其实存在两大挑战

#1. 客户方的Azure是On-Premise的,而以前的成功经验是Azure AD Cloud服务;
#2. 结合项目背景,我们需要将Experience Cloud作为SP,而之前是将SF Org作为SP;

那个时候需要先进行一轮POC,初始化的工作流程需要先跑起来,比如我们需要向客户要哪些输入要素,我们后续需要输出什么等等。基于此背景,于是搜集到两篇官方文档准备临时抱抱佛脚:

看完文档后并没有找到SF Experience Community如何与本地Azure进行SSO配置的直接答案,但由于都是基于SAML 2.0协议的,考虑到对方那边的配置于我而言仍是黑盒,当下首要任务是将SF作为SP和IdP来搭建SF Org间,更进一步SF与Experience Cloud间的SSO流程。因此本文将基于下图展示的最终效果,总结下搭建流程并尝试进一步延伸话题

基础知识】:

SSO是什么?

Single sign-on (SSO) is an authentication method that enables users to access multiple applications with one login and one set of credentials.

IdP与SP是什么?

The system that authenticates users is called an identity provider. The system that trusts the identity provider for authentication is called the service provider.

对于SSO SF支持的两种协议:Salesforce supports SSO with SAML and OpenID Connect. 对于考试而言,支持self-registration的用JIT的是SAML SSO,OpenID Connect Auth, Provider对应的是Registration Handler.

什么是SAML?

SAML is an open-standard authentication protocol that Salesforce uses for single sign-on (SSO) into a Salesforce org from a third-party identity provider. You can also use SAML to automatically create user accounts with Just-in-Time (JIT) user provisioning.

SAML认证机制如何?

When a user tries to log in, your identity provider sends SAML assertions containing facts about the user to Salesforce. Salesforce receives the assertion, validates it against your Salesforce configuration, and allows the user to access your org.

搭建流程】:以SF Org间搭建SSO为例

#1. Both:在SP与IdP中启用My Domain;
#2. IdP:在IdP中启用Identity Provider;
#3. IdP:在IdP详情页下载证书与Metadata或复制Salesforce Identity的URL作为后续步骤的输入项;
#4. SP:找到Single Sign-On Settings项,进入后有3种方式(手动New,从本地导入上一步骤下载的xml文件,从复制的URL中导入配置项)配置SSO Settings;
#5. SP:上传IdP证书,建议SAML Identity Type选择Federation ID (如果后续需启用JIT User Provisioning此类型必须),并保存;
#6. SP:从SSO的详情页复制3样信息:Entity ID, Issuer及Endpoints陈列的Login URL供后续使用;
#7. SP:点开My Domain,在Authentication Configuration面板处勾选刚才配好的Authentication Service
#8. IdP:为SP创建相应的Connected App,其中Entity ID, Issuer是#6中复制的,Start URL与ACR填上#6中对应位置的Login URL
#9. 测试 - 先退出两SF Orgs,访问SP的login页面,随后将在账密Form下看到SSO的图标;
#10. 排错 - 使用SAML tracer谷歌插件监听SSO时重定向过程及XML断言参数,若有问题可以复制SAML的Response XML并前往SP的SSO配置详情页用SAML Assertion Validator验证错误 / 当然也可以借助Login History和Identity Provider Event Log定位错误;

交互流程

注意事项

1. 一个Org中请确保Issuer与Entity ID拼在一起的字符串唯一;
2. 在SF间做SSO(SF Org间 / Experience Cloud间),其中Identity Provider信息是公用的,SSO Settings与Connected App需要相应创建;以前言图例说明,SPs在同一个Org,登Salesforce与登Experience Cloud是两个不同的domain,所以在SP中创建SSO Settings时,需要分别使用IdP中的两套xml信息:

创建后的SP中的SSO Settings与IdP中的Connected App对应分别如下:

图1. SF Org间

图2. Experience Cloud间

大家不难看出在上图2标记处分别对应的是My Domain与Experience Cloud的siteURL

3. 为Experience Cloud搭建完SSO,不要忘了去Workspaces -> Administration -> Login & Registration勾一下,同【搭建流程】#7 
4. 在IdP保持登录状态下,为了达到点击链接后skip掉Login Form跳到SP中,请确保SSO的授权服务只有一个开启,如下图:

其他话题】:

证书管理最佳实践

在实务中搭建SSO时,IdP往往由客户方管理,由于证书有过期日期,如果在证书配置环节存在不同证书,当证书过期后提示信息并不会明确告诉我们哪个证书过期了,因此统一证书将是一个不错的选择
在SF间搭建SSO时,IdP中的Identity Provider与Connected App需要公用1个证书,SSO Settings需要>=2个证书(一个来自IdP,一个一般为自签,还有断言解密有可能需要)。

跨Org交换证书在SF的Certificate and Key Management中有个叫keystore的概念,导出导入需要统一的密码,以下是导入示例:

Connected App自定义属性应用

用于传递参数,指定后使用SAML tracer就能看到,如下图:

问题与方案】:

问题归属:A. Azure AD作为IdP,Experience Cloud作为SP进行单点登录

Q1、使用下图Community Login Page进行单点登录时

报错如下:AADSTS50105: The signed in user {email address} is not assigned to a role for the application '{tanent id}'(SixDeep-Salesforce).

A1、登录Azure Portal,在Azure Services板块点击Azure Active Directory,进入tenant后点选左侧导航Enterprise applications,点击Salesforce应用后在左侧导航点选Properties到达目标页,将User assignment required?取勾后保存配置即可

注意:即便为新邀请的user分配了Azure AD的role,也解决不了上述问题。

Q2、单点登录时,报错如下:AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application: 'https://ydc-dev-ed.my.salesforce.com'.

 

 

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页